RE: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

>
> This is because zsh believes execve() when it sets errno to ENOENT,
> whereas bash explicitly stat()s the file before attempting to execute it
> and returns 126 if it exists, regardless of the errno set by execve(),
> even though the error message it prints is the one from execve().
>

Well, quoting standards again:

Otherwise, the shell will execute the utility in a separate utility
environment (see Shell Execution Environment ) with actions equivalent to
calling the XSH specification execve() function with the path argument set
to the pathname resulting from the search, arg0 set to the command name, and
the remaining arguments set to the operands, if any.
If the execve() function fails due to an error equivalent to the XSH
specification error [ENOEXEC], the shell will execute a command equivalent
to having a shell invoked with the command name as its first operand, along
with any remaining arguments passed along. If the executable file is not a
text file, the shell may bypass this command execution, write an error
message, and return an exit status of 126.

Which means, that strictly speaking both sh and zsh are conform. Shell may
believe execve or may try to directly execute the command. So, it is a
matter of bash/zsh compatibility. I would ignore it.

> There is another effect of this:  If there are two files in the path with
> the same name, bash will always attempt to execute the first one and fail
> with 126/"no such file", but zsh will keep searching and either execute
> the second one or report 127/"command not found".
>

I guess, zsh's behaviour is more appropriate:

[PATH search]
The list is searched from beginning to end, applying the filename to each
prefix, until an executable file with the specified name and appropriate
execution permissions is found.

> It would be somewhat convoluted to retain that path-search behavior yet
> still manage to exit with 126 when there is at least one file in the path
> that *might* have been executable.  It would be possible to get the bash
> behavior for direct execution by addition of a single stat(), but then
> the same script fails with different values depending on how you invoke
> it -- and this gets even more confusing if PATH_DIRS is set.
>
> Does anyone think that (a) zsh's path search behavior is a problem, or
> (b) that it's important to return 126 in this circumstance?
>

No in both cases. I would presume, that in case of path search 126 is not
possible at all.

-andrej