Re: option `-o' for regular file

[Adam Tuja]

Hello,
Don't thank me for good words, I do it for myself and for others as well. The 
program is a product, making it more functional therefore more appealing and 
popular is good not bad thing. Every product without customers sooner rather 
then later dies off. I know it from my own experience.

> 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.

First, I'm not big programmer so don't look at "the patch" too harshly as it's 
more like monkey, or guerilla if you like, patch - to adjust it and see how it 
works. As it turned out to work and cooperate with my application I posted it 
but I know exactly well how partisan it is. It also has this advantage of being 
quick way to apply and test it, by other party as well. I didn't say it's fully 
industrial solution, I'm not that good. Einstein wasn't good at maths either.


> 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
>

I stand corrected; manual to `-o' option doesn't say a word about that `-' and 
example 9 does not have `-' as file name but works nevertheless. Now I know 
it's because there are no more arguments and it's assumed to be standard input 
but still it is not mentioned 
Which brings me to the point that there is no fundamental difference between:
```
$ lzip -k -o file1.out - < file1.in file2 file3
```
and
```
$ lzip -k -o file1.out file1.in file2 file3
```

What I propose is to make it more general and accept all files, whether regular 
or `stdin'. After all there is only one standard input so there can be only one 
output for it, same if it accepted regular files there would be only one output 
for every `-o' input (in most general case).


>>  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*')
>
> 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. 

It's not good argument. Not everything that bzip2 does, or doesn't for that 
matter, is good. It doesn't provide uncompressed size either and everyone I 
know is annoyed and even put off by that. I do think that they could get over 
those 8 bytes, it wouldn't hurt but it would help.

> whatever those
> archivers do to decompress bzip2 files they can do to decompress lzip files.

In fact they don't. I mean there is no good way to add bzip2 to MultiArc or Far 
archiver for that very reason. They use dedicated plugins to decompress bzip2 
files, and they still face the same problem/s; "uncompressed" names are 
generated internally.

> 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. 

I know that.

> (...) 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.

That's my point - I show you 'a need' for it. Even thought up a simple way to 
do it - '-ll' in mainc:
```
int list = 0;
(...)
case 'l': if (!list) { set_mode( &program_mode, m_list ); } list++; break;
```

and then in licst.c:list_files():
```
input_filename = from_stdin ? "(stdin)" : filenames[i];
if (list>1)
    input_filename = strip_ext(input_filename); // pseudo code, it's not a 
python or anything
(...)
list_line( udata_size, cdata_size, input_filename );
```

Regards
Adam

PS. In my opinion `-o' option appends '.lz' excessively (during compression, 
decompression is fine).
```
$ lzip -o file1.out < file1.in
$ ls
file1.in  file1.out.lz
```
Why would user go to the bother and specify output filename and then got 
something else.
I personally don't like juggle with standard in/out if don't need to and often 
use names like 'archive.lz-7', or 'archive.lz-b10M'. If I need extension I add 
it, I'm responsible form my actions.