chris@mimsy.UUCP (Chris Torek) (09/27/88)
In article <128@cetia.UUCP> chris@cetia.UUCP (Chris Bertin) writes: >If 'make' had been modified to get its shell from a different variable (say >'MAKESHELL', for example), no existing makefiles would have been broken and >you would still be able to use a different shell. It is a misfeature. Right. More generally, the problem is that the environment variable $SHELL has the meaning `user's preferred shell', and Makefile commands have the meaning `hand this to the shell the Makefile says to use'. When the two do not conflict, things work out, but the two *do* conflict, and too often. $SHELL and the shell-to-be-used-by-make are simply two different things. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ed@mtxinu.UUCP (Ed Gould) (09/29/88)
>$SHELL and the shell-to-be-used-by-make are simply two different things.
Too true! I work around this nuisance with
alias make make SHELL=/bin/sh
Even though $SHELL is /bin/csh. Something similar can be done in ksh.
--
Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA
{ucbvax,uunet}!mtxinu!ed +1 415 644 0146
"I'll fight them as a woman, not a lady. I'll fight them as an engineer."dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/30/88)
In article <13753@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >More generally, the problem is that the environment variable $SHELL has >the meaning `user's preferred shell'... I think the problem is that $SHELL exists at all. It's a poor substitute for the #! in 4.3BSD. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ggs@ulysses.homer.nj.att.com (Griff Smith) (09/30/88)
In article <4147@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > In article <13753@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >More generally, the problem is that the environment variable $SHELL has > >the meaning `user's preferred shell'... > > I think the problem is that $SHELL exists at all. It's a poor > substitute for the #! in 4.3BSD. > -- > Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi I won't contest the argument that $SHELL is overloaded. As a definition of "the interactive shell that I would prefer to use" it serves well enough, but it has problems when overextended to include program interpretation. $SHELL would be more useful if spit into at least two names; possibly $ISHELL (interactive) and $ESHELL (execution). 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. I usually don't follow Dave's advice on this one; the "#! /bin/ksh" at the top is good documentation of my intentions and I am not as much of an optimizer as I used to be. -- 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
jfh@rpp386.Dallas.TX.US (The Beach Bum) (10/01/88)
In article <4147@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <13753@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>More generally, the problem is that the environment variable $SHELL has >>the meaning `user's preferred shell'... > >I think the problem is that $SHELL exists at all. It's a poor >substitute for the #! in 4.3BSD. $SHELL has more uses than running shell scripts, and does not in fact replace the #! mechanism. $SHELL is useful for programs which support escapes to the user's shell and shell commands from within the program. in those situations the user should get the desired shell and #! would not have added in doing the right thing. #! is used to select the correct shell interpreter for a given shell script. in this case $SHELL may [ and probably will since murphy's law dictates it is so ] be different than the shell interpreter which is being used. the two have nothing to do with each other. -- John F. Haugh II (jfh@rpp386.Dallas.TX.US) HASA, "S" Division "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
nick@ccicpg.UUCP (Nick Crossley) (10/01/88)
In article <4147@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >I think the problem is that $SHELL exists at all. It's a poor >substitute for the #! in 4.3BSD. >-- >Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi It is not only used for scripts, but also for deciding which shell is used to process ! commands from vi and other such tools. It is not easy to see how to extend #! to these facilities. -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/01/88)
In article <7350@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: >$SHELL is useful for programs which support escapes to the user's shell >and shell commands from within the program. in those situations the user >should get the desired shell and #! would not have added in doing the >right thing. This information is already available in /etc/passwd and, with the help of the dbm routines in 4.3BSD, available very quickly. I'll admit that on rare occasions a user might want to override this information, and $SHELL might be a way to do this. But $SHELL seems to be the only automatic mechanism under System V to allow the user to specify which shell should be used to interpret a script. Therefore my original claim, that $SHELL is a poor substitute for #!, is relevant. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
tanner@ki4pv.uucp (Dr. T. Andrews) (10/01/88)
In article <4147@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
) I think the problem is that $SHELL exists at all. It's a poor
) substitute for the #! in 4.3BSD.
The "#!" mechanism and the $SHELL mechanism address different issues.
One is not a substitute for the other.
The first tells the exec(2) family what interpreter should be used
on a "program", since it is not executable. This causes, eg, "csh"
scripts to be run with "csh".
The second is used by certain applications which wish to spawn a user
shell. A common case is the "ex" family of editors, which have a "sh"
command to give you a sub-shell without losing your editing session.
Neither of these mechanisms is suitable for determining how commands
should be interepreted in a "Makefile". It might be clever to start
a Makefile with the line "#! /bin/make SHELL=/bin/sh", and make the
Makefile executable, so that you said "Makefile" instead of "make".
The mistake of importing $SHELL for Makefiles has been made already,
so the clever writer will probably try to include a "SHELL=" line,
not because it is a good thing, but simply for safety.
--
...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!cdis-1!ki4pv!tanner
or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!tannerdik@cwi.nl (Dik T. Winter) (10/01/88)
In article <4164@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > In article <7350@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) > writes: > >$SHELL is useful for programs which support escapes to the user's shell > >and shell commands from within the program. in those situations the user > >should get the desired shell and #! would not have added in doing the > >right thing. > > This information is already available in /etc/passwd and, with the help > of the dbm routines in 4.3BSD, available very quickly. > > I'll admit that on rare occasions a user might want to override this > information, and $SHELL might be a way to do this. > This need not be so very rare. What if I come up with a nice new shell that is not listed in /etc/shells? It will not be available through /etc/passwd. (Yes I have done such a things; during a long time my loginshell was /bin/sh and .profile started with the equivalent of SHELL=nice-new-shell exec $SHELL So there.) -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
henry@utzoo.uucp (Henry Spencer) (10/02/88)
In article <4147@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >I think the problem is that $SHELL exists at all. It's a poor >substitute for the #! in 4.3BSD. It's not intended to be a substitute for #!; its purpose is to indicate which shell should be used when activating an *interactive* shell, e.g. in a shell escape. -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.ARPA (Doug Gwyn ) (10/03/88)
In article <4147@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <13753@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>More generally, the problem is that the environment variable $SHELL has >>the meaning `user's preferred shell'... >I think the problem is that $SHELL exists at all. It's a poor >substitute for the #! in 4.3BSD. So far as I know, no shell uses the SHELL environment variable to determine what shell to use when "exec"ing a shell script. SHELL is used when setting up a new layer or window, etc.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/03/88)
I said that $SHELL is a poor substitute for the #! in 4.3BSD. In article <8616@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >So far as I know, no shell uses the SHELL environment variable >to determine what shell to use when "exec"ing a shell script. > >SHELL is used when setting up a new layer or window, etc. This seems to be correct. I investigated and found no evidence that SHELL is used to decide which shell should be used to interpret a script. It seems that System V has no substitute for the #! in 4.3BSD. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
tanner@ki4pv.uucp (Dr. T. Andrews) (10/04/88)
In article <4164@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
) But $SHELL seems to be the only automatic mechanism under System V to
) allow the user to specify which shell should be used to interpret a
) script.
Unfortunately for this argument, $SHELL is not generally used under
sys5 to decide which shell should be used to interpret a script.
--
...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!cdis-1!ki4pv!tanner
or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!tannerdavidsen@steinmetz.ge.com (William E. Davidsen Jr) (10/05/88)
In article <4180@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: | It seems that System V has no substitute for the #! in 4.3BSD. I seem to recall that there is a similar feature, something like : use /bin/csh or so. The auto-config routines check for it, but I don;t have them handy. Hopefully someone has a better memory than mine. | -- | Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
chris@mimsy.UUCP (Chris Torek) (10/05/88)
>In article <4164@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >>But $SHELL seems to be the only automatic mechanism under System V to >>allow the user to specify which shell should be used to interpret a >> script. In article <7048@ki4pv.uucp> tanner@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@mimsy.umd.edu Path: uunet!mimsy!chris
nick@ccicpg.UUCP (Nick Crossley) (10/08/88)
In article <13872@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >In article <7048@ki4pv.uucp> tanner@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@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