SVR3.0 vs BSD4.3

[John Macdonald]

In article <7514 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>[response to:]
>In article <2423 at bsu-cs.UUCP> dhesi at bsu-cs.UUCP (Rahul Dhesi) writes:
>>[lots of detail differences where BSD4.3 is "preferred" than SVR3.0]
> ...
>[excellent response to most points]
>
>>   support for multiple command interpreters with #! as first line of script
>
>This is totally unnecessary; if all scripts are executed by a Bourne
>shell, it is easy to simulate the #! feature, in fact to generalize
>on it.  Nevertheless I think AT&T may be adding this kludge to the
>kernel exec code in a future release, alas.

I think you are going a bit too far here - it is easy to get sh to invoke
another interpreter on a script, but not allowing the full capability
that #! provides (unless I'm missing some clever sh trick).  In particular,
I don't think you can cause the command "file args" to effectively invoke
"interp [path/]file args" and keep the name of the file available to
the interpreter (for $0 type use).  If $0 is not needed, of course, the sh
script can just execute the interpreter with the rest of the script sent to
its standard input.  (Chip Salzenburg (sp?) recently provided a neat hack
to allow perl programs to be executed either by sh or directly by perl,
but it depended upon clever use of a statement that turns out to be an
exec in sh, but a no-op in perl.)

I can recall ("was it really?" 15 years ago) the idea that the shell
was simply a user program that anyone could replace was referenced as
demonstrating the simplicity and elegance of the design of Unix.
Unfortunately, this idea breaks down (slightly) because scripts are
invoked by the shell, and there was no way to specify *which* shell
should be used.  (This is similar to the fact that a compiled program
can usually only run on one type of hardware.  However, that has not
been a pressing problem for most of us and COFF does provide a
mechanism for specifying which hardware it must run on, even if very
few Unix implementations currently allow it to be acted upon.)

Using #! is definitely a kludge.  Exec is neccessarily a function of the
kernel, but the method of invoking it should be under the user's control.
Why should the searchpath not be available when the indirection to the
interpreter is being done?  Because it is in the kernel and search is
done by the shell, so the kernel #! processing doesn't know about it.
Providing setuid on scripts is a huge security risk, despite its great
convenience.

Using #! is an easy solution in most regards.  It is consistent with
the BSD world and mostly solves the problem.

The *right* alternative (as I see it) is to put #! checking into sh (and
csh, ksh, and any other program that doesn't just use the system("command")
function to figure it all out) as well as into the system library routine.
This would allow using the search path both for finding the script and the
interpreter (and the interpreter's interpreter...).  And it would get rid
of the current situation where all interpreters are equal, except sh which
is a bit more equal.
-- 
John Macdonald   UUCP:    {mnetor,utzoo}             !spectrix!jmm