Re: Unfortunate error message for invalid executable

[AA]

I'm sure I'm not the first person to want to have a long philosophical 
conversation with the engineer that put the bolt I need to to reach in 
order to fix my car, in the place that requires me to disassemble 20 
other unrelated things. Nor am I likely to be the first person to want 
to reclaim the time wasted by such choices.

... but here goes:

While I understand all of these arguments, they seem to me to be 
inappropriately brushing off the issue based on highly technical and 
simultaneously highly user unfriendly reasoning. Bash, in the end, is a 
user space tool that is directly aimed at interfacing humans to the 
machine. It is, after all a *shell*.

In other words, for every provably accurate reason given below, there 
exists an argument that bash (when interpreting the error code returned) 
could do more. It could:

* Not print only the error string associated with ENONENT given that it 
is well known that error code may not in fact apply specifically to the 
file the user asked bash to execute. E.g., it could indicate this well 
known fact.
* Apply a reasonable set of heuristics to determine if the error 
returned by the kernel / execve() call makes direct sense for the path 
passed to the call, and issue a helpful message

Maybe the concern is that any additional calls (such as checking for 
path existence) may have unintended consequences. I'm not qualified to 
say definitively, 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 and therefore that ENOENT is 
provably false *for the path with which the user is directly 
interacting*. It seems therefore valid that, irrespective of 
kernel/distribution/etc/etc if ENOENT is returned when executing a path 
that does in fact exist, bash could print something more than the error 
string expansion of ENOENT (whether being obtuse about it is an 
anachronistic unix-ism or not).

I.e., something like "I'm not sure what's going on, but your path 
definitely exists, yet the kernel says otherwise."

... something like fprintf(STDERR,"No such file or directory while 
attempting to execute %s (it exists, but cannot be executed)",path);

All the best and thanks for the insights!
A.

PS: None of the foregoing is offered with anything but a smile.

On 5/26/22 7:39 PM, Dale R. Worley wrote:
> Chet Ramey<chet.ramey@case.edu>  writes:
> > On 5/26/22 2:27 PM, AA via Bug reports for the GNU Bourne Again SHell wrote:
> > > When a user attempts to execute an executable that is not
> > > recognized as an executable by the system, the generated error is "No such
> > > file or directory"
> > In this case, it's the errno value returned from execve(2), and it's
> > exactly correct, at least from the kernel's perspective.
> >
> > It's not that the executable isn't recognized or in an invalid format, in
> > which case execve would return ENOEXEC. It's that the ELF header specifies
> > a particular interpreter to run on the file (e.g., ld.so), and that file is
> > the one that is not found (ENOENT).
> This parallels the annoying Unixism that if you attempt to execute a
> file that is marked executable that has a #! interpreter specification,
> but the specified interpreter does not exist, the generated error is "No
> such file or directory".  It would be nice if the kernel generated a
> separate errno for "a supporting executable for this executable file
> does not exist" but nobody's bothered to do that.
>
> Dale