bug#21414: -F string with tailing newline always matches

[Jim Meyering]

On Fri, Sep 4, 2015 at 10:34 AM, Paul Eggert <address@hidden> wrote:
> On 09/04/2015 07:45 AM, Ian Brown - HNAS wrote:
>>
>> Grep version 2.20
>>
>> When using the ouput of another command to pass match strings into grep
>> using -F I was getting unexpected results as it was matching every line. If
>> the terminating newline is removed the grep started to work again.
>>
>> Easy to work around but this is different behaviour from 2.12 and may
>> cause some scripts to fail.
>>
>> Ian Brown (HDS)
>>
>
> I assume you're referring to the following sort of behavior:
>
> $ printf 'abc\n\ndef\n' >foo
> $ grep -F 'abc
> ' foo
> abc
>
> def
>
> Older versions of GNU grep would ignore the newline after 'abc' in the
> pattern, and would output only 'abc' with the above example. This behavior
> was incompatible with non-GNU grep implementations and with POSIX, and the
> incompatibility seemed to be unintended and not that useful and was fixed at
> some point (sorry, don't know the GNU grep version).  Sorry you were relying
> on it.

Thank you for the report.
I too find this behavior surprising:

$ seq 3|grep -F xxx$'\n'
1
2
3

This feels like a bug, since it's an artifact of how grep accumulates
multiple keys internally: it uses newline as the separator
(http://git.savannah.gnu.org/cgit/grep.git/tree/src/grep.c#n2308).
Including a literal newline in the search string conflicts with that.
I haven't investigated feasibility, but we be able to make it use \0
as the separator, to avoid this.