On 10/11/21 07:09, Robert Elz wrote: > This is clearly an OS problem, not one in bash. > > POSIX says of ENOENT as it applies to the exec*() set of functions: > > [ENOENT] A component of path or file does not name an existing file > or path or file is an empty string. > > "path" and "file" (which are in italics in the text, that just doesn't > make it to this ascii e-mail) are args to (different instances of) the > exec*() functions (ie: they are not generic words). > > That is, ENOENT is only applicable if the file (or path) named in the > arg to the sys call does not exist.
Indeed, but the kernel.org "Linux man pages" project distributes
manpages which freely "reinterpret" this:
[ENOENT]
The file pathname or a script or ELF interpreter does not exist.
[ENOEXEC]
An executable is not in a recognized format, is for the wrong
architecture, or has some other format error that means it cannot be
executed.
[EINVAL]
An ELF executable had more than one PT_INTERP segment (i.e., tried
to name more than one interpreter).
> This should be fixed at OS level, bash isn't the only shell that exists,
> and shells aren't the only programs that attempt to exec binaries which
> look as if they should be executable.
This would no doubt be a fascinating conversation to have with the Linux
kernel developers, but to be honest it looks like an intentional POSIX
"deviation", shall we say.
In the meantime I think that the most likely response will be "but this
is behaving exactly as documented, just add a Linux case to your
application to handle Linux error codes".
> ps: as an aside, no-one cares about any race conditions here, even if bash
> (or some other process) were to attempt to examine the file after an exec
> failure to generate a nicer message ... the only thing affected would be
> the error message, and if you get weird messages when attempting to run
> binaries which are changing as you're doing it, it should be no surprise.
Indeed, that was part of why I suggested doing so was harmless.
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
OpenPGP_signature
Description: OpenPGP digital signature
