levy@ttrdc.UUCP (02/17/87)
In article <177@quacky.mips.UUCP>, dce@mips.UUCP writes: >I don't disagree with being ABLE to use a different shell, but I disagree >with the method that was used to implement it. > >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. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, allegra,ulysses,vax135}!ttrdc!levy
dce@mips.UUCP (02/19/87)
In article <1515@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <177@quacky.mips.UUCP>, dce@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
matt@LOCUS.UCLA.EDU (03/09/87)
An alternative to modifying 'make' and/or all of your Makefiles would be to move /bin/make to /bin/make.new, and create a short shell script in place of /bin/make: #!/bin/sh SHELL=/bin/sh export SHELL exec /bin/make.new Voila, original semantics (nearly) restored with only slight additional overhead. And you can use the new make too... (You can cook up more elaborate scripts if you want to pass the original SHELL value through to some programs...). Sub Sub rs