zsh-workers
 help / color / mirror / code / Atom feed
From: "Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>
To: <zsh-workers@sunsite.auc.dk>
Subject: RE: PATCH: POSIX exit codes (not quite Re: status codes on Dec OSF)
Date: Mon, 25 Jun 2001 09:57:11 +0400	[thread overview]
Message-ID: <000501c0fd3b$ad5a7be0$21c9ca95@mow.siemens.ru> (raw)
In-Reply-To: <1010623182219.ZM8052@candle.brasslantern.com>


>
> 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().
>

Well, quoting standards again:

Otherwise, the shell will execute the utility in a separate utility
environment (see Shell Execution Environment ) with actions equivalent to
calling the XSH specification execve() function with the path argument set
to the pathname resulting from the search, arg0 set to the command name, and
the remaining arguments set to the operands, if any.
If the execve() function fails due to an error equivalent to the XSH
specification error [ENOEXEC], the shell will execute a command equivalent
to having a shell invoked with the command name as its first operand, along
with any remaining arguments passed along. If the executable file is not a
text file, the shell may bypass this command execution, write an error
message, and return an exit status of 126.

Which means, that strictly speaking both sh and zsh are conform. Shell may
believe execve or may try to directly execute the command. So, it is a
matter of bash/zsh compatibility. I would ignore it.

> 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".
>

I guess, zsh's behaviour is more appropriate:

[PATH search]
The list is searched from beginning to end, applying the filename to each
prefix, until an executable file with the specified name and appropriate
execution permissions is 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?
>

No in both cases. I would presume, that in case of path search 126 is not
possible at all.

-andrej


  reply	other threads:[~2001-06-25  5:58 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
2001-06-25  5:57         ` Andrej Borsenkow [this message]
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='000501c0fd3b$ad5a7be0$21c9ca95@mow.siemens.ru' \
    --to=andrej.borsenkow@mow.siemens.ru \
    --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).