Re: Running 32 bit program on 64 bit system makes bash etc. look bad

[Eli Schwartz]

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