dce@mips.COM (David Elliott) (10/01/88)
In article <10669@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes: >However... #! is not a substitute. I have heard Dave Korn argue on >several occasions that #! gets in the way. If $SHELL is set to point >to ksh, a shell script can be executed by forking and interpreting the >script in the child (don't ask about the kludges required to make this >work reliably, I don't think I want to know). If #! is present, ksh >must fork and exec unless it uses additional kludges to parse the rest >of the #! line to determine whether the designated interpreter is ksh. Kludges required to make this work reliably? How about the kludges required to make it work correctly? If you write a shell script that uses a standard command, such as ls, and you have an alias or function called ls that runs the output from the standard ls through a filter to change its output, your script could fail. Unless ksh tosses all aliases and functions when it starts a subshell, this can happen. This is even worse when the user of the script isn't the author and didn't set up his/her aliases in the first place (we have many users that are using the same startup scripts they were given when they got here, and have no idea that the command 'mail' is an alias for a special command). How do you explain to a novice that they have to get rid of a command they are used to using because ksh is trying to be fancy? -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
ggs@ulysses.homer.nj.att.com (Griff Smith) (10/01/88)
In article <4273@dunkshot.mips.COM>, dce@mips.COM (David Elliott) writes: | In article <10669@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes: | >If $SHELL is set to point | >to ksh, a shell script can be executed by forking and interpreting the | >script in the child (don't ask about the kludges required to make this | >work reliably, I don't think I want to know). | | Kludges required to make this work reliably? How about the kludges | required to make it work correctly? | | Unless ksh tosses all aliases and functions when it starts a subshell, | [confusing execution of scripts] can happen. It does toss them, unless you "export" the aliases. This is considered to be another performance enhancement; you can avoid having to read the definitions from the .env file. I think the feature is confusing, since it promises something that can't always be delivered unless #! is outlawed and $SHELL is set to a name of ksh. If I remember correctly, V9 does export functions. Since I haven't used it, I don't know how the design avoids confused execution in naive scripts. -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: 1-201-582-7736 UUCP: {most AT&T sites}!ulysses!ggs Internet: ggs@ulysses.att.com
gwyn@smoke.ARPA (Doug Gwyn ) (10/03/88)
In article <10678@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes: >If I remember correctly, V9 does export functions. Yes, at least so the manual says. >Since I haven't used it, I don't know how the design avoids confused >execution in naive scripts. Me either (it's not just scripts that would be affected). Note also that older Bourne shells will barf and die if one's environment contains any such critter as an exported function. Therefore when we were adopting V8/V9, csh/tcsh, and ksh features for the BRL Bourne shell, we took a different approach. Our shell sources a file named by the ENV environment variable, only when starting an interactive shell. Non-interactive uses of the shell such as scripts can do their own sourcing of files containing function definitions etc., thank you very much. This is more general and less troublesome than either the V8/V9 or ksh solutions to the same problem. The efficiency difference is negligible.