Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!gatech!gitpyr!robert From: robert@gitpyr.UUCP Newsgroups: comp.unix.wizards Subject: Re: \"special\" shells a security hole? Message-ID: <3063@gitpyr.gatech.EDU> Date: Mon, 9-Feb-87 08:59:06 EST Article-I.D.: gitpyr.3063 Posted: Mon Feb 9 08:59:06 1987 Date-Received: Tue, 10-Feb-87 04:47:25 EST References: <3953@brl-adm.ARPA> <2590002@hpisod2.HP> <3037@gitpyr.gatech.EDU> <1317@ho95e.ATT.COM> <169@quacky.mips.UUCP> Reply-To: robert@gitpyr.UUCP (Robert Viduya) Organization: Office of Computing Services, Georgia Tech Lines: 31 >dce@quacky.UUCP (David Elliott) (dce@quacky.UUCP, <169@quacky.mips.UUCP>): > > The idea of using the SHELL environment variable is something that > really wreaks havoc when you port the System V.2 or better version > of make(1) to a BSD system (or use it in System V.3). Take a look > around and count how many makefiles would break if run using csh > instead of sh. The person that came up with this method really needs > a talking to. We ended up changing sh to not import the value of > SHELL from the environment. If a makefile needs to use a different > shell, it should be specifiable on a per-makefile basis, instead > of having the user screw something up unknowingly. > shell, the user can just > On a 3B20 running SVR2.0v2, the shell IS specifiable on a per makefile basis. Just include "SHELL=/bin/sh" near the beginning of the makefile. I'm fairly sure the same applies to SVR3.0 (can't tell right now, my 3B2 died of a power failure last night and I haven't brought it back up yet). According to the manual page, macro definitions in the makefile are processed AFTER the environment variables are processed, which means that macro definitions override environment variables where-ever a conflict occurs. (Unless, of course, you use the -e option.) robert -- Robert Viduya robert@pyr.ocs.gatech.edu Office of Computing Services (404) 894-4660 Georgia Institute of Technology Atlanta, Georgia 30332