GNU bug report logs - #22945
Surprising behaviour (bug?) of zgrep in combination with the -f option and process substitutions

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Fulvio Scapin <trantorvega <at> gmail.com>, 22945 <at> debbugs.gnu.org
Subject: bug#22945: Surprising behaviour (bug?) of zgrep in combination with the -f option and process substitutions
Date: Thu, 17 Mar 2016 20:58:14 -0700

On Thu, Mar 17, 2016 at 1:13 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 03/16/2016 02:06 PM, Paul Eggert wrote:
>>
>> I have worked on a patch but don't have a reliable fix yet, or even a
>> portable test case to illustrate the bug.
>
> On further thought I found a test case and a fix, which I've attached.
> Normally I would just install this, but we're so close to a release that
> I'll wait for a word from Jim.

Thank you for working on that.
One nit: perhaps it should continue to work when a search string
contains a NUL byte?  E.g., this works before your change on OS X
yet finds no match with the patch applied:

  $ zgrep -af <(printf 'b\0\na') <(printf 'b\0') <(echo a)
  /dev/fd/12:b
  /dev/fd/13:a

Might be tricky to portably transform that NUL byte into something we
can embed in a command-line-specified search string. Is there even a
notation for that? I don't think so.

But NUL problems aside, this also should work, requiring alternation
in the regexp derived from input with two or more lines, but then
we'll have to escape embedded '|' bytes, too:

  $ zgrep -f <(printf 'a\nb') <(echo b) <(echo a)
  /dev/fd/12:b
  /dev/fd/13:a

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.