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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Fulvio Scapin <trantorvega <at> gmail.com>
Subject: bug#22945: closed (Re: bug#22945: Surprising behaviour (bug?) of
 zgrep in combination with the -f option and process substitutions)
Date: Fri, 18 Mar 2016 22:31:02 +0000

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

Your bug report

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

which was filed against the gzip package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 22945 <at> debbugs.gnu.org.

-- 
22945: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22945
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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

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

On 03/18/2016 01:24 PM, Jim Meyering wrote:
> You are welcome to push that with changes like the following:
OK, thanks, I pushed the attached patch, which contains those changes, 
plus one more change: check for errors when writing to the temporary 
pattern file. Marking this as done.

[0001-zgrep-with-f-SPECIAL-read-SPECIAL-just-once.patch (application/x-patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Fulvio Scapin <trantorvega <at> gmail.com>
To: bug-gzip <at> gnu.org
Subject: Surprising behaviour (bug?) of zgrep in combination with the -f
 option and process substitutions
Date: Tue, 8 Mar 2016 12:42:30 +0100

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

Hello.

There is a problem with zgrep whenever the -f option actually reads from
the output of a process substition in bash.
A willingly trivial example below.

$ mkdir /tmp/test

$ cd /tmp/test

$ cat > first
aaa

$ cat > second
bbb

$ cat > third
ccc

$ cat > fourth
ddd

$ tail *
==> first <==
aaa

==> fourth <==
ddd

==> second <==
bbb

==> third <==
ccc

$ gzip -9 *

$ ls
first.gz  fourth.gz  second.gz  third.gz

$ cat > patterns
aaa
bbb
ccc
ddd

$ tail patterns
aaa
bbb
ccc
ddd

$ zfgrep -f <( cat patterns ) first.gz fourth.gz second.gz third.gz
first.gz:aaa

$ zfgrep -f patterns first.gz fourth.gz second.gz third.gz
first.gz:aaa
fourth.gz:ddd
second.gz:bbb
third.gz:ccc



zfgrep -f <( cat patterns ) first.gz fourth.gz second.gz third.gz
translates in
zfgrep -f /dev/fd/XX first.gz fourth.gz second.gz third.gz
where XX is a number, 63 for instance .

The problem, from what I understand, arises since

zgrep -f patternfile a.gz b.gz c.gz

actually is a succession of

gzip -dc a.gz | grep -f patternfile
gzip -dc b.gz | grep -f patternfile
gzip -dc c.gz | grep -f patternfile


Since patternfile in this case is /dev/fd/XX, only the first invocation of
grep in the first pipeline actually reads a pattern list, while the second
and third invocation get nothing, giving no match for b.gz and c.gz as a
result.


From /bin/zgrep (Version 1.6, Ubuntu 15.10) one can read

  (-f | --file)
   # The pattern is coming from a file rather than the command-line.
   # If the file is actually stdin then we need to do a little
   # magic, since we use stdin to pass the gzip output to grep.
   # Turn the -f option into an -e option by copying the file's
   # contents into OPTARG.
   case $optarg in
   (" '-'" | " '/dev/stdin'" | " '/dev/fd/0'")
     option=-e
     optarg=" '"$(sed "$escape") || exit 2;;
   esac
   have_pat=1;;

The workaround concerning stdin should (maybe) also apply to situations
such as the one in my example?

Thanks in advance.

Fulvio Scapin

[Message part 7 (text/html, inline)]

Previous Next

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