Not sure this bug characterization is correct, but this is how it appeared to me. Also, not sure if CURRENT is correct choice for "Version"; this is on MacOS Sierra 10.12.4: $ grep -V grep (BSD grep) 2.5.1-FreeBSD I apologize if either assumption is incorrect. Some examples: $ echo x xx | grep -w x x xx $ #CORRECT $ echo xx x | grep -w x xx x $ #CORRECT $ echo x xx | grep -v -w x $ #CORRECT $ echo xx x | grep -v -w x xx x $ #INCORRECT
This reproduces in FreeBSD, using "bsdgrep" in place of "grep." Notably, bsdgrep is not yet "grep" on FreeBSD systems because it is known to be broken in some ways. It is kind of amusing that MacOS uses it for grep. Kyle Evans has been doing some work to improve bsdgrep lately, this may be something he is already tracking (or maybe something new).
Hi, Thanks for the awesome test case! I've diagnosed and fixed this with bsdgrep(1) and created a patch+review [1] and introduced a test for -w -v behavior based on your examples. Thanks, Kyle Evans [1] https://reviews.freebsd.org/D10329
You're welcome. Good work!
A commit references this bug: Author: emaste Date: Tue May 2 02:32:10 UTC 2017 New revision: 317665 URL: https://svnweb.freebsd.org/changeset/base/317665 Log: bsdgrep: fix -w -v matching improperly with certain patterns -w and -v flag matching was mostly functional but had some minor problems: 1. -w flag processing only allowed one iteration through pattern matching on a line. This was problematic if one pattern could match more than once, or if there were multiple patterns and the earliest/ longest match was not the most ideal, and 2. Previous work "fixed" things to not further process a line if the first iteration through patterns produced no matches. This is clearly wrong if we're dealing with the more restrictive -w matching. #2 breakage could have also occurred before recent broad rewrites, but it would be more arbitrary based on input patterns as to whether or not it actually affected things. Fix both of these by forcing a retry of the patterns after advancing just past the start of the first match if we're doing more restrictive -w matching and we didn't get any hits to start with. Also move -v flag processing outside of the loop so that we have a greater change to match in the more restrictive cases. This wasn't strictly wrong, but it could be a little more error prone. While here, introduce some regressions tests for this behavior and fix some excessive wrapping nearby that hindered readability. GNU grep passes these new tests. PR: 218467, 218811 Submitted by: Kyle Evans <kevans91 at ksu.edu> Reviewed by: cem, ngie Differential Revision: https://reviews.freebsd.org/D10329 Changes: head/contrib/netbsd-tests/usr.bin/grep/t_grep.sh head/usr.bin/grep/util.c
A commit references this bug: Author: kevans Date: Wed Aug 16 17:42:39 UTC 2017 New revision: 322583 URL: https://svnweb.freebsd.org/changeset/base/322583 Log: MFC r317665: bsdgrep: fix -w -v matching improperly with certain patterns -w and -v flag matching was mostly functional but had some minor problems: 1. -w flag processing only allowed one iteration through pattern matching on a line. This was problematic if one pattern could match more than once, or if there were multiple patterns and the earliest/ longest match was not the most ideal, and 2. Previous work "fixed" things to not further process a line if the first iteration through patterns produced no matches. This is clearly wrong if we're dealing with the more restrictive -w matching. #2 breakage could have also occurred before recent broad rewrites, but it would be more arbitrary based on input patterns as to whether or not it actually affected things. Fix both of these by forcing a retry of the patterns after advancing just past the start of the first match if we're doing more restrictive -w matching and we didn't get any hits to start with. Also move -v flag processing outside of the loop so that we have a greater change to match in the more restrictive cases. This wasn't strictly wrong, but it could be a little more error prone. While here, introduce some regressions tests for this behavior and fix some excessive wrapping nearby that hindered readability. GNU grep passes these new tests. PR: 218467, 218811 Approved by: emaste (mentor, blanket MFC) Changes: _U stable/11/ stable/11/contrib/netbsd-tests/usr.bin/grep/t_grep.sh stable/11/usr.bin/grep/util.c