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.ra...@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
