On 11/1/19 7:56 PM, 積丹尼 Dan Jacobson wrote:
> $ mapping/taipower/pole2tm
> bash: mapping/taipower/pole2tm: No such file or directory
>
> Must be a bash bug! Proof:
> $ ls -l mapping/taipower/pole2tm
> -rwxr-xr-x 1 jidanni jidanni 11290 2012-06-19 mapping/taipower/pole2tm
>
> But wait,
> $ strace mapping/taipower/pole2tm
> execve("mapping/taipower/pole2tm", ["mapping/taipower/pole2tm"],
> 0x7ffd53416200 /* 58 vars */) = -1 ENOENT (No such file or directory)
> strace: exec: No such file or directory
> +++ exited with 1 +++
>
> Must also be a strace bug...
>
> Ah,
> $ file mapping/taipower/pole2tm
> mapping/taipower/pole2tm: ELF 32-bit LSB executable...
>
> but we are running it on
> $ arch
> x86_64
>
> Anyway, perhaps somebody could submit a kernel bug, telling them to
> somehow make bash, etc. look less bad, by a clearer error message, as I
> suppose bash cannot always catch such cases, to make a better error
> message.
>
> In fact maybe bash could catch it (expensive?):
>
> First "stat" the file.
> If it doesn't exist bash should make its own message
> bash: /tmp/abce: No such file or directory
> If it does, then bash should be prepared to catch the kernel's message
> (which is referring to a *different* file, which yes, actually does not
> exist.)
> Whereupon bash could make a better error message.This seems like a very complicated way to work around the fact that you're either downloading mysterious (32-bit) binaries which aren't for your (64-bit) OS, or installing broken stuff from your package manager that doesn't pull in the 32-bit support libraries it is supposed to. And as you cleverly pointed out, "fixing" bash would not "fix" strace or any of the many other ways it is possible to launch an executable file. Playing whack-a-mole seems not-fun. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
