Re: error message lacks useful debugging information

[Kerin Millar]

On Wed, 4 Oct 2023 20:05:41 -0400
Dave Cigna via Bug reports for the GNU Bourne Again SHell <bug-bash@gnu.org> 
wrote:

> Description:
> 
> Attempting to tun an executable file (not a bash script) with the following
> command:
> 
> ./Candle
> 
> the following error message is reported by bash:
> 
> bash: ./Candle: cannot execute: required file not found
> 
> The executable file 'Candle' does exist in the current directory;
> if it didn't then bash would report a different error.
> 
> The problem may be a missing dependency. However, the BUG is in bash in that

That is, indeed, the problem.

https://lists.gnu.org/archive/html/bug-bash/2022-05/msg00048.html
https://lists.gnu.org/archive/html/bug-bash/2022-05/msg00050.html

> it doesn't offer any useful debugging information. Debugging the issue could
> go from "nearly hopeless" to "I think I can handle this" if bash simply
> reported what required file was missing. i.e. path and filename.
> 
> Repeat-By:
> 
> Here's how I encountered the problem. You might not be able to reproduce
> it on your machine, but that doesn't mean that it's not a bug with bash:

While it can be considered as a matter of usability, it is not a bug in bash. 
The real problem (in so far as there is one) is that the kernel reports the 
error in a manner that is coarse enough to confuse users as to the matter of 
exactly which file is missing. That is, there is no distinct error code that 
exists to indicate that the missing file just happens to be one that the 
dynamic loader implemented by your OS was looking for. Moreover, bash is only 
the messenger. It is not realistic to expect for bash to have any genuine 
insight into (precisely) why a given kernel and userland - for a given 
distribution of a given OS - decides to raise ENOENT after being charged with 
executing a binary. The information that would be necessary to print any 
accurate debugging information is simply beyond the purview of the shell.

Ironically, bash does already supply its own diagnostic message for ENOENT (the 
one you saw and reported), rather than print the native error string which 
would simply have been "No such file or directory". In principle, you could 
propose yet another improvement in its wording. In my view, the value in 
replacing or decorating native error messages is dubious. There is only so much 
that can be said without making too many assumptions about the underlying 
platform or, worse, implementing dodgy heuristics. Although, there is a 
heuristic that tries to determine whether ENOENT was caused by a script 
containing a shebang specifying an invalid interpreter, which does not help in 
this case.

-- 
Kerin Millar