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.
