Re: [Lzip-bug] Regarding Verbose Output for Decompression in Lzip

[Timothy Beryl Grahek]

Hi Antonio,

Glad to hear your comments.

> Following the user interface of bzip2, lzip shows "done" when 
> decompressing. When compressing, just the sizes, etc, are shown, 
> because there is no integrity to be checked during compression.
>
> The behavior is similar to that of md5sum:
>
> $ md5sum rfc6557.txt
> 4fe6ac0511d7ffce4cddb6985ec763ac  rfc6557.txt
> $ md5sum -c rfc6557.txt.md5
> rfc6557.txt: OK 

I definitely agree with this decision.

> It seems that '-g' has been just adopted by POSIX compress to mean 
> "Use the deflate algorithm"[1]. Maybe we can use '-p, --progress' if 
> finally a new option is needed.
>
> [1] http://austingroupbugs.net/view.php?id=1041
Does it concern you that -p deals with permissions in programs such as 
cp? I mildly dislike capitalization, but would you happen to think -P is 
more desirable than -p to avoid confusion with other utilities such as cp?

> Even in this case, '-vv' could be left as is for compression, for 
> backward compatibility. 

I definitely agree with keeping backward compatibility.

> Thank you. Your help is welcome. :-) 

Sounds very good to me. :)

Bzip2 offers for compression generally unhelpful output to the layperson 
when specifying '-vv1' as an option:

   bzip2 -vv1 FreeBSD.vhd
      FreeBSD.vhd:
        block 1: crc = 0xe41ef92f, combined CRC = 0xe41ef92f, size = 99983
        too repetitive; using fallback sorting algorithm
        block 2: crc = 0x1b4f3d64, combined CRC = 0xd372cf3b, size = 99981
        too repetitive; using fallback sorting algorithm
        block 3: crc = 0x7e49bae6, combined CRC = 0xd8ac2491, size = 99981
        too repetitive; using fallback sorting algorithm
        block 4: crc = 0x59575531, combined CRC = 0xe80f1c12, size = 99981
        too repetitive; using fallback sorting algorithm
        block 5: crc = 0xf186f7ed, combined CRC = 0x2198cfc8, size = 99981
        block 6: crc = 0x7badf0ec, combined CRC = 0x389c6f7c, size = 99981
        block 7: crc = 0x2827d422, combined CRC = 0x591f0ada, size = 99984
        block 8: crc = 0xc038cf40, combined CRC = 0x7206daf4, size = 99981
        too repetitive; using fallback sorting algorithm
        block 9: crc = 0x4be26586, combined CRC = 0xafefd06e, size = 99985
        too repetitive; using fallback sorting algorithm
        block 10: crc = 0x7de6a9dc, combined CRC = 0x22390901, size = 99983
        too repetitive; using fallback sorting algorithm
        block 11: crc = 0xe3cd14b6, combined CRC = 0xa7bf06b4, size = 99983
        too repetitive; using fallback sorting algorithm
        block 12: crc = 0x4a508b70, combined CRC = 0x052e8619, size = 99985
        too repetitive; using fallback sorting algorithm
        block 13: crc = 0x058181b5, combined CRC = 0x0fdc8d87, size = 99981
        block 14: crc = 0xb438ff93, combined CRC = 0xab81e49d, size = 99981
        block 15: crc = 0x74424b9c, combined CRC = 0x234182a7, size = 99981
        block 16: crc = 0x2a83d6ce, combined CRC = 0x6c00d380, size = 99981
        etc.

Using Bzip with a single verbose option produces what I expect:

   bzip2 -v1 FreeBSD.vhd
      FreeBSD.vhd:

When finished compressing a file, the output is similar, even identical, 
to Lzip:

   FreeBSD.vhd:  3.714:1,  2.154 bits/byte, 73.07% saved, 1267034624
   in, 341187804 out.

Bzip2 offers similarly unhelpful output for decompression using '-vvd' 
when you consider the layperson:

   bzip2 -vvd FreeBSD.vhd.bz2
      FreeBSD.vhd.bz2:
        [1: huff+mtf rt+rld]
        [2: huff+mtf rt+rld]
        [3: huff+mtf rt+rld]
        [4: huff+mtf rt+rld]
        [5: huff+mtf rt+rld]
        [6: huff+mtf rt+rld]
        [7: huff+mtf rt+rld]
        [8: huff+mtf rt+rld]
        [9: huff+mtf rt+rld]
        etc.

A single verbose option is reasonable, like it is in compression:

   bzip2 -vd FreeBSD.vhd.bz2
      FreeBSD.vhd.bz2:

When it's finished, the output is similar, even identical, to the output 
of Lzip:

   bzip2 -vd FreeBSD.vhd.bz2
      FreeBSD.vhd.bz2: done

So, yeah, in conclusion, Bzip2 offers no percentage information in its 
compression or decompression options when considering up to specifying 
second level verbosity. If Lzip could provide percentages for both 
options, with verbose option or another option such as what has been 
suggested, it would be superior in providing information to users, among 
Lzip's being superior in many other ways. ;)

Best regards,

Timothy Beryl Grahek




On 08/28/2017 11:32 AM, Antonio Diaz Diaz wrote:
> Hi Timothy. Thanks for your comments.
>
> Timothy Beryl Grahek wrote:
> > if Lzip could keep that same final output while having an
> > implementation for progress, that would be highly desirable.
>
> This is what I intend to do.
>
>
> > I notice that the word 'ok' does not appear at the end if you are
> > either compressing or decompressing an archive, but it does appear
> > when testing an archive.
>
> Following the user interface of bzip2, lzip shows "done" when 
> decompressing. When compressing, just the sizes, etc, are shown, 
> because there is no integrity to be checked during compression.
>
> The behavior is similar to that of md5sum:
>
> $ md5sum rfc6557.txt
> 4fe6ac0511d7ffce4cddb6985ec763ac  rfc6557.txt
> $ md5sum -c rfc6557.txt.md5
> rfc6557.txt: OK
>
>
> > Lastly, a '-g' option seems like a good choice if '-vv' won't work.
>
> It seems that '-g' has been just adopted by POSIX compress to mean 
> "Use the deflate algorithm"[1]. Maybe we can use '-p, --progress' if 
> finally a new option is needed.
>
> [1] http://austingroupbugs.net/view.php?id=1041
>
>
> > If you do go with that, what makes the most sense to me is if you
> > remove the progress indicator in compression when specifying '-vv'
> > and then opting for progress for both operations when specifying the
> > '-g' option.
>
> Even in this case, '-vv' could be left as is for compression, for 
> backward compatibility.
>
>
> > I can check this for you,
>
> Thank you. Your help is welcome. :-)
>
>
> Best regards,
> Antonio.
>
> _______________________________________________
> Lzip-bug mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lzip-bug