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

[Fulvio Scapin]

Hello Bob.

Yes, I did write to bug-gzip after writing here, this being not the
right place to begin with.
I got confused trying to reuse the old thread to comment upon the issue.
And it turns out that you are right as well about the bug. I was too
hasty and didn't check things properly.
i guess I had worked a little too much that day. I was in the middle
of opening an issue for the zstd wrapper zstdgrep regarding the
contents of my old zgrep issue.
I was convinced that the distro I was using, being from 2018, shipped
with a more recent version of gzip than the 1.6 which had the issue.
It turns out that it didn't.
And then I kept looking at the history of zgrep.1 instead of zgrep.in
in the cgit of Savannah to compound my mistake.
So too much baseless convinction for one day :) And fortunately it was
just my blunder.

Thanks for the check and sorry to have wasted your time needlessly.

Fulvio

Il giorno sab 4 apr 2020 alle ore 19:49 Bob Proulx <address@hidden> ha scritto:
>
> 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
> >