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