SHELL not always correct

SHELL not always correct

[Daniel Qarras]

Dear List,

I'm wondering is this a bug or a feature:

localhost:~> echo $SHELL 
/bin/zsh
localhost:~> exec bash -l
localhost:~$ echo $SHELL
/bin/bash
localhost:~$ exec zsh -l -i
localhost:~> echo $SHELL
/bin/bash

If a feature, then I guess I'll drop something like this to my .zshenv:

# Erase any possible signs of an inferior shell invoking us
unset BASH BASH_VERSION
export SHELL="`whence zsh`"

Cheers!




      

Re: SHELL not always correct

[Peter Stephenson]

Daniel Qarras wrote:
> Dear List,
> 
> I'm wondering is this a bug or a feature:
> 
> localhost:~> echo $SHELL 
> /bin/zsh
> localhost:~> exec bash -l
> localhost:~$ echo $SHELL
> /bin/bash
> localhost:~$ exec zsh -l -i
> localhost:~> echo $SHELL
> /bin/bash

I very much doubt whether bash is altering SHELL internally; try
starting with -x to see if it's coming from an initialisation file.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: SHELL not always correct

[Phil Pennock]

On 2008-10-21 at 21:58 +0100, Peter Stephenson wrote:
> I very much doubt whether bash is altering SHELL internally; try
> starting with -x to see if it's coming from an initialisation file.

I don't want to read the bash source and end up with tainted knowledge
or whatever the term is, but this seems safe enough:

# cd /usr/ports/shells/bash
# make extract
# fgrep -r '"SHELL"' work
work/bash-3.2/variables.c:  temp_var = find_variable ("SHELL");
work/bash-3.2/variables.c:      temp_var = bind_variable ("SHELL", current_user.shell, 0);
work/bash-3.2/shell.c:      set_var_read_only ("SHELL");

Okay, I peeked at variables.c and this comment:
/* Set $SHELL to the user's login shell if it is not already set.  Call
   get_current_user_info if we haven't already fetched the shell. */
decorates set_shell_var() which forcibly claims SHELL for itself.

Seems rather presumptuous, to claim to child processes that you are the
user's chosen preferred shell, merely because you're running.

Single Unix Specification v3, XBD, Chapter 8:
----------------------------8< cut here >8------------------------------
SHELL
    This variable shall represent a pathname of the user's preferred
    command language interpreter. If this interpreter does not conform
    to the Shell Command Language in the Shell and Utilities volume of
    IEEE Std 1003.1-2001, Chapter 2, Shell Command Language, utilities
    may behave differently from those described in IEEE Std 1003.1-2001.
----------------------------8< cut here >8------------------------------

which is consistent with my understanding that programs setting up an
environment based on getpwnam() may set $SHELL (login, sshd, crontab) or
a user may set it themselves but it shouldn't be otherwise overriden
without good cause.  Good cause might be a build system which wants to
guarantee POSIX sh instead of csh might set SHELL for the environment of
the build to get a known-good setup.

(I'm sure Peter knows all that, I'm answering the OP).

-Phil

Re: SHELL not always correct

[Aaron Davies]

On Wed, Oct 22, 2008 at 7:13 AM, Phil Pennock
<zsh-workers+phil.pennock@spodhuis.org> wrote:

> Seems rather presumptuous, to claim to child processes that you are the
> user's chosen preferred shell, merely because you're running.

I've generally found that SHELL isn't much use for figuring out what you're in.

