Date: Mon, 11 Oct 2021 11:00:54 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <45ecd950-9e9b-553b-132b-04d1dcfad...@case.edu>
| When execve returns this error for what is a clearly invalid reason,
The problem is that sometimes it will probably be an invalid reason
(that's where the race conditions can matter, that the file was there
when it was checked doesn't mean it is still there now, so the reason
might be valid, and I'm not sure it is really worth another stat() to
find out - and even if the stat() is done and that says the file exists,
the exec attempt might just have happened in the middle of a
mv a a.old; mv a.new a
sequence).
Other times (like exec of a /path/to/file) you won't have any idea at
all in advance that the file apparently exists, so the same underlying
issue would generate different messages in different circumstances if you
try and handle the case where you believe error to be invalid (unless you
check after every ENOENT -- even in the /path/to/file case).
Better to get the OS fixed (those kinds of fixes tend to seem less
urgent when applications work around them instead of simply complaining).
But that said:
| it's not unreasonable that the shell help.
it isn't unreasonable - as I said (in the postscript) "even if bash
(or some other process) were to attempt to examine the file after an exec
failure to generate a nicer message...", kind of indicating that it
wouldn't be a wrong thing to do, just certainly not required.
kre
