zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: <zsh-workers@sunsite.auc.dk>
Subject: Re: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)
Date: Sat, 23 Jun 2001 18:22:19 +0000	[thread overview]
Message-ID: <1010623182219.ZM8052@candle.brasslantern.com> (raw)
In-Reply-To: <1010623034918.ZM6314@candle.brasslantern.com>

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   


  reply	other threads:[~2001-06-23 18:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1000304181244.ZM24879@candle.brasslantern.com>
2001-06-21 21:46 ` status codes on Dec OSF Brian Harvell
2001-06-22  6:01   ` Andrej Borsenkow
2001-06-23  3:49     ` PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF) Bart Schaefer
2001-06-23 18:22       ` Bart Schaefer [this message]
2001-06-25  5:57         ` Andrej Borsenkow
2001-06-27  7:15           ` Andrej Borsenkow
2001-06-27  7:46             ` Bart Schaefer
2001-06-27 13:02               ` Brian Harvell
2001-06-22  7:03   ` status codes on Dec OSF Sven Wischnowsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1010623182219.ZM8052@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).