gwyn@brl-smoke.UUCP (02/14/87)
In article <3088@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes: >I disagree completely. Adding "SHELL=/bin/sh" is an extremely trivial I wasn't arguing against "make" allowing definition of the shell to use in the Makefile, which is after all written with a particular shell in mind (so the Makefile is an appropriate place to specify it), but rather against it paying any attention to the environment variable SHELL, which users often set to things like /bin/csh which have nothing to do with the Makefile's contents.
dvadura@watdaisy.UUCP (02/16/87)
The question of what shell is used inside make only becomes a problem during
those command sequences inside the makefile that are essentially shell
scripts. Writing such command sequences makes your makefile non-portable to
anything but machines containing compatible shells. There is however a side
issue to all this. Most shells provide some form of redirection and
pipelining if the OS supports it. It is in these instances that it would be
advantageous to have make read the SHELL variable or MAKE_SHELL variable
(what you really call it makes little difference) from the environment.
Since make can then use the proper shell based on host machine/os combination.
I propose, and have implemented the following rules for a version of make
that is soon to be released. This make is an attempt at unifying those
features of most use found in unix make, adding some features not
found in any unix make, fixing bugs/annoyances found in unix make, and
making the code usable on a wide variety of machines. (so far this includes
vax family, MS-DOS boxen, amiga, and soon Sun, Sys V, etc. ) Thus the point
of SHELL is important here.
So here are the rules in order of priority (highest to lowest):
1. if you do not mention SHELL anywhere make will use the default compiled
in shell. (eg. unix == /bin/sh, DOS == command.com, etc ...)
2. if you mention SHELL in command line or in makefile then that is the SHELL
that is used. unless you say SHELL= in this case the default shell is
used.
3. if you say -a or -e, (-e == read environment strings) and SHELL is defined
in the environment, (-a == look for shell in environment, -e superceeds -a)
then that value of SHELL is used provided SHELL is NOT mentioned anywhere
that rule 2 applies.
This way SHELL found in environment strings can only be used if SHELL is not
mentioned anywhere else, and you must specifically request for it to be used.
--
--------------------------------------------------------------------------------
Dennis Vadura, Computer Science Dept., University of Waterloo
UUCP: {ihnp4|allegra|utzoo|utcsri}!watmath!watdaisy!dvadura
================================================================================ken@rochester.UUCP (02/16/87)
Re: proposal to honor SHELL env variable. This is not such a big deal. A far more useful feature I have wanted in make is conditional substitution in macros. Ken
billj@zaphod.UUCP (02/22/87)
In article <8139@watdaisy.UUCP> dvadura@watdaisy.UUCP (Dennis Vadura) writes: >It is in these instances that it would be >advantageous to have make read the SHELL variable or MAKE_SHELL variable >(what you really call it makes little difference) from the environment. The AT&T Toolchest Nmake, which we're using here, looks in MAKESHELL and secondarily SHELL for the shell to use. In both cases, an assignment in the Makefile or on the command line overrides the environment. Nmake is supposed to be bought after the Korn shell, which should remove the problem about your interactive shell being unsuitable, but the separate variable is nice for renegades like us who haven't bought Ksh yet and still use the Bourne shell in Makefiles and C shell interactively. In keeping with the sentiments expressed earlier, Nmake here has been restrained from importing SHELL for now. >I propose, and have implemented the following rules for a version of make >that is soon to be released. This make is an attempt at unifying those >features of most use found in unix make, adding some features not >found in any unix make... Nmake does all sorts of Neat Stuff (including, as ken@rochester.ARPA wished for, conditional macros). Have you looked at it to see if you're reinventing the wheel? There's a paper in the Summer '85 Usenix proceedings; or see the on-line Toolchest description at (201) 522-6900, login "guest". -- Bill Jones, Develcon Electronics, 856 51 St E, Saskatoon S7K 5C7 Canada uucp: ...ihnp4!sask!zaphod!billj phone: (306) 931-1504
daveb@rtech.UUCP (03/02/87)
Many people have complained about or been bitten by the SV make's
importation of the SHELL variable. It certainly catches me by surprise
once every six months or so.
Therefore, I reluctantly say that this behaviour is _correct_, and that the
wishes that it would ignore SHELL are _wrong_.
If you need to have environment variables visible to make, the only
reasonable thing to do is to take all of them. The interpretation rule
is now clear:
Command line > environment > Makefile > default
Creating a list of exceptions would only encourage entropy. It has
always been easy enough for me to put
setenv SHELL /bin/sh
in my .login to mollify make.
--
It's hard to type with asbestos gloves.
{amdahl, sun, mtxinu, cbosgd}!rtech!davebguy@gorodish.UUCP (03/03/87)
>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.
thomas@spline.UUCP (03/03/87)
In article <688@rtech.UUCP> daveb@rtech.UUCP writes: > The interpretation rule is now clear: > > Command line > environment > Makefile > default > This line voids your thesis. It shows that you, who claim to support the current mode, are still confused about how it works. The true order (thank goodness) is Command line > Makefile > environment > default This reminds me of an early version of spell that would fail if you had a variable named I set in your shell. =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)
ed@mtxinu.UUCP (03/03/87)
I agree with Guy Harris's assesment of what would be right for make: to always use /bin/sh, like the old days. >>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. The workaround I use - that avoids just this side effect - is alias make make SHELL=/bin/sh Since variables set on the command line override those from the environment, this works. It breaks makefiles that explicitly assigh tht SHELL variable, though. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
simon@its63b.UUCP (03/04/87)
In article <688@rtech.UUCP> daveb@rtech.UUCP (Dave Brower) writes: >Many people have complained about or been bitten by the SV make's >importation of the SHELL variable. It certainly catches me by surprise >once every six months or so. > >Therefore, I reluctantly say that this behaviour is _correct_, and that the >wishes that it would ignore SHELL are _wrong_. > >If you need to have environment variables visible to make, the only >reasonable thing to do is to take all of them. Ok, whether it should do it or not is a bit contentious, but I'm sure everyone will agree that if it *does* import variables from the environment, it SHOULD DO IT PROPERLY!!! (thump desk with fist :-)). At present, it binds environ variables to make variables using the wonderful strategy: oh look, they've put "glorkz=mumble" in their environment, so I'll treat that just like a "glorkz=mumble" assignment in Make. I'll just use my standard way of doing this, ie parse it into <name> = <value>, where any blank space around the "=" is ignored. This is fine for most variables (ie, no nasty surprises), but if the value of the string happens to begin with characters that Make considers to be blank space, then these get removed. THIS IS A BUG!! (For example, IFS=<space><tab><newline> gets turned into IFS=<null-string>). The only way to get 'round this is to explicitly put double-quotes around the values of shell-variables which you suspect might have "blanks" at the start (sort of, `IFS=\"<space><tab><newline>\"'), but this is obviously dead crappy (and causes problems in other places instead). I guess it's what I deserve for doing a "export *" :-) Simon. -- ---------------------------------- | Simon Brown | UUCP: seismo!mcvax!ukc!{its63b,cstvax}!simon | Department of Computer Science | JANET: simon@uk.ac.ed.{its63b,cstvax} | University of Edinburgh, | ARPA: simon@{its63b,cstvax}.ed.ac.uk | Scotland, UK. | ---------------------------------- "Life's like that, you know"