Re: Fix for bug #22945 misteriously vanished from the tree?

[Bob Proulx]

I am not an expert on this but since there is not a response yet I
will volunteer what I know about it.

I see that bug#22945 is archived.  In order to add to that bug ticket
it will need to be "unarchived".  I removed the bug address from this
reply to avoid confusion until then.

  https://www.debian.org/Bugs/server-control#unarchive

To unarchive an archived bug report one may send this type of message
to the control server.  (Pretty sure.  I usually use the 'bts' command
line helper.  Sorry but I didn't test this.)

  echo unarchive 22945 | mailx -s request address@hidden

After the bug is unarchived then it would be available for further
comment.  Until then, while archived, it is not.

As to the rest of your question and information, that is really more
suitable for the bug report or for the bug-gzip mailing list.  As we
are really only knowledgeable about the BTS on debbugs here.

However when I clone the gzip sources and look in the version history
for zgrep.in I see the commit in the history of that file.  It's
there.  There is a test for the behavior in the tests/zgrep-f file.
When I look at the current source to the zgrep.in script I see that it
includes that change, making a copy of the pattern file.  Look for the
string pattern "not a regular file" to see the code there.  I am
looking at the current master which is post the v1.10 release.

Perhaps your sandbox copy is on a different branch and that is why you
are not observing it in your copy?

Remember that I am just an outside observer in this.  The bug-gzip
mailing list would be a better place to ask questions about gzip.  It
may be that I am very confused about the question.

Bob

Fulvio Scapin wrote:
> Today I was about to post a bug for the zstdgrep wrapper of zstd and
> as a comparison I was about to quote the fix for bug #22945 which I
> myself opened around 4 years ago.
> I was using the command to reproduce the bug to show how zgrep
> processes things correctly to suddenly discover that it doesn't.
> From the 1.7 changelog of gzip I read, under "Bug fixes"
> [...]
>  zgrep -f A B C no longer reads A more than once if A is not a regular file.
>   This better supports invocations like 'zgrep -f <(COMMAND) B C' in Bash.
>   [bug introduced in gzip-1.2]
> [...]
> In the Savannah cgit I can find commit 
> f0bda0b75a28f6fd2069600f19f7eafa569545e6
> 
> ( 
> http://git.savannah.gnu.org/cgit/gzip.git/commit/?id=f0bda0b75a28f6fd2069600f19f7eafa569545e6
> ) which affects zgrep.in, NEWS and tests/zgrep-f
> 
> However in the history of the current zgrep.in I see no traces of
> either the commit or its modifications, while I see both in the other
> two files.
> 
> Empirically I see, for instance, that the contents of the zgrep
> wrapper shipped with versions 1.6 and 1.8 of gzip are identical.
> 
> Which means that the bug is not actually close at all AFAIC.
> 
> Have I gone mad and started seeing things which are not there?
> And if not has anything else been lost along the way?
> 
> Regards,
> Fulvio Scapin
>