Re: SHELL not always correct

[Chet Ramey <chet.ramey@xxxxxxxxx>]

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@xxxxxxxx    http://cnswww.cns.cwru.edu/~chet/