When invoked as /bin/sh with SHELL unset, then bash should set SHELL
to /bin/sh, not to the login shell for the current user.
The current behavior can lead to surprises when descendants of /bin/sh
invoke $SHELL. There is even a reasonable argument that /bin/sh
_always_ should set SHELL=/bin/sh, even (and especially) overriding
an existing SHELL=/bin/bash. This would agree with the manual page:
"SHELL: The full pathname to the shell is kept in this environment variable."
If it's not going to change, then please emphasize the current behavior
on the manual page: "SHELL: ... If it is not set when the shell starts,
bash assigns to it the full pathname of the current user's login shell,
even if the result is SHELL=/bin/bash but the current shell was invoked
# Verify that /bin/sh is a link to bash.
$ ls -l /bin/sh
lrwxrwxrwx. 1 root root 4 Sep 30 2016 /bin/sh -> bash
# Remove SHELL from the environment, invoke /bin/sh,
# ask for the new value of SHELL.
# Note the single quotes to prevent expansion before invoking /bin/sh.
$ env --unset=SHELL /bin/sh -c 'echo $SHELL'
> Bash Version: 4.3
> Patch Level: 43
> Release Status: release
> When invoked as /bin/sh with SHELL unset, then bash should set SHELL
> to /bin/sh, not to the login shell for the current user.
Posix, the closest thing we have to a standard description of SHELL, says:
"This variable shall represent a pathname of the user's preferred command
The best approximation of that is the user's login shell.
On Sat, Jul 15, 2017 at 02:59:41AM +0700, Robert Elz wrote:
> IMO, if SHELL gets unset (it is usually initialised by login, or its
> equivalent), it should simply stay unset, and not be set to anything,
> until some user (or script) decides to set it again.
> On Sat, Jul 15, 2017 at 02:59:41AM +0700, Robert Elz wrote:
>> IMO, if SHELL gets unset (it is usually initialised by login, or its
>> equivalent), it should simply stay unset, and not be set to anything,
>> until some user (or script) decides to set it again.
> wooledg:~$ unset SHELL
> wooledg:~$ bash -c 'echo "$SHELL"'
> wooledg:~$ ksh -c 'echo "$SHELL"'
> wooledg:~$ zsh -c 'echo "$SHELL"'
> wooledg:~$ tcsh -c 'echo "$SHELL"'
> SHELL: Undefined variable.
> Looks like there's not much agreement here.
Good thing is bash doesn't export SHELL if it wasn't already exported,
and most shells seem to preserve the value of SHELL exported by some
parent. I see mksh sets -x if SHELL was previously unset... I suppose
that might cause a problem in some scenario (but probably not).