[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unfortunate error message for invalid executable
From: |
Chet Ramey |
Subject: |
Re: Unfortunate error message for invalid executable |
Date: |
Fri, 3 Jun 2022 09:50:20 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 |
On 5/28/22 4:56 PM, AA via Bug reports for the GNU Bourne Again SHell wrote:
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.
I know it's bait, but I'll bite. I'm sure it would be a short conversation,
along the lines of risk analysis showing the likelihood of that bolt
failing was small enough that its placement was deemed a low priority, and
that higher priority parts (in terms of both failure rate and assembly
constraints) were made more accessible.
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*.
You'll be pleased to hear that bash-5.2 behaves the way you want, the
result of
https://lists.gnu.org/archive/html/bug-bash/2021-10/msg00020.html
back early last October.
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).
ENOENT really can happen. Consider a hashed command whose target is
removed after hashing, without checkhash enabled. Uncommon, you say? Maybe.
But so is this scenario. So you have to check it; you can't just assume
that ENOENT means the required interpreter was not found.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
- Re: Unfortunate error message for invalid executable,
Chet Ramey <=