GNU nano - Bugs: bug #56766, older nanos complain about the...
You are not allowed to post comments on this tracker with your current authentication level.
bug #56766: older nanos complain about the current perl.nanorc: "Invalid range end"
Submitter: | Benno Schulenberg <bens> | ||
Submitted: | Sat 17 Aug 2019 11:04:12 AM UTC | ||
Severity: | 2 - Minor | Status: | Fixed |
Assigned to: | bens | Open/Closed: | Closed |
Jump to the original submission
Tue 20 Aug 2019 02:51:45 PM UTC, comment #11: |
Benno Schulenberg <bens> |
Tue 20 Aug 2019 12:39:40 AM UTC, comment #10: Do the ranges in the braces set not cause an error?
|
Brand Huntsman <brand> |
Mon 19 Aug 2019 03:16:26 PM UTC, comment #9: It should not be needed, because all newer nanos should be using gnulib's regex modules when they're compiled on an older system (and anyway, no one is using nano to edit Perl scripts, as no one has complained about any miscoloring after variable names (bug #56713)), but... just in case: I've replaced the range expressions with an explicit enumeration: commit bdf1a9d4. |
Benno Schulenberg <bens> |
Mon 19 Aug 2019 03:07:02 PM UTC, comment #8: I've checked on my dad's machine (64-bit, an older Linux Mint, glibc 2.23) and it's the same thing: 4.0 and 4.3 use the regex replacement functions from gnulib, but 4.1 and 4.2 don't. And the nanos that don't use gnulib, complain about "Invalid range end" in the new perl.nanorc. |
Benno Schulenberg <bens> |
Sun 18 Aug 2019 06:32:21 PM UTC, comment #7: I also have 32bit glibc 2.29, and it doesn't appear to have any extra patches applied. So gnulib isn't only checking the version of glibc. And I also ran a script that cleans and re-configures nano when I switched versions. |
Brand Huntsman <brand> |
Sun 18 Aug 2019 11:51:05 AM UTC, comment #6: On a different machine (32-bit, with an up-to-date Manjaro), it is the same thing: 4.0 and 4.3 use the regex replacement functions from gnulib, 4.1 and 4.2 don't. (And that is after cleaning, reconfiguring and remaking each of them, to exclude the influence of a different base system at compile time.)
|
Benno Schulenberg <bens> |
Sun 18 Aug 2019 09:10:19 AM UTC, comment #5: I don't find an explicit set of characters easier to read.
|
Benno Schulenberg <bens> |
Sun 18 Aug 2019 12:00:18 AM UTC, comment #4: And none of them with or without gnulib produce an error with that regex. |
Brand Huntsman <brand> |
Sat 17 Aug 2019 11:51:00 PM UTC, comment #3: And my system uses gnulib for 4.0 and newer, but not for 3.2. So it isn't consistent with your results. |
Brand Huntsman <brand> |
Sat 17 Aug 2019 06:11:25 PM UTC, comment #2: Why not just replace the ranges with the easier to read explicit list of characters, and then open a new bug on why gnulib doesn't work? |
Brand Huntsman <brand> |
Sat 17 Aug 2019 01:51:23 PM UTC, comment #1: The difference is that (on my machine) nano from git, version 4.3 and version 4.0 use the regex replacement functions from gnulib, whereas 4.2 and 4.1 and 3.2 and older do not use any modules from gnulib. :| Somehow the older configure code from gnulib failed to see the need to use gnulib's regex modules.
|
Benno Schulenberg <bens> |
Sat 17 Aug 2019 11:04:12 AM UTC, original submission:
When running a nano version from before 4.3, while using the syntax definitions from current git, it will report "Mistakes in perl.nanorc" on the status bar, and upon exit the following message will be on the terminal:
|
Benno Schulenberg <bens> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2019-08-19 | bens | Severity | 3 - Normal | 2 - Minor | |
Status | None | Fixed | |||
Assigned to | None | bens | |||
Open/Closed | Open | Closed |
Powered by Savane 3.13-f8d8.
Corresponding source code
No. Only the range ['-.] ending with a period triggered the complaint. (Checked on two machines, glibc 2.23 and 2.27.)