Bug 22755

Summary: Errors reports about the interpreter on scripts are bogus
Product: Base System Reporter: mwm
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description mwm 2000-11-10 20:20:00 UTC
If an error is found with the interpreter in an executable script, the
error with the interpreter is reported to the shell, which then
reports the problem to the user as belonging to the script. So the
user winds up seeing "/usr/local/bin/script: No such file or
directory" or "/usr/local/bin/script: Permission denied" and so on,
even though "which script" reports /usr/local/bin/script, and the
permission are clearly correct, and in general the problem isn't with
the script. These error messages are at best misleading, and at worst
wrong.

This is a kernel problem, as its error indication is wrong. There's
no way for the shell to do anything other than what it does.

Fix: The attached patch solves the problem. The first file patched
(kern_exec.c) fixes the problem proper. Any errors found with the #!
line or when trying to execute an interpreter are changed to
EINVALINTERP. If the problem occurs before the shell image activer
gets started, the actual error is reported, and is probably correct
(i.e. - if the permissions on the script are wrong, it gets reported
as such).

I couldn't find an error I thought was appropriate. The second two
files patched (errlst.c & errno.h) add the EINVALINTERP error. If you
think an existing error is a good match, change EINVALINTERP in the
first file patched to that error, and skip the second two files. In
fact, I first tested the patch by using EFTYPE.  The last file patched
(imgact_shell.c) is just cleanup. It currently returns ENOEXEC if
there are problems, which the first patch will change to EINVALINTERP
(or whatever), which seems cleaner. Leaving it off won't change the
behavior of the system after the first patch is applied.

If the new error number is used, shells that statically link libc will
just report "error 87" or some such until they are relinked.
How-To-Repeat: 
Create a mode 755 file on your path with first lines like:
#!/dev/null/notthere or #!/etc/fstab or #!/usr/bin/shar and notice
that you get messages that finger the script, but apply to the file
you listed in the executable.
Comment 1 Alfred Perlstein freebsd_committer freebsd_triage 2000-12-10 02:41:35 UTC
State Changed
From-To: open->closed

It would be nice, however this breaks standards compliance. 
The shell should be smarter and try to investigate why it got ENOEXEC.