Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)
- X-seq: zsh-workers 15054
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: <zsh-workers@xxxxxxxxxxxxxx>
- Subject: Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)
- Date: Sat, 23 Jun 2001 18:22:19 +0000
- In-reply-to: <1010623034918.ZM6314@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <000601c0fae0$d819c640$21c9ca95@xxxxxxxxxxxxxx> <1010623034918.ZM6314@xxxxxxxxxxxxxxxxxxxxxxx>
On Jun 23, 3:49am, Bart Schaefer wrote:
}
} Apparently quoting from the POSIX standard, Andrej goes on:
}
} } If a command is not found, the exit status will be 127. If the command name
} } is found, but it is not an executable utility, the exit status will be 126.
} } Applications that invoke utilities without using the shell should use these
} } exit status values to report similar errors.
}
} + _exit(errno == EACCES ? 126 : 127);
Upon reflection, I think that should test ENOEXEC as well; bash behaves
that way. I'll make that change when I commit the patch.
However, in comparing with bash I found a discrepancy, and I'm not sure
which interpretation is the correct one. Consider a shell script that
begins with:
#! /this/does/not/exist
Attempting to execute such a script in bash gives a 126 exit status. In
zsh with my patch applied, the status is 127 -- because the command in
the #! line is, in fact, not found.
If the script is executed directly by its full path, both shells print
"no such file". If the script is executed via a path search, however,
zsh actually does print "command not found", while bash still says "no
such file".
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().
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".
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?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by:
Reverse Date,
Date,
Thread,
Author