On 2019-11-02 at 07:56 +0800, 積丹尼 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
That's not exactly the problem, although related.
ELF programs may be static (rare) or dynamic, in which case they include
in their header that they should be run with an interpreter such
as /lib/ld-linux.so
If it is a 32 bit program being run on a 64 bit arch, it is most likely
pointing to a binary that is not present there (you could have a
multi-arch system installed, in which case your pole2tm would run fine)
Running
$ readelf -l mapping/taipower/pole2tm | grep "Requesting program
interpreter:"
will show you the program that it is trying to run, which is likely to
be missing.
[In some cases you may also receive that message when it's one of the
dependencies (libraries) that is missing]
The problem is exactly the same as if you made a shellscript with a
shebang pointing to a missing binary.
In fact, dash does just that:
$ dash -c "./foo"
dash: 1: ./foo: not found
bash manages to provide a slightly more helpful error message:
$ bash -c "./foo"
bash: ./foo: /bin/missing: bad interpreter: No such file or directory
> 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.
The kernel only returns an error code, jidanni. Which is the right one,
as there is a missing file.
I agree it's confusing, though, as the message provided is the same as
if the program itself was missing, which is obviously not the case.
> 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.
bash is already stating it after the exec fails (as part of the fallback
code to see if it should manually run a shebang, I think).
You could place a different message there.
I don't think it should be parsing the ELF file just for this cosmetic
point (additionally, it might be in another format, such as PE, the
kernel may support many formats, see what people do with binfmt_misc
https://en.wikipedia.org/wiki/Binfmt_misc )
However, it would be helpful if it changed the to something a bit
different, such as
bash: mapping/taipower/pole2tm: missing file when executing existing
file (bad interpreter?)
The actual message would not be as important as providing a different
error message that is able to point people the right path, rather than
leaving them scratch their head on the seemingly false error provided.
