Chet Ramey writes ("Re: Bug#360793: bash -c '. /dev/enoent; whoami' unhelpful
error code (forwarded from Ian Jackson)"):
> Matthias Klose wrote:
> > The exit status should be 127, not 1. That would allow
> > bash -c '. bogus; diff file other-file'
> > to be distinguished from
> > bash -c '. /dev/null; diff file other-file'
>
> There's no good reason to change this. If you want to check whether
> or not a file exists before trying to source it, use test -e or
> test -f. If you want the shell to abort if the file argument can't
> be read, use posix mode.
?!
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.
In fact, adding tests of this kind tends to mask bugs because it
increases the number of error-handling paths - it ensures that obscure
and strange error conditions take untested and probably-buggy code
paths. Furthermore, these kind of tests can make it very hard to
synthesise errors (which you need to do if you want to test the error
handling).
If the shell synthesises the exit status 1 in these cases then it
makes it unnecessarily hard to interact with programs which use 1 for
some special purpose, like diff.
In posix mode the situation is even worse because you can't prevent
the shell from exiting with its own synthetic code `1'. Consider, for
example, if you were trying to write a script which was a wrapper for
diff, and which wanted to use `.' to source a file. Failure to read
the file would cause the wrapper to exit with status code 1, which
would be wrongly interpreted by the caller to mean `all went well and
the files differ'.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
