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