Seems like too extreme of a behavior change. If this proposal is implemented,
then 99.9% of the time, pigz -l will decode the entire file. If someone is
regularly doing pigz -l on a large number of files, the time it would take
would go up orders of magnitude.
The fundamental dilemma is that gz
On 8/9/21 8:19 AM, Adler, Mark wrote:
pigz -l doesn’t do that, but pigz -lt does. Since -t has to decode the whole
file, -l combined with it will use that information to give the correct result.
For compatibility, pigz -l still does what gzip does, which is to guess based
on what it finds at t
pigz -l doesn’t do that, but pigz -lt does. Since -t has to decode the whole
file, -l combined with it will use that information to give the correct result.
For compatibility, pigz -l still does what gzip does, which is to guess based
on what it finds at the end of the file.
> On Aug 9, 2021, a
On 8/9/21 1:02 AM, Stephen Kitt wrote:
Is there any chance
https://lists.gnu.org/archive/html/bug-gzip/2018-12/msg00010.html could
be considered?
Better than that, why not just have 'gzip -l' print the correct number,
by decompressing the whole file and discarding its bytes? That's what
pi
Hi,
Le 09/08/2021 07:37, Jim Meyering a écrit :
NEWS (below) is nearly empty, but it's been more than 2.5 years since
the last release, so I am now preparing to make a new one. Any testing
would be most welcome. If anyone has pending changes, please speak
soon. I aim to release in just a few
Hello Jim,
Op 09-08-2021 om 07:37 schreef Jim Meyering:
> https://meyering.net/gzip/gzip-1.10.34-aa73.tar.xz
This package does not contain a POT file. Please do not send me
an announcement for packages that are not translatable.
Benno
NEWS (below) is nearly empty, but it's been more than 2.5 years since
the last release, so I am now preparing to make a new one. Any testing
would be most welcome. If anyone has pending changes, please speak
soon. I aim to release in just a few days.
gzip snapshot:
https://meyering.net/gzip/g
