1

I'm using macOS, and since it ships with Bash 3.2, I've upgraded to 4.4 via homebrew. I've configured my terminal to use the newer version by setting its startup command to:

/usr/local/bin/bash -l

I was recently playing around with the script command to record and playback terminal sessions, and found that it was using Bash 3.2

Setting export SHELL=/usr/local/bin/bash fixes this, but I'm wondering whether it's advisable to set it. I imagine it might be inadvisable not to set it, but I'm just not sure what else makes decisions based on the SHELL env var.

ivan
  • 1,858
  • 2
  • 19
  • 37
  • Have you tried setting the shell to `/usr/local/bin/bash` in `/etc/passwd`? – John1024 Aug 10 '17 at 22:25
  • 1
    Is `/usr/local/bin/bash` in your `/etc/shells`? If not run this: `sudo bash -c 'echo /usr/local/bin/bash >> /etc/shells'`. Also just for solidarity make sure you have followed the steps in this guide for your upgrade: http://clubmate.fi/upgrade-to-bash-4-in-mac-os-x/ – jesse_b Aug 10 '17 at 22:26
  • 2
    @Jesse_b Why would it matter that it's in `/etc/shells`? That file is only used by `chsh`, unless macOS does something unusual. – Gilles 'SO- stop being evil' Aug 10 '17 at 23:11
  • Where is `/usr/local/bin` compared to `/usr/bin` in your `PATH` ? – thrig Aug 10 '17 at 23:27
  • Where did you hear that @Gilles? As far as I know every *nix OS uses /etc/shells unless a few obscure ones do something unusual. – jesse_b Aug 10 '17 at 23:27
  • "The shells file contains a list of login shells on the system. Applications use this file to determine whether a shell is valid. For each shell a single line should be present, consisting of the shell's path, relative to the root of the directory structure (/)." – jesse_b Aug 10 '17 at 23:28
  • "The /etc/shells is a Linux / UNIX text file which contains the full pathnames of valid login shells. This file is used by various commands including chsh command. Please note that there are programs which consult this file to find out if a user is a normal user. For example, ftp daemons such as ftpd disallow access to users with shells not included in this file." – jesse_b Aug 10 '17 at 23:41
  • 1
    @Jesse_b Ok, that file is only used by `chsh` and a few other system services that are relatively uncommon these days. The point is, it's only used to check the user's current login shell. It has nothing to do with the `SHELL` environment variable. – Gilles 'SO- stop being evil' Aug 10 '17 at 23:45
  • We are talking semantics here but if you add a new shell to your *nix system you absolutely should add it to /etc/shells. Additionally in most linux/unix distros your `SHELL` variable is set by the `/etc/passwd` file, however in mac it is not. So in mac the correct way to set your default shell is with the `chsh` command we can't stop talking about anyway. – jesse_b Aug 10 '17 at 23:52
  • Also FYI: I believe you are not setting any environmental variables. When you do: `SHELL=/usr/local/bin/bash` You are setting a shell variable. In order to make it an environmental variable you would need to do: `export SHELL=/usr/local/bin/bash` – jesse_b Aug 11 '17 at 00:44
  • @Jesse_b Yep, I added the new bash to `/etc/shells` when I did the upgrade. I think I referenced that same page you linked ;) – ivan Aug 11 '17 at 16:53
  • @John1024 There's no line in `/etc/passwd` corresponding to my user, I'm guessing because I'm on macOS. From the other comments it sounds like that also relates to the use of `/etc/shells` when doing this on mac – ivan Aug 11 '17 at 16:57
  • @Jesse_b I accidentally omitted `export` in my original post. I'll update... – ivan Aug 11 '17 at 16:59

1 Answers1

2

The conventional meaning of the SHELL environment variable is the user's favorite interactive shell. There is no obligation that it has any particular syntax (it doesn't have to be Bourne-like), that it supports any particular command line syntax (such as -c), or that it has anything to do with the login shell (applications that use SHELL typically default to the login shell if SHELL is unsed). It's mostly used by terminal emulators as the program to run by default.

If you log in in text mode (on a text console or over SSH), what you get is the login shell listed in the user database (e.g. /etc/passwd). When you open a terminal in a GUI environment, you get the shell specified by the SHELL environment variable if the variable is set. If you want the same shell for text mode logins, either change your login shell with chsh, or make your login shell switch to your favorite shell with exec.

Occasionally you might encounter a program that uses $SHELL -c instead of sh -c to execute code in sh syntax. But that's pretty rare. It's technically allowed by POSIX, but it would violate historical usage. In practice, setting SHELL is safe. I've had my login shell set to /bin/sh and SHELL set to /path/to/zsh on most machines for about two decades.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • When you say: "you get the shell specified by the SHELL environment variable if the variable is set" How does that environment variable get set? (Pretty sure the passwd file is what sets it. -- not in mac though) – jesse_b Aug 11 '17 at 00:05
  • @Jesse_b It gets set because the user sets it, typically in `~/.profile`. A few programs (Screen, at least) set it (to the login shell) if it's unset. – Gilles 'SO- stop being evil' Aug 11 '17 at 00:14
  • I disagree with that. You do not need to set `SHELL` in any of your profile files and it will still always be set by the `/etc/passwd` file. – jesse_b Aug 11 '17 at 00:16
  • If you do a `useradd -D` you will see what `environment variables` the /etc/passwd file sets by default for each user. – jesse_b Aug 11 '17 at 00:22
  • Additionally with the GUI you can specify a default shell in the settings of whatever terminal app you are using but otherwise it will use whatever one you set with `chsh` I'm still not sure how mac chooses a default shell in the first place though. – jesse_b Aug 11 '17 at 00:27
  • 1
    @Jesse_b True, at least on Linux you get `SHELL` set to your login shell when you log in. That doesn't make much difference from having it unset. – Gilles 'SO- stop being evil' Aug 11 '17 at 00:29
  • I'm sure it makes no difference but I guess what I'm getting at is that if I wanted to muck with my `SHELL` variable I would change it in /etc/passwd rather than in my `.profile`. I kind of view setting it manually as a workaround and would like to know how it actually is set in mac but everything I'm finding says either to use the gui or `chsh` so maybe they don't want you messing with it that way. found it: `niutil -createprop . /users/joebob shell /usr/local/bin/bash` – jesse_b Aug 11 '17 at 00:38
  • @Jesse_b Your login shell and your favorite login shell don't have to be the same program. This is important for two kinds of people. For people who use a non-sh-compatible interactive shell, it's convenient to use `sh` or `bash` as a login shell because GUI logins often read `.profile` under `sh`. For people who use heterogeneous networks, `/bin/sh` is guaranteed to be available everywhere, whereas one's favorite interactive shell may not be installed everwhere (or even if it's installed it may be in a different location, e.g. `/usr/bin/zsh` vs `/usr/local/bin/zsh`). – Gilles 'SO- stop being evil' Aug 11 '17 at 00:51
  • Are you implying that many people use `/bin/sh` as their login shell? On most linux distros I'm pretty sure `/bin/sh` is just a symbolic link to `/bin/bash` anyway. I understand that some linux distros are starting to come with an actual bourne shell now but I digress. Thank you for the information about a favorite shell and login shell which I was not aware, however in this use case I believe he just wants to change both his shells to the newly installed bash v4~. I just think adding it as a user property is cleaner in that case. – jesse_b Aug 11 '17 at 00:56
  • 1
    @Jesse_b Debian and Ubuntu have dash as `/bin/sh`, but `/bin/bash` as the default login shell. No Linux system has ever come up with an actual Bourne shell. – Gilles 'SO- stop being evil' Aug 11 '17 at 00:59