Unfortunate error message for invalid executable
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-Smvct5/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux ip-172-31-20-239 5.13.0-1021-aws #23~20.04.2-Ubuntu SMP Thu Mar 31 11:36:15 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 17 Release Status: release Description: 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" Repeat-By: Obtain an i386 executable instead of an amd64 executable and attempt to run it via ./name_of_executable Fix: If the file exists but cannot be executed, issue an error message that is not so misleading. The file does exist, so "No such file or directory" seems plain wrong.
Re: Unfortunate error message for invalid executable
On 5/26/22 2:27 PM, AA via Bug reports for the GNU Bourne Again SHell wrote: Bash Version: 5.0 Patch Level: 17 Release Status: release Description: 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). Bash looks at the errno value a bit, but doesn't attempt to second-guess the kernel to any great extent. -- ``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: Unfortunate error message for invalid executable
On Thu, 26 May 2022 11:27:32 -0700 AA via Bug reports for the GNU Bourne Again SHell wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > -fdebug-prefix-map=/build/bash-Smvct5/bash-5.0=. > -fstack-protector-strong -Wformat -Werror=format-security -Wall > -Wno-parentheses -Wno-format-security > uname output: Linux ip-172-31-20-239 5.13.0-1021-aws #23~20.04.2-Ubuntu > SMP Thu Mar 31 11:36:15 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.0 > Patch Level: 17 > Release Status: release > > Description: > 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" > > Repeat-By: > Obtain an i386 executable instead of an amd64 executable and > attempt to run it via ./name_of_executable > > Fix: > If the file exists but cannot be executed, issue an error > message that is not so misleading. The file does exist, so "No such file > or directory" seems plain wrong. While potentially confusing, it isn't wrong. Your kernel has CONFIG_IA32 compiled in so, in fact, it is considered as a valid executable. If that were not the case, it would have raised ENOEXEC (Exec format error) instead. Instead, the execve() syscall raises ENOENT (No such file or directory) because the 32-bit instance of ld-linux.so is missing on your system. You may run "man 8 ld-linux.so" to learn more about it. The reason that this file is missing in your OS is because it's not presently set up to be multilib-capable. Still, all of this is outside of the purview of the shell. What bash is doing in response to the failed syscall is to report the exact error that it raised. It doesn't seem reasonable to expect for it to do anything else. -- Kerin Millar
Re: Unfortunate error message for invalid executable
Chet Ramey 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
