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.
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
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 d
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 compresso
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)
> //
Pavel Raiskup wrote:
I agree that this would be the most logical. But there is a problem with
backward compatibility. The behaviour of --use-compress-program will
change.. what about this:
-I, --use-filter-program (general 'vanilla' API)
--use-compress-program (obsoleted alias to ^^^)
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 lik
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.
> 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
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
> But with the proposed approach, -I /usr/bin/gzip behaves differently
> from -I gzip. Isn't that confusing?
It definitely is.
> > I'm partly against
> > this because it complicates tar's api & user is always able to write
> > very simple wrapper
>
> Good point. So perhaps we shouldn't add that
On 04/26/2013 12:42 AM, Pavel Raiskup wrote:
> I think that the '-I' should define perfectly the program return values.
> So the -I /usr/bin/gzip could be considered like bad usage - and tar
> behaves like this now.
But with the proposed approach, -I /usr/bin/gzip behaves differently
from -I gzip.
> Still, the current patch doesn't seem quite right;
> what if the user specifies -I/usr/bin/gzip, or
> something like that? It seems to me that we need
> to let the user specify one or more "ok exit statuses",
> i.e., exit statuses to treat as if they were zero.
I think that the '-I' should defi
On 04/25/13 08:49, Antonio Diaz Diaz wrote:
> Only if the "random future compressor" continues repeating the errors of the
> past.
Hmm, OK, thanks, you convinced me.
Still, the current patch doesn't seem quite right;
what if the user specifies -I/usr/bin/gzip, or
something like that? It seems to
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
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.
Sh
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,
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 obs
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.
> 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)
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
22 matches
Mail list logo