Ticket #336 (closed defect: wontfix)
Shell gives useless error message when a binary's interpreter is missing
Reported by: | jdreed | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | Upstream Utopia |
Component: | -- | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: | LP:335666 |
Description
Running old binaries (ez, for example) produces the incorrect error message "command not found", when what it really can't find is the interpreter.
We opened LP:335666. We tried to get a patch in the kernel (relevant threads at http://lkml.org/lkml/2009/7/9/74 and http://lkml.org/lkml/2009/7/30/211)
broder notes that in addition to affecting libc5 binaries:
I ran into this bug (or something very like it) when I was working on a cross-compiler toolchain for my phone. Long story, but the short version is that I found the pre-built compiler that Palm was supposedly using, and I was getting ENOENTs when I tried to run them on my Jaunty VM. So I think this is still worth pushing, but through kernel.org, not through LP.
We think that we can quote POSIX at them ( http://www.opengroup.org/onlinepubs/9699919799/functions/exec.html), which is pretty clear about ENOENT only applying to the file, and not the interpreter. EINVAL might be a better choice than the ENOEXEC in the original patch.
Someone who has time and background to argue with kernel developers should send mail again, with a new patch (Signed-Off and Tested) pointing out that the current behavior is not POSIX-compliant. The original patch can be found at the first lkml link above, and modifying it to return EINVAL should be easy.