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.
