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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
