[Bug 252446] egrep bug with trailing backslash (\)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252446

Kyle Evans <kevans at freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |In Progress
                 CC|                            |bugs at FreeBSD.org,
                   |                            |olivier at freebsd.org
           Assignee|bugs at FreeBSD.org            |kevans at freebsd.org

--- Comment #1 from Kyle Evans <kevans at freebsd.org> ---
(In reply to fernando.valle from comment #0)

Hi,

Thanks! I received a report just earlier today about this, too; what's going on
here is that bsdgrep doesn't know that \t means tab and neither does the
underlying regex engine (this is correct by the spec). The underlying regex
engine rejects it now because it doesn't have any special meaning.

Interestingly enough, this only worked by coincidence with gnugrep. gnugrep
*also* doesn't understand \t => tab but instead opted to just silently
interpret it as a 't'. The reason it appears to succeed is that the pattern
argument breaks down like so (with \t translated to t):

<<EOF
[0-9]+ttestdir/A/B
testdir/A
testdir/C
testdir
EOF

Note that this is four (4) distinct patterns; the first one never matches,
while the latter three do. You can confirm this with gnugrep -o (I manually ran
the test here):

<<EOF
root at viper:/usr/tests/usr.bin/du# /usr/local/bin/grep -E "[0-9]+\t$(echo
"testdir/A/B testdir/A testdir/C testdir" | tr ' ' "\n[0-9]+\t")\n" -o du.out
testdir/A
testdir/A
testdir/C
EOF

I will fix the test.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.