Date: Tue, 05 Jan 2021 20:30:53 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 252446] egrep bug with trailing backslash (\) Message-ID: <bug-252446-227-YAzTs0deoX@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-252446-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252446 Kyle Evans <kevans@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |bugs@FreeBSD.org, | |olivier@freebsd.org Assignee|bugs@FreeBSD.org |kevans@freebsd.org --- Comment #1 from Kyle Evans <kevans@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@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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252446-227-YAzTs0deoX>