[PATCH 0/3] Fix exit status for 'exec nonexistent' and 'exec .'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux