Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!mmdf
From: wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu
Newsgroups: comp.os.minix
Subject: Re: executable scripts?, and retraction of bovine exhaust
Message-ID: <52579@nigel.ee.udel.edu>
Date: 3 May 91 18:48:49 GMT
Sender: mmdf@ee.udel.edu
Lines: 29


Glen Overby wrote
>I disagree.  The shell should not be looking at executables; it should
>merely "exec" them and the kernel should determine what is REALLY done with
>the executable, be it loaded as a binary image or fed through an interpreter.
>
>By requiring the "shell" to check for executable scripts, you complicate any
>program which chooses to use exec(2) since it, too, must open the executable
>and check for an interpreter.  Any executable should be "exec"-able.

	What is an "executable"?  In the days before "#!" was in the
Berkeley kernel, the shell first tried to do an exec() and if this failed it
assummed that the file was in fact a shell script.  Having the shell look at
the first line of the file before assuming it is script for your particular
shell would not slow down the exec() (it's already failed) and really
wouldn't slow down interpreting of scripts much either since you have to
open and read them anyway.  If you later added support for "#!" to your
kernel, it would speed up the interpretation of such scripts slightly, but
wouldn't effect their functionality at all.  I'm not saying don't add this
to the kernel, but adding the code to the shell would provide much of the
functionality for most people.

				Bill Bogstad

Caveat:  Their would be one major difference between shell based and kernel
based handling of "#!".  If it is in the kernel, you can have setuid
scripts.  Such scripts are now frowned upon by many people as it is very
difficult to make standard shell scripts truly secure against crackers.
Some intepreters (like perl?) though can apparently handle this properly.