Paul Eggert wrote:
I think I'd rather have tar assume the gzip exit-status
convention, and depart from that only for bzip2 and lzip
(which don't use the convention). That's a bit simpler
and is more likely to match some random future compressor.
Only if the "random future compressor" continues repeating the errors of
the past.
Bzip2 and lzip follow a deeper convention; that any non-zero exit status
means failure[1]:
[1]http://www.gnu.org/software/bash/manual/html_node/Exit-Status.html#Exit-Status
"For the shell's purposes, a command which exits with a zero exit status
has succeeded. A non-zero exit status indicates failure. This seemingly
counter-intuitive scheme is used so there is one well-defined way to
indicate success and a variety of ways to indicate various failure modes."
Routing around gzip's quirks may be necessary, but if we begin
considering some non-zero exit statuses as success, chaos will develop.
The "--use-compress-program" is a general mechanism, not only for
compressors[2]:
[2]http://www.gnu.org/software/tar/manual/html_node/gzip.html#SEC132
"The '--use-compress-program' option, in particular, lets you implement
your own filters, not necessarily dealing with
compression/decompression. For example, suppose you wish to implement
PGP encryption on top of compression, using gpg"
And it happens that '2' is in the range gpg reserves for fatal errors[3]:
[3]http://www.gnupg.org/documentation/manuals/gnupg/GPG-Examples.html#GPG-Examples
"The program returns 0 if everything was fine, 1 if at least a signature
was bad, and other error codes for fatal errors."
So, please, don't break "--use-compress-program".
Best regards,
Antonio.