Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: file attributes
Message-ID: <8509@auspex.auspex.com>
Date: 24 Jun 91 18:58:43 GMT
References: <1743@sranha.sra.co.jp> <1991Jun20.021749.12011@gpu.utcs.utoronto.ca> <1991Jun21.191521.12644@sco.COM>
Organization: Auspex Systems, Santa Clara
Lines: 32

>|	*Please* don't bloat the kernel with features that belong in
>|user mode.
>
>You mean like the #! hack?

Heh.  Well, for the benefit of those who haven't figured it out yet,
"bloat", when used in software discussions, is pretty much a noise-word
these days, used only in ritual denunciations of "bloat".  I recommend
its retirement....

However, depending on what meaning (if any) you'd assign to "bloat",
"the #! hack" may or may not "bloat" the kernel; by my count, it adds 60
lines to "kern_exec.c" in 4.3BSD, for example.

Presumably, your user-mode version would be done in the "execve()"
library routine - i.e., instead of just being a wrapper around the
"execve()" trap, as it is in most existing UNIX implementations, it'd
check for ENOEXEC and, if that was the error, it'd check for a "#!"
line, shuffle the argument list, and invoke the program specified by the
"#!" line?  (That'd lose the set-UID/set-GID capability, but it's not
clear whether that's really a loss or not - even if you fix the known
bugs with the set-UID shell script mechanism, would *you* trust some
arbitrary shell, or the "awk"/"perl"/whatever interpreter, and the
language it implements sufficiently that you'd want to write set-UID
scripts in that language?)

If not, it's not interesting, because it's not transparent.  The reason
for a "#!" mechanism is to allow scripts to be executed *just like
programs*.  And no, it's not at all clear that all uses of the "execv"
or "execl" family of calls would want to be replaced by "execvp" or
"execlp" calls, and those calls only understand Bourne shell scripts in
any case....