make importing SHELL

[Nick Crossley]

In article <13872 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>
>In article <7048 at ki4pv.uucp> tanner at ki4pv.uucp (Dr. T. Andrews) writes:
>>Unfortunately for this argument, $SHELL is not generally used under
>>sys5 to decide which shell should be used to interpret a script.
>
>... which is, of course, fortunate for users.  The interpreter needed
>to run a script is a property of the script, just as the shell needed
>to run makefile commands is a property of the makefile.  The user's
>environment has nothing to do with either.
>-- 
>In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
>Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris

There is an important exception to what Chris says; when you want to change
to an upwards-compatible shell for additional features and/or bug fixes.

Thus, a script may have been written for shell X, then along comes a new
shell Y (which may be just a bug-fixed version of X in a testing directory,
or a new shell, as ksh is to sh).  We may then wish to run all (or some,
for the test case) X scripts using Y.  One cannot of course do this by
changing something in all the X scripts, because in the replacement case
not all users may have switched to Y at the same time, and in the testing
case the change is only temporary.

SHELL/MAKESHELL/whatever gives one a way of doing this for Makefiles, but
that is only a small part of the problem.  #! is not of much use here, as
it needs (I believe) an absolute path name.

This is then further complicated by 'intelligent' shells and makes which
attempt to minimise the number of forks and/or execs used, and may thus
do things themselves one might have thought handled by a separate shell.

-- 

<<< standard disclaimers >>>
Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA
Tel. (714) 458-7282,  uucp: ...!uunet!ccicpg!nick