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

How to change default shell to Bash
#

When I logged into a new server, 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.

Settings in `bashrc` or `bash_profile` do not take effect 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 first need to understand the basic concept of a login shell and an interactive shell.

Login and interactive shell
#

login 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 shell¹. 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'

Interactive shell
#

Roughly speaking, an interactive shell is a shell that the user can interact with via the terminal, i.e., typing a command, sending it to the shell and getting output. If you run a script test.sh inside the shell by using bash test.sh, what actually happens is that a non-interactive bash shell is started to execute the commands 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

Different types of shell
#

According to the above statements, we now have four different types of a 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

Why isn’t `.bashrc` 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 that exists and is readable is sourced. So ~/.bashrc is not 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

Why isn’t `.bash_profile` sourced?
#

Another strange case I met with a new 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 logged in to the destination server with the same user name. Then each user will have to switch to his/her own account via su command: su REAL_USERNAME.

That is cause of the problem. The shell started by mere su REAL_USERNAME is an interactive non-login shell. The bash manual also says that:

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 $HOME/.bashrc is sourced. The solution to this issue is simple: invoke su command with - or -l option to tell Bash that we want a login shell instead of a non-login shell.

What gets sourced when we run a non-interactive non-login shell?
#

The Bash manual says that for a non-interactive shell, it has the following behavior:

When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV
in  the  environment, expands its value if it appears there, and uses the expanded value as the name of a file
to read and execute.  Bash behaves as if the following command were executed:
       if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the filename.

So only the file represented by BASH_ENV is sourced when a non-interactive shell is started.