"special" shells a headache in make? (was: security hole)

[dce at mips.UUCP]

In article <1515 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) writes:
>In article <177 at quacky.mips.UUCP>, dce at mips.UUCP writes:
>>I don't disagree with being ABLE to use a different shell, but I disagree
>>
>>As Doug says, it isn't right that I have to edit already-working makefiles
>>just because AT&T decides to allow the SHELL variable. Maybe you don't
>>have 300-400 makefiles to maintain (I'd bet that Doug has thousands), but
>>some of us do, and don't like the idea of having to change every one of
>>them just to make them work again (note the operative word is "again").
>
>I do sympathize with you (despite being a hacker from the Death Star :-) ).
>But there's an easier "workaround" than modifying zillions of makefiles.
>Just create a shell script, shell function, or alias which sets SHELL=/bin/sh
>in a subshell, then execs your favorite :-) make program with the proper
>arguments.  The function or alias need not be known to the make process itself
>since once SHELL is set to /bin/sh in the environment it will propagate
>automatically to sub-makes.

Tell that to some of our customers. Tell that to the people that actually
build our systems:

	"What? I have to have a special shell script just to build this
	 correctly?"

Things that require workarounds are called "bugs". The release notes to
the product I produce contains a list of things just like this. Some of
them are caused by mistakes I made. Some are caused by mistakes made
by other people in the company. Some are caused by people that didn't
write portable code. Some are caused by people that hacked the code.
Some are caused by someone not giving a thought to the wonderful new
feature they just came up with. (Another good example of this is
why <<-, which breaks shell scripts, was used instead of <<#, which is
syntactically incorrect in early shells. No thought; just blind hacking.)

In other words, I either have to modify zillions of makefiles or change
make to not import SHELL from the environment. I did the latter because
I have customers that don't want to have to have to do magic to get things
to work.

I'd also like to point out that the use of an environment variable for
the execution shell has been independently invented by a number of
people in one form or another (MAKESHELL, for example). It's OK to
implement without thinking, just as long as you don't try to force the
entire world to live with it ;-).

-- 
			David Elliott

UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD:  	408-720-1700