Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: symbolic links  and csh execution
Message-ID: <22663@sun.uucp>
Date: Sun, 5-Jul-87 04:01:24 EDT
Article-I.D.: sun.22663
Posted: Sun Jul  5 04:01:24 1987
Date-Received: Sun, 5-Jul-87 08:36:00 EDT
References: > <2211@bunker.UUCP> <1097@mtune.ATT.COM> <500@its63b.ed.ac.uk>
Sender: news@sun.uucp
Lines: 37

> Unfortunately, execution of a "program" only makes sense from within an
> interpreter environment (such as sh, csh, ...). After all, the command
> "/bin/cat" that gets executed by a "#!/bin/cat" interpreter could have
> widely different interpretations depending on who is executing it.

What?   You don't have to be a shell to execute a program, so I don't see
where an "interpreter environment" comes into it.  "init" and "login"
aren't interpreters in any commonly understood sense of the word
(perhaps in a trivial sense, but that's it), and they execute plenty
of programs.

Furthermore, there is only one interepreter that's *supposed* to
execute "/bin/cat", and that's the one implemented by the hardware,
microcode, and supporting software (kernel, etc.)  on your machine.
Yes, if you treat "/bin/cat" as a shell script it will have a
different (and probably not very interesting) interpretation, but so
what?

> I would quite like to use pipes, i/o redirection, shell-variables, etc... in
> a #!

It's not clear that generalizing "#!"  so that the interpreter it
executes is an arbitrary shell command or pipeline, and not just a
single program, would be worth the costs.  It would require
hardcoding either information about the command syntax of some
particular shell into the kernel, or hardcoding rules telling it to
run the command line in question through a particular shell or shells
into the kernel.  Both would increase the complexity of the
implementation, and hardwire things that shouldn't be hardwired.

Furthermore, it would mean that "execve" and company would not be
guaranteed only to change the image running in the current process;
they would have to fiddle the file descriptors of that process, spawn
new processes, etc., etc., etc..
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com