Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!styx!ames!ucbcad!ucbvax!decvax!decwrl!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: "make" SHELL variable
Message-ID: <14374@sun.uucp>
Date: Mon, 2-Mar-87 19:05:35 EST
Article-I.D.: sun.14374
Posted: Mon Mar  2 19:05:35 1987
Date-Received: Thu, 5-Mar-87 19:02:01 EST
References: <3953@brl-adm.ARPA> <2590002@hpisod2.HP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 24

>If you need to have environment variables visible to make, the only
>reasonable thing to do is to take all of them.

Leaving aside the question of whether absolute consistency is
preferable to not breaking Makefiles, I simply point out that even if
"make" imports the environment variable SHELL it need not use it to
decide which shell to use to run commands!  It can just say "I run
things with '/bin/sh', and that's that."

To put it bluntly, it is incorrect for "make" to cause the behavior
of a Makefile that may be used by several people to build some piece
of software to depend on a user-preference item like the setting of
the SHELL environment variable.  If this causes "make"s behavior to
have a small wart, so be it.

>It has always been easy enough for me to put 
>
>	setenv SHELL /bin/sh
>
>in my .login to mollify make.

And possibly confuse other programs that use SHELL to determine which
shell to use when handling a "shell escape" command - or, more
likely, confuse the user who tries to use a "shell escape" command.