[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21414: -F string with tailing newline always matches
From: |
Paul Eggert |
Subject: |
bug#21414: -F string with tailing newline always matches |
Date: |
Mon, 7 Sep 2015 08:11:29 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
Ian Brown - HNAS wrote:
the pattern list used was the output of another command, it now needs to have
the terminating newline removed.
Typically the issue occurs with grep -f. If the pattern list is generated via
the shell, like this:
grep "$(somecmd)" file
then the shell removes all trailing newlines from the output of SOMECMD, so it
is not a problem in this case. The shell even strips multiple trailing
newlines, which in hindsight is probably a mistake but is standard behavior.
So, for example:
printf 'abc\n' | grep "$(printf 'xyz\n\n\n')"
does not output any matches, but:
printf 'xyz\n\n\n' >pattern; printf 'abc\n' | grep -f pattern
outputs a match for abc, because the empty pattern matches every line.
I didn't find any mention of this change of behaviour in the change logs
The change is listed in NEWS under grep-2.19 bug fixes, like this:
grep no longer mishandles an empty pattern at the end of a pattern list.
[bug introduced in grep-2.5]
This is due to commit 2d3832e1ff772dc1a374bfad5dcc1338350cc48b dated Fri Apr 11
21:34:11 2014 +0900. Here is the ChangeLog entry.
2014-04-11 Norihiro Tanaka <address@hidden>
grep: no match for the empty string included in multiple patterns
* src/dfasearch.c (EGAcompile): Fix it.
* src/kwsearch.c (Fcompile): Fix it.
This fixes Bug#17240, which essentially is the negation of your bug report,
i.e., Bug#17240 asks for the standard grep behavior which we broke in grep 2.5.
You can see that bug report here:
http://bugs.gnu.org/17240
- bug#21414: -F string with tailing newline always matches,
Paul Eggert <=