Re: SHELL not always correct

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

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@xxxxxxxxxxxx> 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