From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3780 invoked from network); 23 Jun 2001 18:25:36 -0000 Received: from unknown (HELO sunsite.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Jun 2001 18:25:36 -0000 Received: (qmail 21646 invoked by alias); 23 Jun 2001 18:24:54 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15054 Received: (qmail 21616 invoked from network); 23 Jun 2001 18:24:53 -0000 From: "Bart Schaefer" Message-Id: <1010623182219.ZM8052@candle.brasslantern.com> Date: Sat, 23 Jun 2001 18:22:19 +0000 In-Reply-To: <1010623034918.ZM6314@candle.brasslantern.com> Comments: In reply to "Bart Schaefer" "PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)" (Jun 23, 3:49am) References: <000601c0fae0$d819c640$21c9ca95@mow.siemens.ru> <1010623034918.ZM6314@candle.brasslantern.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Subject: Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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