Re: error message lacks useful debugging information
On Thu, Oct 05, 2023 at 07:04:26AM +0200, Phi Debian wrote: > Since we are on the error path (not the perf path) may be the shell could > go the extra miles and try some more diag, has it does for shebang, on > ENOENT, the shell could try to open the a.out, if OK try some other > euristics, [...] Just for the record, trying to open the program for reading is only possible for scripts. It's not too uncommon for a compiled program to have +x permission for the user, but *not* +r permission. Such a program can be executed, but not opened for reading. This permission combo is primarily used for setuid programs on some systems, where it's believed that letting the user read the program might give them insight into finding security exploits in it. Such systems are typically not open source, although it wouldn't surprise me one bit if there are also some BSD/Linux systems with programs like this. Another reason some people might use this permission combo is to "protect their intellectual property", by allowing end users to run the program, but not to make a copy of it. This obviously only works if the owner of the system (and anyone else with root access) is trusted not to make copies. So, it's an incredibly niche situation, but it might still be in use somewhere.
Re: error message lacks useful debugging information
On Thu, Oct 5, 2023 at 12:57 PM Greg Wooledge wrote: > On Thu, Oct 05, 2023 at 07:04:26AM +0200, Phi Debian wrote: > > Since we are on the error path (not the perf path) may be the shell could > > go the extra miles and try some more diag, has it does for shebang, on > > ENOENT, the shell could try to open the a.out, if OK try some other > > euristics, [...] > > Just for the record, trying to open the program for reading is only > possible for scripts. It's not too uncommon for a compiled program > to have +x permission for the user, but *not* +r permission. Such a > program can be executed, but not opened for reading. > > Correct, this is why I proposed the later case, when the shell can not find out more to say, just do nothing and simply suggest some known cases of trouble, yet if the shell can provide more insight, run file(1) and/or an ldd(1) could be usefull. This is the counter part for an interpreter of what compiler do, long time ago, diag from various compiler where very limited, and nowaday they try to be as accurate as possible.
Re: error message lacks useful debugging information
I want to thank all of you for taking this issue seriously. I'm sure you all agree that when something fails, the error message should provide useful information about what went wrong. If bash simply doesn't have the information because the kernel didn't provide it, then perhaps I should throw this to the kernel developers. I understand that it might not seem like a bug in the usual sense, but I hope that you agree that it's something straddling the line between bug and "issue" and really is worth fixing. I don't want to get on a soapbox, but it's an example of why linux hasn't acquired the share of desktop users that it should. Thank you again for your time. David Cigna On 10/5/23 01:04, Phi Debian wrote: Since we are on the error path (not the perf path) may be the shell could go the extra miles and try some more diag, has it does for shebang, on ENOENT, the shell could try to open the a.out, if OK try some other euristics, at least the trivial one i.e the multilib case that seems the most disorientating one, the wrong arch (arm on intel) is already correctly handled, then 'may be' try an ldd (if ldd exist) to mention possible missing libs, all this leading to yet another 'error message' to be entered in the NLS... Or simply a reword of the current implementation bash: ./Candle: cannot execute: required file not found bash: ./Candle: cannot execute: Possible arch mismatch or missing shared libs Assuming no QA test already match the "required file not found", if so it would require yet another compat flag... With this more explicit error message the OP at least have some clue to of what to look for.
Re: error message lacks useful debugging information
On 10/5/23 2:09 PM, Dave Cigna via Bug reports for the GNU Bourne Again
SHell wrote:
I want to thank all of you for taking this issue seriously. I'm sure you
all agree that when something fails, the error message should provide
useful information about what went wrong.
An error message should accurately convey the information the program
printing it has about an error. So let's look at this case.
Bash attempted to execute a program (./Candle) and received -1/ENOENT
from the kernel. It could have stopped there and printed the corresponding
error message ("No such file or directory"), and, in fact, before October
2021, did just that.
There are several reasons the kernel could have returned this error. The
two most likely are that one of the required shared libraries was missing
or the required ELF interpreter (e.g., ld.so) wasn't present. It was the
latter case that prompted the current wording, from a report in 2021:
https://lists.gnu.org/archive/html/bug-bash/2021-10/msg00020.html
There are other causes, including a missing interpreter specified with #!,
which bash handles separately, but these are the two most common on Linux.
Bash doesn't know which case applies, but both involve missing files that
cause the execve to fail.
I don't think it's appropriate for the shell to be able to look into
executable files of several different formats (e.g., ELF, Mach-O) and
determine which of the several potential cases applies here. That's code
I don't need to carry around or support.
If bash simply doesn't have the information because the kernel didn't
provide it, then perhaps I should throw this to the kernel developers.
The kernel is telling you what it knows. Bash is telling you what it knows.
There are other tools (file, ldd, etc.) that can tell you more.
https://lists.gnu.org/archive/html/bug-bash/2021-10/msg00090.html
suggests other values for errno that might be more appropriate, but we
get what we get. The Linux man pages already appropriate ENOENT for these
cases anyway, but there's no good way to determine which file is missing.
And so bash reports that a required file was not found.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: error message lacks useful debugging information
On 2023-10-04 at 20:05 -0400, Dave Cigna wrote: > 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: > > download: candle_1.1.7.tar.gz > from: https://github.com/Denvi/Candle > Extract to the folder of your choosing. cd to that folder and execute > the > bash command: > > ../Candle For the record, the above program is a 32-bit ELF executable. The most likely caue for the error in this case is not having the /lib/ld- linux.so.2 interpreter it requests.
