Ian Jackson wrote:
> 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.
Step back and take a look. You have to do this sort of checking no
matter what if you want robust programs.
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.
In general, trying to intuit something besides "an error occurred" from
a non-zero exit status works only in a very few cases.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
