We've recently changed 'gzip -l' so that it displays the correct
uncompressed size, and this change should appear in the next gzip release.
As that seemed to be the primary motivation for suggesting 'gzip -t' to
display the size, I'm taking the liberty of closing Bug#32903 dated
2018-10-02.
On Sun, 4 Nov 2018 21:54:59 +0200, Sergey Ponomarev wrote:
> From user point of view it would be better not to enclose the size
> into brackets: it will be easier to parse the output by other tools.
Good point, here’s an updated patch (I hesitated between "xxx bytes OK" and
"OK xxx bytes" but wen
Thanks for explanation,
>From user point of view it would be better not to enclose the size
into brackets: it will be easier to parse the output by other tools.
On Sun, 4 Nov 2018 at 21:39, Stephen Kitt wrote:
> Hi Sergey,
>
> On Sun, 4 Nov 2018 14:49:50 +0200, Sergey Ponomarev
> wrote:
> > >
Hi Sergey,
On Sun, 4 Nov 2018 14:49:50 +0200, Sergey Ponomarev wrote:
> > Alongside the OK message, print the real size in bytes; this provides
> a way to view the stored file's size when it's larger than 4GiB.
>
> You can get a real size by `gzip --list` command. Why to show the size in
> `gz
> Alongside the OK message, print the real size in bytes; this provides
a way to view the stored file's size when it's larger than 4GiB.
You can get a real size by `gzip --list` command. Why to show the size in
`gzip --test` output? Almost all other compressors (lzop, xz, bzip2, etc0
just shows th
Alongside the OK message, print the real size in bytes; this provides
a way to view the stored file's size when it's larger than 4GiB.
Signed-off-by: Stephen Kitt
---
gzip.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gzip.c b/gzip.c
index e6a7761..4104472 100644
---
