Ticket #336 (closed defect: wontfix)

Opened 15 years ago

Last modified 14 years ago

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.

Change History

comment:1 Changed 14 years ago by jdreed

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.

comment:2 Changed 14 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix

Documented.  http://kb.mit.edu/confluence/x/zTlB

We will not be fixing this ourselves. #476 has an item to deal with this upstream. Closing this ticket.

Note: See TracTickets for help on using tickets.