Eric Blake wrote:
> Additionally, the standard REQUIRES that 'sh -c "exec /"' shall fail
> with status 126:
>
> http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#exec
> "If command is found, but it is not an executable utility, the exit
> status shall be 126."
>
> Right now, dash gets this wrong:
>
> dash -c 'exec .'; echo $?
> exec: 1: /: Permission denied
> 2
>
> And since you already have the code in dash to detect failure to
> 'exec' a directory, you should be able to reuse that code when
> detecting failure to run a directory as a script, as in 'dash .'.
Summary:
Command Status Expected status
1) exec . 2 126
2) exec nonexistent 2 127
3) sh . 0 126
4) sh nonexistent 2 127
(1) and (2) seem to be regressions from about 5 years ago.
Reverting the problematic patch fixes it for me; see below.
(3) is not clearly documented in the standard, and there is
some disagreement between shells on how to handle it[1]. The
current behavior seems fine to me.
(4) is a clear bug, well documented in the EXIT STATUS section
of the description of sh in the "Utilities" chapter. See
http://thread.gmane.org/gmane.comp.shells.dash/291/focus=390
for a patch[2].
Thoughts?
Jonathan Nieder (3):
[EXCEPTIONS] Stop documenting EXSHELLPROC
Revert "Eliminated global exerrno."
[EXCEPTIONS] Eliminate global exerrno
src/TOUR | 11 +----------
src/error.h | 5 ++---
src/eval.c | 8 ++++----
3 files changed, 7 insertions(+), 17 deletions(-)
[1]
$ bash .; echo $?
.: .: is a directory
126
$ ksh93 .; echo $?
ksh93: .: cannot open [Is a directory]
126
$ pdksh .; echo $?
0
[2] Unfortunately this does not share code with the fix to (1)
and (2) as Eric hoped. Why? The system calls involved are
different: the exec builtin uses execve(), while 'sh <script>'
uses open() and read().
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[LARTC]
[Bugtraq]
[Yosemite Forum]
[Photo]