[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: option `-o' for regular file
Antonio Diaz Diaz
Re: option `-o' for regular file
Fri, 08 May 2020 23:22:56 +0200
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:188.8.131.52) Gecko/20110420 SeaMonkey/2.0.14
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
# 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
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.
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.