[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21414: -F string with tailing newline always matches
From: |
Ian Brown - HNAS |
Subject: |
bug#21414: -F string with tailing newline always matches |
Date: |
Tue, 8 Sep 2015 12:16:15 +0000 |
My code was in Ruby and that preserves the newlines
irb(main):001:0> `printf 'abc\n'|grep "#{`printf 'xyz\n\n\n'`}"`
=> "abc\n"
irb(main):002:0>
Didn't think to look under NEWS .. thanks.
-----Original Message-----
From: Paul Eggert [mailto:address@hidden
Sent: 07 September 2015 16:11
To: Ian Brown - HNAS
Cc: address@hidden
Subject: Re: bug#21414: -F string with tailing newline always matches
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:
https://urldefense.proofpoint.com/v2/url?u=http-3A__bugs.gnu.org_17240&d=BQICaQ&c=DZ-EF4pZfxGSU6MfABwx0g&r=oUyQxD5D078svVweHQscGciDxD5YHkgZqUu_H1lDr_I&m=ydFOQe7IjFmk2xPA2Strddr1vCireNQ7FIIh9ERiCZE&s=n855GH9cvWAZ_PXYT1pr1MEszacQw0CsW9bVR5WcUAk&e=