bugGNU nano - Bugs: bug #57852, \d and \D not working as expected...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #57852: \d and \D not working as expected in regular expression search

Submitter:  Ben Addis <faxanadu>
Submitted:  Tue 18 Feb 2020 02:28:05 PM UTC
   
 
Severity:  3 - Normal Status:  Confirmed
Assigned to:  None Open/Closed:  Closed

Jump to the original submission

Wed 21 Oct 2020 08:35:58 AM UTC, comment #7: 

Closing this, as the recognition of \d and \D is a task for the regex functions, not for nano.  (In theory, nano could translate \d to [0-9] and \D to [^0-9], but what if someone uses \d or \D inside square brackets?  I don't want to go there.)

No one responded to the bug report for grep.  But just now I read in 'man 7 regex':  "An atom is [...] a '\' followed by any other character(!) (matching that character taken as an ordinary character, as if the '\' had not been present(!)) [...]."  To me this appears to say that "\x" in a regular expression should be equivalent to "x" if "\x" doesn't have any special meaning.

Benno Schulenberg <bens>
Group administrator
Mon 24 Feb 2020 06:54:26 PM UTC, comment #6: 

Reported upstream as https://lists.gnu.org/archive/html/bug-grep/2020-02/msg00003.html, but so far no response.

Benno Schulenberg <bens>
Group administrator
Tue 18 Feb 2020 06:59:11 PM UTC, comment #5: 

(I should add that my grep is aliased to 'grep --color=auto'.)

Benno Schulenberg <bens>
Group administrator
Tue 18 Feb 2020 06:51:54 PM UTC, comment #4: 

In GNU grep, \d does not select digits -- it just finds "d".  Which shows that also in nano, \d should find any d and D, just like \D.  Hmmm...  \d does find lowercase "d"s when switching on case sensitivity with M-C.  So... \d not working in the case-insensitive case is a bug, in gnulib.


grep -i '\d' README


This command selects certain lines, but nothing is highlighted in red.  When using \D instead, the selection is the same, but all "d"s and "D"s are shown in red.  :|  Weird bug.

$ grep -V | head -1
grep (GNU grep) 3.1

I've downloaded and compiled GNU grep 3.4.  It still has the same bug.  I will go and report it tomorrow.

Benno Schulenberg <bens>
Group administrator
Tue 18 Feb 2020 04:01:52 PM UTC, comment #3: 

Thanks for looking into it.

I also found a comment on Hacker News (https://news.ycombinator.com/item?id=17571211) that said \d is from perl, and [[:digit:]] is the POSIX version, so I guess it's just a case of different implementations.

The funny thing is that \d works in my system's grep!

Ben Addis <faxanadu>
Tue 18 Feb 2020 03:54:59 PM UTC, comment #2: 

In gnulib, lib/dfa.c only recognizes \s, \S, \w, and \W, not \d and \D.  That code comes from grep, and 'info grep regular the' (that is: section 3.3) documents eight special backslash sequences, but \d and \D are not among them.

So... if you want to have \d and \D recognized, I think you will have to post a feature request to the gnulib maintainers.

Benno Schulenberg <bens>
Group administrator
Tue 18 Feb 2020 03:07:13 PM UTC, comment #1: 

Strange.  \w, \W, \s, and \S work fine.  But \d and \D don't.  :|

I don't think this is a bug or deficiency in nano, but in gnulib.  Nano links against the regex module of gnulib (you can check with 'objdump -t src/nano | grep rpl_'), and that module should handle all regular expressions.

(I didn't know that \d stands for [0-9], but
https://www.regular-expressions.info/shorthand.html says it does.  I haven't dug into the gnulib code to see whether it is supposed to support \d.)

Benno Schulenberg <bens>
Group administrator
Tue 18 Feb 2020 02:28:05 PM UTC, original submission:  

nano 4.7
macOS Catalina 10.15.3

Expected behaviour: `\d` and `\D` in a regular expression search are equivalent to `[0123456789]` and `[^0123456789]`


Actual behaviour: `\d` results in `[ "\d" not found ]` (even when a literal '\d' exists in the text)

`\D` results in finding a literal 'd' or 'D' character

Ben Addis <faxanadu>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by faxanadu (Submitted the item)
  • -email is unavailable- added by faxanadu
  •  

    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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-21 bens Open/ClosedOpen Closed
    2020-02-18 bens StatusNone Confirmed
    2020-02-18 faxanadu Carbon-Copy- Added faxanadu

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code