[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unfortunate error message for invalid executable

From: AA
Subject: Re: Unfortunate error message for invalid executable
Date: Sat, 28 May 2022 13:56:07 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

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!

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]