GNU autoconf <http://autoconf.iunix.biz/autoconf_105.html> checks
whether ZSH_VERSION is set to determine if it's running in zsh.
(Hopefully it's not exported in the standard setup. :-)
-- 
Aaron Davies
aaron.davies@gmail.com

Re: SHELL not always correct

[Richard Hartmann]

On Wed, Oct 22, 2008 at 02:35, Aaron Davies <aaron.davies@gmail.com> wrote:

> (Hopefully it's not exported in the standard setup. :-)

richih@roadwarrior ~ % echo $ZSH_VERSION
4.3.6
richih@roadwarrior ~ % bash
richih@roadwarrior:~$ echo $ZSH_VERSION

richih@roadwarrior:~$ echo $BASH_VERSION
3.2.39(1)-release
richih@roadwarrior:~$ zsh
richih@roadwarrior ~ % echo $BASH_VERSION

richih@roadwarrior ~ %


Richard

Re: SHELL not always correct

[Phil Pennock]

On 2008-10-22 at 08:35 +0800, Aaron Davies wrote:
> On Wed, Oct 22, 2008 at 7:13 AM, Phil Pennock
> <zsh-workers+phil.pennock@spodhuis.org> wrote:
> 
> > Seems rather presumptuous, to claim to child processes that you are the
> > user's chosen preferred shell, merely because you're running.
> 
> I've generally found that SHELL isn't much use for figuring out what you're in.

Never has been.  Used to be that $0 was a good check and if $0 was unset
then you're in csh.  Nowadays with /bin/sh being a symlink to some other
shell and sometimes needing to figure out what /bin/sh is that's more
interesting.

But anyone thinking $SHELL is the current shell is misunderstanding;
$SHELL is a statement of desired intent, not of current state.  It can
be set by something conveying desired intent (ie, it looked in system
databases such as /etc/passwd), by the user themselves or by someone
needing to override desired intent for a process sub-tree, but shouldn't
be being set by a shell for its children just because it's running.

This actually appears to be a bash bug, as it means that on systems
where /bin/sh is bash, programs using popen()/system()/etc will lose
information about the user's configuration and even if zsh is the shell
in /etc/passwd, programs run via such a path won't see it.  Unless bash
only calls this logic for interactive shells, that is.  Figuring that
out would involve reading enough of the bash source that someone might
object to the reader then contributing to a non-GPL shell such as zsh.
:-(

I don't believe I currently have access to any systems using bash as
/bin/sh to test the actual behaviour; they're all either using BSD sh or
dash or equivalent.  Or in a production environment where I really am
not going to run private tests.

-Phil

Re: SHELL not always correct

[Chet Ramey]

Phil Pennock wrote:

> I don't want to read the bash source and end up with tainted knowledge
> or whatever the term is, but this seems safe enough:
> 
> # cd /usr/ports/shells/bash
> # make extract
> # fgrep -r '"SHELL"' work
> work/bash-3.2/variables.c:  temp_var = find_variable ("SHELL");
> work/bash-3.2/variables.c:      temp_var = bind_variable ("SHELL", current_user.shell, 0);
> work/bash-3.2/shell.c:      set_var_read_only ("SHELL");
> 
> Okay, I peeked at variables.c and this comment:
> /* Set $SHELL to the user's login shell if it is not already set.  Call
>    get_current_user_info if we haven't already fetched the shell. */
> decorates set_shell_var() which forcibly claims SHELL for itself.
> 
> Seems rather presumptuous, to claim to child processes that you are the
> user's chosen preferred shell, merely because you're running.

Gee, it sure would be.  If only that were happening.  Since you
don't want to read the bash source to avoid contaminating yourself,
why are you speculating?

The comment is accurate:  the function sets SHELL to the user's login
shell if it's not already set.  Bash neither presumes it is the
preferred shell nor overrides a user's intent.  It does assume that
the login shell is the appropriate `preferred shell'.

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.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

Re: SHELL not always correct

[Stephane Chazelas]

On Tue, Oct 21, 2008 at 04:13:23PM -0700, Phil Pennock wrote:
[...]
> work/bash-3.2/variables.c:  temp_var = find_variable ("SHELL");
> work/bash-3.2/variables.c:      temp_var = bind_variable ("SHELL", current_user.shell, 0);
> work/bash-3.2/shell.c:      set_var_read_only ("SHELL");
> 
> Okay, I peeked at variables.c and this comment:
> /* Set $SHELL to the user's login shell if it is not already set.  Call
>    get_current_user_info if we haven't already fetched the shell. */
> decorates set_shell_var() which forcibly claims SHELL for itself.
> 
> Seems rather presumptuous, to claim to child processes that you are the
> user's chosen preferred shell, merely because you're running.
[...]

No, bash doesn't set $SHELL to bash, that would be a bug if it
did, it just sets $SHELL to the user's login shell if it's not
already set which is fine. Here, my login shell is zsh,

$ env -i bash -c 'echo $SHELL'
/bin/zsh

$ env SHELL=/bin/rc bash -c 'echo $SHELL'
/bin/rc

So bash acknowledges my choice, it just sets $SHELL in case it
wasn't set before.

Basically, it's doing the job of login(1). login(1) is the
command that generally initialises $SHELL (that is the user's
shell of choice) to the user's login shell (from the "passwd"
database).

-- 
Stéphane

Re: SHELL not always correct

[Stephane Chazelas]

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.

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
.profile/.bashrc?

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
shell

Looking around, I see AT&T ksh is the only other shell that sets
$SHELL. It sets it to "/bin/sh" though (even on Solaris where
/bin/sh is not a standard shell!) and it doesn't export it
either. ash, pdksh, posh, mksh, csh, tcsh, rc, es, zsh don't set
it.

-- 
Stéphane

Re: SHELL not always correct

[Daniel Qarras]

Hi!
 
> > localhost:~> echo $SHELL 
> > /bin/zsh
> > localhost:~> exec bash -l
> > localhost:~$ echo $SHELL
> > /bin/bash
> > localhost:~$ exec zsh -l -i
> > localhost:~> echo $SHELL
> > /bin/bash
> 
> I very much doubt whether bash is altering SHELL
> internally; try starting with -x to see if it's coming from an
> initialisation file.

Good guess, and even a correct one: on a system where I tried it a init script was actually setting SHELL.

Cheers!




      

Re: SHELL not always correct

[Chet Ramey]

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
> .profile/.bashrc?

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
> shell

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
> $SHELL.

OK.  Bash does what it does, though, and there's enough backwards
compatibility to leave the current behavior alone.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/