On 6 July 2017 at 07:53, der.hans <deb-u...@lufthans.com> wrote: > > "$SHELL" is a builtin variable that tells you what shell you're currently > running.
No, that's "not accurate", as indeed you wrote later. Shells do not set this variable to identify themselves. This can be easily tested by starting any shell interactively and inspecting $SHELL. For example, in a terminal start a 'dash' shell and then run 'echo $SHELL' inside it. For more enlightenment, start a 'dash' shell with 'SHELL=foo dash' and run 'echo $SHELL' inside it. Below I refer to man pages (on jessie). I have not read any relevant source code, nor do I know if systemd does anything different, someone else is welcome to comment on that. On jessie, 'man 1 login', states that it sets SHELL. I understand this to mean that 'login' exports SHELL as an environment variable to child processes of 'login'. I believe 'login' sets SHELL to the value of the user's login shell, as read from /etc/passwd. Once. And after that it does not change. And 'man bash' states that 'bash' sets SHELL only if it was previously not set, and that in that situation it sets SHELL to the value of the user's login shell. And 'man dash' doesn't mention SHELL, so I presume it does not touch it at all. > When using subshells ( including a shell script ) I find it to > not be accurate. Could well be that I just don't consistently quote it > properly. It is accurate, just not in the way you imagined. Quoting isn't the reason :) It is simply that the "shell you're currently running" can easily be different to the login shell, which is what $SHELL is expected to contain.