On Mon, Dec 20, 1999 at 04:28:27PM +0100, David Korn wrote:
>
> > Maybe my text fragment below is usable.
> >
> > From: David Korn <yyy@xxxxxxxxxxxxxxxx>
> >
> > > Everybody supports #! - why not standardize it?
> >
> > I don't support #! because it puts absolute pathnames
> > inside scripts.
> >
> > It need not. Some Unix flavours allow #!perl.
> Yes, but the problem with this is that the system needs to
> do a PATH search for perl or have the pathname embedded
> into the kernel. It is not a good idea to have the
> path search algorithm buried into the kernel where it
> needs to use environment variables. In addition, there
> is no guarantee that the search semantics will be identical.
>
> However, if the syntax were
> #! name
> where there was a file /etc/interepreters which contained
> the interpreter name and the pathname, that would work.
This would need another system call to load the path names into the kernel.
And how would you keep the semantics per user? User mays want to define their
own
interpreters. You could use a scheme similar to groups where it the table set
by
login and inherited for the session. This has the same problems as groups as
that
you cannot easily change this without restarting the whole session (sans hacks
like
newgrp). It could not be kept over suid changes, because it could be used to
create a security hole when some suid program execs a a script. But the user
still
wants to change it for legitimate reasons. So you would need a special bit per
table
entry that says "is safe across credential changes" and those could be only
overwriten
by root. It gets more and more complex.
A global + a per session table is also not possible, because not all systems
have the
concept of a session id. The groups approach has too many disadvantages IMHO.
Overall I would think /etc/interpreters is not worth the hazzle.
-Andi
|