Problems with System V Release 2.1 on 68010

[Robert Elz]

In article <412 at hropus.UUCP>, ka at hropus.UUCP (Kenneth Almquist) writes:
> An alternative approach is to have the shell handle "#!".

If you do this you lose what is one of the main advantages of #!,
that is that exec() works on them from any parent, not only shells.
You could build handling of #! into execvp() I suppose, and then
require ever program to use execvp() rather than execve() (and close
relations) but don't you think that this is one place where the
kernel really is the right solution.

The claim of effeciency loss is largely a red herring.  Most of the
costs have already been born (a bad pun?) by the shell by the time
it would look for the #! anyway - its done the fork, its done the
path search for the exec, etc.  The only thing you save is the
work of the exec itself, and for a shell exec'ing itself that's
not as much as you might expect.  The text is going to be shared
with the parent, the data space is pretty small, there just isn't all
that much to do.  (For csh of course this isn't true, but csh was
never able to avoid the exec in any circumstances...)  NB: I'm not
claiming that there's no loss, just that the magnitude of the loss
isn't likely to be enough to really trouble anyone.  If you're writing
a set of command procedures, and you know how they are going to be
used (from each other) then you can always just omit the #! and
have the shell operate the old way, and gain all your effeciency back.

And continues...
> Allowing you to unset PATH would be difficult.

I'm not sure why.  If you can exec a shell with no PATH set,
the shell has to do something sensible (which may be defined
as using a default built in PATH, or simply having no path
at all and only exec'ing commands when given path names that
find them).  I can't see why unsetting PATH should be any different.

Robert Elz		seismo!munnari!kre   kre%munnari.oz at seismo.css.gov