Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site sequent.UUCP Path: utzoo!watmath!clyde!akgua!mcnc!decvax!ucbvax!ucbcad!tektronix!ogcvax!sequent!merlyn From: merlyn@sequent.UUCP Newsgroups: net.unix-wizards Subject: Re: magic numbers Message-ID: <418@sequent.UUCP> Date: Fri, 9-Mar-84 12:57:32 EST Article-I.D.: sequent.418 Posted: Fri Mar 9 12:57:32 1984 Date-Received: Thu, 15-Mar-84 07:24:01 EST References: <2639@alice.UUCP> <199@opus.UUCP> Organization: Sequent Computer Systems, Portland Lines: 35 [from nbires!rcd...] [[ There's a lot of code in the Berkeley kernels to handle shell scripts - [[ take a look at it. Since (1) the number of applications which need to do [[ exec's of arbitrary programs is relatively small, (2) the cost of handling [[ scripts in user code is small compared to the rest of the fork/exec/start- [[ up-a-shell overhead, and (3) the shell-script handling can be reasonably [[ put in the library code where it is pageable, it seems that it would be [[ better off there, particularly if you're at all tight on memory. I will [[ also (re)state my opinion that the kernel is in a bad place (at least [[ awkward) for giving a good interpretation of errors in being unable to [[ "exec" a shell script - it would take STILL MORE precious kernel space for [[ the code to generate good error values, as well as yet more expansion of [[ the set of errno values. [[ -- The shell script code CANNOT be put into a library for certain cases. The one I think of is that you cannot then have execute-only shell scripts. The kernel MUST open the file, and make it stdin to the designated program. Arbitrary interpreters (ala /bin/sh) would not have enough power to open the file (if read-denied) and start up the desired other interpreter. Setuid interpreted scripts also become available as well (such as an execute-only, read-protected, setuid cshell script). This is also something that couldn't be done at the application level, but rather at the kernel level. I thank Berkeley for putting in this feature, and appreciate it (and use it) quite regularly. Randal L. Schwartz, esq. Sequent Computer Systems, Inc. UUCP: ...!tektronix!ogcvax!sequent!merlyn BELL: (503)626-5700 P.S. It's true... the infamous UUCP-breaker from last year is back! After 10 months of VMS, I get to play with UNIX again! What a deal.