[einpoklum]

> For beginners it's a nightmare

I've taught undergraduate students some basic shell use for being able to compile their C programs. It's not really that bad. You have them use bash and you teach them some basic syntax and a few shell-usable programs, including man. You tell them that there is a lot of things the shell can do that we won't be discussing, so they have to be careful not use arbitrary symbols and to double-quote names. And I also tell them that bash is just one kind of shell, and that some systems have other shells by default, but we are working on a system which defaults to bash. I then tell them to check with "echo $SHELL" if they're on another system than the one we are working on, and if they don't see "/bin/bash" or "/usr/bin/bash" then they should ask someone for help.

That's enough to satisfy newbies in my experience.

[SAI_Peregrinus]

> I then tell them to check with "echo $SHELL" if they're on another system than the one we are working on, and if they don't see "/bin/bash" or "/usr/bin/bash" then they should ask someone for help.

Some systems will be weird. EG my default shell is bash, but my interactive shell for all my terminal emulators is fish. So "echo $SHELL" returns "/bin/bash", even from fish.

Of course I know this, I set it up this way deliberately so that only actual interactive shells (or correctly shebanged scripts) would be fish and everything else could be bash. But it would definitely confuse a beginner!

[einpoklum]

Hmm... interesting. But - echo $SHELL should tell you what the current shell is, not what the default shell is.

[arexxbifs]

$SHELL should typically be set to reflect the configured login shell, I.E. the shell specified in /etc/passwd. Or, as POSIX[0] puts it: "This variable shall represent a pathname of the user's preferred command language interpreter." The currently running shell is not necessarily the "preferred" shell, for example if you're doing "xterm -e zsh" or running a specific ksh script when you normally prefer (log in to) bash.

Being vaguely defined, it is of course open to interpretation and might vary from system to system, thus being a prime example of the kind of frustrating Unix gotchas that spawned the original article.

[0] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

Edit: To tie in to my earlier comment - where should I look for info on this variable in Linux? I know it exists, but how do I find out more about the behavior? 'apropos "\$SHELL"' gives me nothing. 'apropos SHELL' gives me a list of commands which doesn't include much of interest. Digging deeper, there's login(1), which briefly touches the subject, and environ(7), which gives a good description of it but of course dives in head-first and starts off by describing an array of pointers. Not overly helpful for the novice.

[JdeBP]

No, It tells you what program image file is going to be used when a program "shells out" or spawns a shell to run a shell command (e.g. via the ! command in mail or the :shell command in nvi).

It is a way for applications to know where the shell to invoke is, not a way for a user to find out what program xe is using to run commands. echo $0 is more informative on that score.