Re: Re: Writing de/compressed data to a terminal policy

[wrotycz]

This makes sense and (because of that) is what other programs are

doing.

Just because others do that doesnt make it right.

lzip: I won't write compressed data to a terminal.

Why so? lzip output in this case is binary data, which is (99%) useless

output on a user terminal

I get that, and I said that too.

Compare that to uncompressing a file directly on the terminal:

$ < hello.lz lzip -d

Hello world

Why do you forbid writing binary data during compression and slow during decompression?

~~~

$ head -c 100 /dev/urandom | lzip -c > test.bin

$ lzip -dc test.bin.lz

@£&_)(&@##!&_:":)+=#&&;(==_(/+

...

~~~

That is inconsistent.

The issue about nul being wrongly detected as a tty in Windows seems a

How do you know it is wrong/wrongly detected?

I did not say that.

More over, I say that it is right, but it should be avoidable, so to speak. User should be able to force writing into terminal with -f/--force. If user takes effort to write --force it means they mean that, they know what they are doing, and it should be respected.

At least in windows it is necessary to have such option.

Just checked, and gzip and bzip2 allow writing to nul, no problem, and pigz allow to force it.

~~~

% gzip -c test.txt > nul

% bzip2 -c test.txt > nul

% pigz -c test.txt > nul

pigz.exe: abort: trying to write compressed data to a terminal (use -f to force)

% pigz -f -c test.txt > nul

~~~

And thats how it should be, and thats what I postulate.

Regards.