On Tuesday 11 October 2005 14:36, Julian Foad wrote:
> 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.
Please note that the return code is normally correlated to the system error
that caused the error, ie.
> Greg Hudson wrote:
> > 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
2 == ENOENT == File not found
It is merely convention that warnings produce the (lowest possible) return
code of 1 - as the thing which caused a warning might not be the result of a
system error (think XML-parser with invalid date *after* the xml - there's no
failed system call, but some internal condition that resulted in a warning).
BTW, 1 == EPERM ... that doesn't say much.
It's just returned so that the caller doesn't think *everything* went ok.
So, IMO warnings should *always* return non-0, and errors an as meaningful as
possible return code - it's better than simply returning the same code.
Eg. if some script finds an return code of 12 == ENOMEM it may just retry a
while later.
I believe that as much information as possible should be returned - so the
caller can decide what to do.
Regards,
Phil
---------------------------------------------------------------------
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:55:30 2005