Awesome (I made no claims of expertise about the details of the call semantics). I agree any multi-call scenario would among other things not be atomic. Though, I’m not sure that’s what you mean by hoodwinked.
That last suggestion is exactly one I also made (simply improve the error text) and I completely agree would suffice if there isn’t a technical solution to disambiguate the actual error condition. My nezt step was going to be to find the source, and check where the string is generated or looked ip. A. > On May 29, 2022, at 4:34 AM, Martin D Kealey <mar...@kurahaupo.gen.nz> wrote: > > > > >> On Sun, 29 May 2022, 06:56 AA via Bug reports for the GNU Bourne Again >> SHell, <bug-bash@gnu.org> wrote: >> Maybe the concern is that any additional calls (such as checking for path >> existence) may have unintended consequences [but that] seems unlikely. >> >> Therefore, IMHO it is very hard to argue with the fact that the file passed >> to the kernel does in fact exist > > > Actually it's quite easy to argue with that: a race condition between when > execve fails and when we subsequently check whether the file exists means we > could be hoodwinked into reporting the wrong error message in both directions. > > Either use fexecve (where it exists) to be CERTAIN that the file exists > before invoking it, or simply adjust the wording of the error message to make > the ambiguity clear. > > Then again, "file (or its interpreter) does not exist" would cover both cases > without needing to check separately whether the file exists. > > -Martin
