On Sunday, April 28, 2013 07:23:05 PM Antonio Diaz Diaz wrote:
Paul Eggert wrote:
Converting gzip to the general API seems the right thing to do in the long
term.
That might be wise, yes, but there might be other users who
expect the current behavior, and we'd need to consult with them.
If you look at the gzip source code you'll
find a number of circumstances that will
cause it to exit with status 2, as a warning.
This API isn't likely to change any time soon,
I'm afraid, as gzip is fairly frozen.
Paul Eggert wrote:
Converting gzip to the general API seems the right thing to do in the long term.
That might be wise, yes, but there might be other users who
expect the current behavior, and we'd need to consult with them.
To my surprise I have found that the current behavior is that gzip
On 04/26/2013 12:56 AM, Pavel Raiskup wrote:
So you think something like remove the leading path '/usr/bin/' before
comparison with 'GZIP_PROGRAM'?
I'm afraid that will lead to even more confusion; among other things,
tar shouldn't care what the program names are.
It may be better to have two
When tar infers a compressor it can also infer which of these two
options to use.
That means, using the -Z, -z, .. options will setup some new flag, same
as the new use-compress-program-like option will. Do you have some
requirements for this option name? This is the hard one..
Would you be
On 04/26/2013 01:17 AM, Pavel Raiskup wrote:
Do you have some
requirements for this option name?
We could have --use-compress-program for the compress API,
and --use-filter-program for the more-vanilla API.
Or something like that. I'm fine with your preparing
a patch.
On Friday, April 26, 2013 01:36:02 AM Paul Eggert wrote:
On 04/26/2013 01:17 AM, Pavel Raiskup wrote:
Do you have some
requirements for this option name?
We could have --use-compress-program for the compress API,
and --use-filter-program for the more-vanilla API.
Or something like that.
On 04/26/2013 03:07 AM, Pavel Raiskup wrote:
-I, --use-filter-program (general 'vanilla' API)
--use-compress-program (obsoleted alias to ^^^)
// remove from --help man info to not confuse people
--use-compress-like-program (with a *proper* definition what it does)
// or
On 04/26/2013 10:07 AM, Antonio Diaz Diaz wrote:
Converting gzip to the general API seems the right thing to do in the long
term.
That might be wise, yes, but there might be other users who
expect the current behavior, and we'd need to consult with them.
And there are a lot of other compressor
On Wednesday, April 24, 2013 10:58:10 PM 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.
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
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.
On Tuesday, February 26, 2013 08:32:25 AM Pavel Raiskup wrote:
On Mon, 2013-02-25 at 11:39 -0800, Paul Eggert wrote:
I suggest something simpler: namely, just declare that the
-Z (compress) program must conform to the compress API,
so that its exit status 2 really means OK. That way,
we
Hello,
as is written in compress manual page
[...]
Exit status is normally 0; if the last file is larger after (attempted)
compression, the status is 2; if an error occurs, exit status is 1.
the compress utility could end with exit value 2 which does not mean fatal
error. It is just some
I'm attaching one possible solution, could you look at it?
Sorry for the typo, re-attaching because of this:
| diff --git a/src/system.c b/src/system.c
| index ca0ad05..d722352 100644
| --- a/src/system.c
| +++ b/src/system.c
| @@ -192,7 +192,7 @@ sys_wait_for_child (pid_t child_pid, bool eof)
I suggest something simpler: namely, just declare that the
-Z (compress) program must conform to the compress API,
so that its exit status 2 really means OK. That way,
we can change only src/system.c and NEWS. The compress API
is obsolete and isn't likely to change so this sounds safe.
On Mon, 2013-02-25 at 11:39 -0800, Paul Eggert wrote:
I suggest something simpler: namely, just declare that the
-Z (compress) program must conform to the compress API,
so that its exit status 2 really means OK. That way,
we can change only src/system.c and NEWS. The compress API
is
17 matches
Mail list logo
