On Fri, Sep 4, 2015 at 10:34 AM, Paul Eggert <egg...@cs.ucla.edu> 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.
