Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cuae2!ltuxa!ttrdc!levy From: levy@ttrdc.UUCP Newsgroups: comp.unix.wizards Subject: Re: "special" shells a headache in make? (was: security hole) Message-ID: <1515@ttrdc.UUCP> Date: Mon, 16-Feb-87 21:11:24 EST Article-I.D.: ttrdc.1515 Posted: Mon Feb 16 21:11:24 1987 Date-Received: Tue, 17-Feb-87 21:15:20 EST References: <3953@brl-adm.ARPA> <2590002@hpisod2.HP> Organization: AT&T, Computer Systems Division, Skokie, IL Lines: 25 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