A shell can use more codes as an extension, but this is not recommended to
leave as much room for application specific return values as is practical.
I view it as 127 covers errors related to path resolution/setting up the exec()
attempt, including determining in an unspecified manner whether the command is
a script so no exec() call needed; 126 covers errors when those checks done and
exec() is expected to not fail but does anyways, or the shell can't be forked
and reinitialized to begin processing a script. It is the time point that
determines which value is used, not type of error. For 127 errors, an
abort/retry query loop is plausible for a script, but not so much for 126 type
errors.
On Saturday, July 1, 2017 Robert Elz <k...@munnari.oz.au> wrote:
When the shell has to exec a utility, if the exec*() it performs fails,
it has to reflect that status (failure) back to the calling process
(usually for our purposes, the script).
XCU 2.8.2 includes ... (lines wrapped for e-mail)
75455 If a command is not found, the exit status shall be 127.
If the command name is found, but it is
75456 not an executable utility, the exit status shall be 126.
Applications that invoke utilities without
75457 using the shell should use these exit status values to report
similar errors.
The final sentence of those 3 (the second part of line 75456 to the end)
isn't relevant here (but whatever the answer is here should apply to
such applications in the same way, I would assume).
For the purposes of this e-mail assume that user/script has written
/path/to/command/I/want arg1 arg2 ...
to avoid discussions about what any of this means to PATH searches, and
burrowing down that rabbit hole.
The exec(2) functions can fail for a lot of reasons, they are listed in the
exec page of XSH section 3 (the exec errors are on pages 788-9)
"If a command is not found" (status 127) I assume certainly means ENOENT
from the error list, but might also mean EACCES in the 2nd use of that,
and probably ELOOP ENAMETOOLONG ENOTDIR.
On the other hand "but is not an executable utility" (status 126) clearly
implies the first case of EACCES ("the implementation does not support
execution of files of its type.") plus I assume EINVAL, or ENOEXEC.
I'm not sure how the shell which just had an exec*() sys call fail with
EACCES is supposed to tell which of the two cases applied - I guess it
could open the path, and if EACCES happens for that, then it is the 2nd
case, and if the open succeeds, try fexecve() and if that fails with
EACCES it must be the first case, as the 2nd is not defined (nor relevant).
But that's not the real question here (and seems like a lot of burden that I
doubt that many shells, if any, bother with.)
What is the shell intended to return when the exec*() error is not one
of those cases, but one of the other possible errors, like E2BIG, or ETXTBUSY
or ENOMEM, (or perhaps something not listed, like EIO which can occur if
while reading the new process to exec it, an I/O error occurs - bad block on
the media or similar, or someone simply unplugged a device while the
exec from it was in progress.)
Neither the 127 nor 126 status codes seem appropriate for those kinds of
errors, the file was found (so not 127) and is an executable utility (so
not 126) - is there any common approach to reporting the other "utility
never started, this error is from the shell trying to run it" cases?
kre
