Re: Misleading error when attempting to run foreign executable

[Eli Schwartz]

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