In this post, I would like to share causes and solutions to a few issues related to login shell.
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:
Make sure that the shell you want to switch are set in /etc/shells. Otherwise
you will fail.
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.
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 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: himBHsAccording to the above statements, we now have four different types of a 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.:
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:
.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.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.
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。