Chet Ramey writes ("Re: Bug#360793: bash -c '. /dev/enoent; whoami' unhelpful
error code (forwarded from Ian Jackson)"):
> Ian Jackson wrote:
> > Testing for expected error situations before carrying out some action
> > is no substitute for proper and correct error handling if the action
> > fails. For example, in the case I quoted, there might be all sorts of
> > reasons why opening the file might fail even though it exists and is a
> > file.
>
> Step back and take a look. You have to do this sort of checking no
> matter what if you want robust programs.
I disagree. Instead, the correct approach is usually to allow the
error to happen and then handle it appropriately. This depends, of
course, on being able to tell what the error was from the information
provided (in this case, we're discussing using the exit status for
that).
> Consider what would happen if the shell changed the exit status of `.'
> to 127 if the file argument did not exist. Since `.' is required to
> return the exit status of the last command executed, there's now no
> difference between
> . notthere
> and
> . existing-file
> where `existing-file' ends with `notthere' or any other command that's
> not found.
Indeed so. The reason this is better than having there be
no difference between
. notthere
and
. existing-file-which-wraps-diff
is this: missing commands and missing `.' files are both usually to be
treated as the most serious kind of unexpected error; a script or
program which encounters that situation will want to perform whatever
error recovery it thinks it can and then probably bomb out (or return
to some higher level main loop or some such).
The same is true for other situations that result in exit status 127
(for example, runtime linking failures). It's not generally true for
situations that result in exit status 1, and it makes life less
inconvenient if exit status 1 is not reused for other purposes in ways
that make it difficult to tell whether it originated in the `expected'
manner or some other way.
> In general, trying to intuit something besides "an error occurred" from
> a non-zero exit status works only in a very few cases.
My point is that sometimes this is both necessary and possible.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
