Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15559 > unrolled thread

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

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Running 32 bit program on 64 bit system makes bash etc. look bad Eli Schwartz <eschwartz@archlinux.org> - 2019-11-02 20:54 -0400

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

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web