Re: Unfortunate error message for invalid executable

[Andrew Athan]

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 <martin@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