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: Fri, 18 Mar 2016 13:24:55 -0700

[Message part 1 (text/plain, inline)]

On Fri, Mar 18, 2016 at 12:46 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Jim Meyering wrote:
>>
>> 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:
>
>
> How about the attached patch instead? It uses a bigger hammer, which should
> address both issues.

Very nice. Thank you very much.
You are welcome to push that with changes like the following:
 - retain the 2-empty-line section separator in NEWS (there's a
syntax-check hook to test for that in other packages, but not yet here
in gzip)
 - adjust the test to cover the case of more than one line in -f's input:

[k.patch (text/x-patch, attachment)]

Previous Next

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