Re: SHELL not always correct

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

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