Date: Sun, 10 Oct 2021 21:09:53 -0400 From: Eli Schwartz <eschwa...@archlinux.org> Message-ID: <4a362385-066d-0795-9a02-ff8bbb920...@archlinux.org>
| So I wonder, if bash already in this exact case attempts to open() the | file and read() it to look for a shebang, what's the harm in assuming | (or checking) that it exists in this patch? 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. On the other hand: [EINVAL] The new process image file has appropriate privileges and has a recognized executable binary format, but the system does not support execution of a file with this format. looks like it would be an acceptable error for the situation described (which would also cover when the file is an executable for a different architecture, and cases like that). [ENOEXEC] The new process image file has the appropriate access permission but has an unrecognized format. might almost qualify (but not really, as I believe the file was understood to be a known executable format). 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. kre 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.