On Thu, 26 May 2022 11:27:32 -0700 AA via Bug reports for the GNU Bourne Again SHell <bug-bash@gnu.org> 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
