Greg Hudson wrote:
>
> That seems overly final. We could change our code to return exit status
> 1 if there was a warning, or perhaps if no targets succeeded.
>
> Other programs have the same issue:
>
> egyptian-gods% ls -d foo blob
> ls: foo: No such file or directory
> blob
> egyptian-gods% echo $status
> 1
>
> egyptian-gods% tar cvf foo.tar foo blob
> tar: foo: Cannot stat: No such file or directory
> blob/
> tar: Error exit delayed from previous errors
> egyptian-gods% echo $status
> 2
> egyptian-gods% ls -l foo.tar
> -rw-r--r-- 1 ghudson mit 10240 Oct 10 12:46 foo.tar
>
> We appear to be unusual in returning exit status 0 on a mix of success
> and failure.
Yikes! Thanks for this revelation.
That system (1 if any warnings, 0 only for clean success) makes sense now that
I think about it. If there are warnings, an interactive user determines
whether the program "succeeded" in doing what he/she wanted by reading them and
making a judgement about whether they are acceptable, and doesn't look at the
exit code. The exit code is for automated use in scripts etc., where any
surprise or failure to do what was requested may well mean the script shouldn't
continue, and if certain warnings _are_ expected then the script writer can
explicitly provide for ignoring them.
Therefore, subject to further views on the matter, I propose we change to that
system.
Here are a few further thoughts on doing so.
If warnings yield 1, should errors yield 2? It is difficult enough already for
us to decide whether a given circumstance should be treated as an error or a
warning. We can't reliably and objectively make a distinction in many cases,
and to produce arbitrary distinctions wouldn't help script writers: to know how
to handle any failure, they need to know exactly what the problem was, not just
whether we regarded it as "error" or "warning". So errors should also (still)
produce exit code 1.
Do we need to hold off for backward compatibility? I don't know.
Implementation details: this won't be trivial because we'll need to keep track
of warnings that are, I think, in some cases produced down in the libraries.
It might not be difficult, though.
Some commands, such as those whose purpose is to compare or find or test
something, can have more than one success status, and thus 2 or a higher number
for the warning/error exit code. E.g. "svn diff" could have 0 if no
differences found, 1 if differences found, 2 for warnings and/or errors.
I might try to write a concrete proposal for this. We should state it in our
user documentation.
Apologies for the times I said we should return zero if there are only
warnings. I did think about it at the time, and was sure of it, but I am now
convinced otherwise. Any other views?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 14:37:26 2005