Re: option `-o' for regular file

[Antonio Diaz Diaz]

Hello Tuja,

Thanks for your nice words about lzip. :-)

Adam Tuja wrote:
> $ lzip -k -d -o "dog9" "fox6.lz"

This is an interesting suggestion. If I understand it correctly, you are 
suggesting that -o behaves just like -c, but sending the output 
unconditionally to a file instead of to standard output. Right?


> As it is now it works only in "single file mode" anyways so it wouldn't
> hurt if it was usable with regular file not only stdin. And a single file
> only.
> [...]
> # but when combined with more file names it doesn't:
> [...]
> $ cat a1 | lzip -k -f -o a1.lz b2

As you can see in the --help output of lzip, "If no file names are given, or 
if a file is '-', lzip compresses or decompresses from standard input to 
standard output."

If file name(s) are given, then you must include a hyphen '-' to tell lzip 
to read standard input:

$ cat a1 | lzip -k -v -o a1.lz - b2
  (stdin):  0.077:1, 1300.00% ratio, -1200.00% saved, 3 in, 39 out.
  b2:       0.077:1, 1300.00% ratio, -1200.00% saved, 3 in, 39 out.
$ ls
a1  a1.lz  b2  b2.lz


> As a matter of fact I "patched" clzip to make it work and it cooperates
> with MultiArc fine.

Thanks. As it is, your patch does not work with more than one input file. A 
completely different approach is needed to make -o work reliably with any 
number of input files.

I was going to announce lunzip 1.12-rc1 today (released 2 days ago), but 
I'll delay the release of all lzip tools until I find a way to specify and 
implement this feature. Neither gzip nor bzip2 provide the option -o, so we 
need to think carefully how to implement it.


> As we are on the subject would be good to add option to list command that
> would display file name stripped of extension (`.lz'/`.lz*') which would
> add functionality to plugins like Multiarc or Far archiver to add lzip as
> another unpacker. Now, when it shows `archive.lz' in listing Multiarc
> user sees internal file name as `archive.tar.lz' not `archive.tar'. This
> way manager thinks that in `archive.tar.lz' there is another
> `archive.tar.lz'. It still can be unpacked (decompressed really) but name
> suggests it is `.tar.lz' archive when in fact it's `.tar'.

I do not think that stripping the extension is the right way to fix this.

To begin with, bzip2 does not provide the option --list. So, whatever those 
archivers do to decompress bzip2 files they can do to decompress lzip files.

A compressed file is not an archive (even if it can contain one). 'lzip -l' 
is not like 'tar -t' or 'unzip -l'. It does not show the "internal file 
name". It shows some information (sizes, number of members,...) about a 
compressed file, whose name is also shown. Much like 'file' does:

$ file fox.lz
fox.lz: lzip compressed data, version: 1

The reason why gzip shows the 'uncompressed_name' (as archivers do) is that, 
for historical reasons, it stores the uncompressed name in its header. 
AFAIK, gzip is the only compressor doing this. It makes sense for gzip to 
show the uncompressed name because it may be arbitrarily different from the 
compressed name. But for other compressors (bzip2, lzip), the decompressed 
name is always the compressed name minus the extension (or .tlz --> .tar). 
There is no need to call 'lzip -l' to know what the decompressed name is.


Best regards,
Antonio.