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
chsh command like this:
chsh -s /bin/bash
Make sure that the shell you want to switch are set in
you will fail.
bash_profile do not take effect after login
Another issue is that when I sshed to the server, I found that only settings
.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
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
# 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 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:
|login||when you log into a server normally|
|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
echo $- shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'
The output of remote server will be:
hBs Login shell
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
~/.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
if [[ -f "$HOME/.bashrc" ]]; then source $HOME/.bashrc fi
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
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
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.
- This post has good graph on what is sourced during bash startup.
- Bashrc isn’t always run when I log in.
- Change shell in Ubuntu.
- How to get non-interactive login shell.
- How to check if a shell’s type: login or interactive.
- Difference between login, non-login, interactive and non-interactive shells.
- Zsh doc on login and interactive shells.
- Difference between bashrc and bash_profile.
License CC BY-NC-ND 4.0