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. 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. 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(-)  $ bash .; echo $? .: .: is a directory 126 $ ksh93 .; echo $? ksh93: .: cannot open [Is a directory] 126 $ pdksh .; echo $? 0  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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html