Zsh Mailing List Archive
Messages sorted by:
Re: SHELL not always correct
- X-seq: zsh-users 13382
- From: Chet Ramey <chet.ramey@xxxxxxxx>
- To: Stephane Chazelas <Stephane_Chazelas@xxxxxxxx>
- Subject: Re: SHELL not always correct
- Date: Wed, 22 Oct 2008 21:36:23 -0400
- Cc: Chet Ramey <chet.ramey@xxxxxxxx>, dqarras@xxxxxxxxx, zsh-workers+phil.pennock@xxxxxxxxxxxx, ZSH Users <zsh-users@xxxxxxxxxx>, pws@xxxxxxxxxxxxxxxxxxx
- In-reply-to: <20081022142732.GB4959@xxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- Organization: ITS, Case Western Reserve University
- References: <903527.44182.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <200810212058.m9LKwXQe009278@xxxxxxxxxxxxxxxxxxx> <20081021231323.GA89901@xxxxxxxxxxxxxxxxxxxx> <48FE9074.5020103@xxxxxxxx> <20081022142732.GB4959@xxxxxxxxxxxxxxx>
- Reply-to: chet.ramey@xxxxxxxx
Stephane Chazelas wrote:
> On Tue, Oct 21, 2008 at 10:31:16PM -0400, Chet Ramey wrote:
>> Bash used to auto-export SHELL because programs like tset and make
>> still depend on its value. If the current version sets the value,
>> however, it doesn't export it.
> Hi Chet,
> What implementation/version of make uses $SHELL? I thought SHELL
> was meant to be *the* environment variable that make was meant
> *not* to read as it conflicts with its own SHELL variable.
Certainly no modern version of make does, especially since Posix
forbids inheriting SHELL from the environment.
I'm pretty sure that old System V versions of make used SHELL in this
way -- 7th edition didn't need to as it had only one shell, and BSD
inherited this behavior -- but I may be mistaken. I don't have any
System V makes lying around, but the documentation implies that the
environment is used unless a variable is explicitly assigned a value
in a makefile, and SHELL is not called out as an exception.
> What's the point of setting $SHELL and not exporting it, btw?
> does bash use $SHELL internally or is it just for the benefit of
Bash doesn't use SHELL internally. It originally used to export SHELL
for the benefit of commands (like tset) that changed their output
depending on the value of $SHELL, but even those programs ended up
checking *sh vs. *csh, and bash quit exporting it with bash-2.05a.
Though Bash never messed with an inherited value for SHELL, if it didn't
find one, we interpreted the Posix standard as allowing setting and
exporting its value -- we set SHELL to the full pathname to a shell
implementing the Posix standard. I changed it to the user's login
shell for bash-1.13, figuring that was closer to the intended use,
but kept exporting it.
Back in the day, and I'm sure zsh was in the same situation, there
were a lot of bash users whose default shell was csh, because that was
the "system's standard," but preferred to use bash. In those days, it
was useful to set SHELL to the full pathname of the running version of
bash, but even then bash never overrode an environment variable, and,
as I said above, that stopped after bash-1.12.
I finally decided that auto-exporting SHELL wasn't that great an idea,
and bash-2.05a quit doing that, but it's set to this day. It's
guaranteed to exist, and users can rely on its presence.
> Do you know of which systems where the SHELL environment
> variable is not set by login/cron/rshd...? On this debian
> system, cron sets it to /bin/sh, rshd/login/kdm to my login
Maybe not any more, but earlier systems were not quite so predictable.
> Looking around, I see AT&T ksh is the only other shell that sets
OK. Bash does what it does, though, and there's enough backwards
compatibility to leave the current behavior alone.
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU chet@xxxxxxxx http://cnswww.cns.cwru.edu/~chet/
Messages sorted by: