https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252446
Kyle Evans <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |[email protected], | |[email protected] Assignee|[email protected] |[email protected] --- Comment #1 from Kyle Evans <[email protected]> --- (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@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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
