In this post, I would like to share causes and solutions to a few issues related to login shell.

Default shell is not bash

When I logged in, I found that somehow my default shell (echo $SHELL) is /bin/sh instead of /bin/bash. We can change the default shell with chsh command like this:

chsh -s /bin/bash

Make sure that the shell you want to switch are set in /etc/shells. Otherwise you will fail.

bashrc or bash_profile not sourced after login

Another issue is that when I sshed to the server, I found that only settings inside .bash_profile is sourced. Settings inside .bashrc didn’t take effect. Before we delve into this problem, we need first to understand the basic concept of login shell and interactive shell.

Login and interactive shell

A login shell is usually the shell when the user first log in to the system. If the user start another shell or use bash inside the current shell, then the user will probably start a non-login shell1. To check whether the bash shell is a login shell, use the following command:

# only works for bash
shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'

Roughly speaking, an interactive shell is a shell that the user can interact with via the terminal, i.e., typing some command, sending it to the shell and getting output. If you run a script test.sh inside the shell instead by using bash test.sh. In fact, a non-interactive bash shell is started to execute the command inside test.sh. Now, you get a sense of what interactive means. To check if a bash shell is interactive, you can see if i is present in the variable $-:

echo $-
# output may be: himBHs

According to the above statements, we now have four different types of shell:

  • interactive login shell
  • interactive non-login shell
  • non-interactive login shell
  • non-interactive non-login shell

In the following table, I show how you can get these shells:

interactive non-interactive
login when you log into a server normally ssh xxx@ip < test.sh
non-login start a new bash shell inside the login shell when you execute script inside the login shell

Non-interactive login shell is extremely rare. You can start one when you run a local script via ssh on remote.:

ssh xxx@ip < test.sh

To verify that we have started a non-interactive login shell, put the following the command inside test.sh:

echo $-
shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'

The output of remote server will be:

hBs
Login shell

.bashrc not sourced

After looking up the bash manual, the section on startup file explains this behaviour:

When Bash is invoked as an interactive login shell, or as a non-interactive shell with the –login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The –noprofile option may be used when the shell is started to inhibit this behavior.

According to the above description, when you log into the server (bash is interactive login shell), bash will first source /etc/profile, then it will source ~/.bash_profile, ~/.bash_login and ~/.profile in the order given. The first one which exists and is readable is sourced. So ~/.bashrc is sourced during the login process.

If you need to source .bashrc during login process, you can add the following setting to .bash_profile:

if [ -f "$HOME/.bashrc" ]; then
    source $HOME/.bashrc
fi

.bash_profile not sourced

Another case I met with another server is that ~/.bash_profile is not executed during login. A little background here: for this destination server, I need to log into a jump server, and choose the destination server. All users are initially log in with the same user name. Then each user will have to switch to his/her own account via su command: su USERNAME.

That is problem here. The shell started by mere su USERNAME is an interactive non-login shell. In this case, according to the bash manual:

When an interactive shell that is not a login shell is started, Bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the –norc option. The –rcfile file option will force Bash to read and execute commands from file instead of ~/.bashrc.

It means that only settings inside ~/.bashrc is sourced. The solution to this issue is simple: invoke su command with - or -l option to specify that we want a login shell.

References


  1. That is not always true. For example, for macOS, new terminal started by Terminal.app is actually a login shell.