Re: /bin/sh should set SHELL to /bin/sh

[Dan Douglas]

On 07/14/2017 03:13 PM, Greg Wooledge wrote:
> 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"'
> /bin/bash
> wooledg:~$ ksh -c 'echo "$SHELL"'
> /bin/sh
> 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).



signature.asc
Description: OpenPGP digital signature

Re: /bin/sh should set SHELL to /bin/sh

[Greg Wooledge]

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"'
/bin/bash
wooledg:~$ ksh -c 'echo "$SHELL"'
/bin/sh
wooledg:~$ zsh -c 'echo "$SHELL"'

wooledg:~$ tcsh -c 'echo "$SHELL"'
SHELL: Undefined variable.

Looks like there's not much agreement here.

Re: /bin/sh should set SHELL to /bin/sh

[Robert Elz]

Date:Thu, 13 Jul 2017 23:02:49 -0400
From:Chet Ramey 
Message-ID:  <102d254a-d321-20c0-b8d6-9f2257861...@case.edu>

  | Posix, the closest thing we have to a standard description of SHELL, says:

It does, but POSIX doesn't say the shell is intended to set it.
That is, it defines its purpose, but leaves unstated where it comes from.

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.

kre

Re: /bin/sh should set SHELL to /bin/sh

[Chet Ramey]

On 7/13/17 6:05 PM, John Reiser wrote:

> Bash Version: 4.3
> Patch Level: 43
> Release Status: release
> 
> Description:
> 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
language interpreter."

The best approximation of that is the user's login shell.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

/bin/sh should set SHELL to /bin/sh

[John Reiser]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE -DRECYCLES_PIDS 
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin'  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic

uname output: Linux f25e64.local 4.11.7-200.fc25.x86_64 #1 SMP Mon Jun 26 
15:58:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 4.3
Patch Level: 43
Release Status: release

Description:
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
as /bin/sh."

Repeat-By:
# 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'
/bin/bash

# Be pedantic: verify the comments above
$ strace -e trace=execve -v -s 100 env --unset=SHELL /bin/sh -c 'echo 
$SHELL'
execve("/usr/bin/env", ["env", "--unset=SHELL", "/bin/sh", "-c", "echo $SHELL"], 
[..., "SHELL=/bin/bash", ...]
execve("/bin/sh", ["/bin/sh", "-c", "echo $SHELL"], [..., /* no SHELL= 
*/, ...]

Fix:
Special case the setting of SHELL when the current shell
was invoked as /bin/sh.

--