Bash launch in detail
- Transfer
- Tutorial
If you found this page in a search, then you are probably trying to solve some problem with running bash.
It is possible that your environment bash does not set an environment variable and you do not understand why. You may have stuffed something into various bash boot files or into profiles, or into all files at random until it worked.
In any case, the point of this note is to outline the bash startup procedure as easy as possible so that you can deal with problems.
This flowchart summarizes all the processes when running bash.
Now let's take a closer look at each part.
First you need to choose whether you are in the login shell or not.
The login shell is the first shell you enter when you log in for an interactive session. The login shell does not require a username and password. You can force the launch of the login shell by adding a flag
The login shell configures the base environment when you run the bash shell for the first time.
Then you determine if the shell is interactive or not.
This can be checked by the presence of a variable
Or see if the parameter is set
If there is a symbol in the output
If you are in the login shell, then bash searches for the file
Then it searches for any of these three files in the following order:
When it finds one, it launches it and skips the others.
If you are in an interactive shell without a login (non-login shell), it is assumed that you have already visited the login shell, the environment is configured and will be inherited.
In this case, the following two files are executed in order, if they exist:
If you are neither in the login shell nor in the interactive shell, then your environment will really be empty. This causes a lot of confusion (see cron jobs below).
In this case, bash looks at
In 95% of cases, I have debugging the launch of bash due to the fact that the cron job does not work as expected.
This damn task works fine when I run it on the command line, but fails at startup in crontab .
There are two reasons :
You usually don’t notice or care that the shell script is not interactive because the environment inherits from the interactive shell. This means that all
This is why it is often necessary to install a
Another common problem is when scripts are mistakenly configured to call each other. For example,
Usually this happens when someone tried to fix some kind of error and everything seemed to work. Unfortunately, when you need to separate these different types of sessions, new problems arise.
To experiment with shell startup, I created a Docker image that you can use to debug shell startup in a safe environment.
Launch:
Dockerfile is here .
To force login and simulate login shell:
To check a set of variables
For debugging, a
It is possible that your environment bash does not set an environment variable and you do not understand why. You may have stuffed something into various bash boot files or into profiles, or into all files at random until it worked.
In any case, the point of this note is to outline the bash startup procedure as easy as possible so that you can deal with problems.
Diagram
This flowchart summarizes all the processes when running bash.
Now let's take a closer look at each part.
Login Shell?
First you need to choose whether you are in the login shell or not.
The login shell is the first shell you enter when you log in for an interactive session. The login shell does not require a username and password. You can force the launch of the login shell by adding a flag
--login
when called bash
, for example:bash --login
The login shell configures the base environment when you run the bash shell for the first time.
Interactive?
Then you determine if the shell is interactive or not.
This can be checked by the presence of a variable
PS1
(it sets the command input function):if ["$ {PS1-}"]; then echo interactive else echo non-interactive fi
Or see if the parameter is set
-i
using a special hyphen variable -
in bash, for example:$ echo $ -
If there is a symbol in the output
i
, then the shell is interactive.In the login shell?
If you are in the login shell, then bash searches for the file
/etc/profile
and launches if it exists. Then it searches for any of these three files in the following order:
~ / .bash_profile ~ / .bash_login ~ / .profile
When it finds one, it launches it and skips the others.
In an interactive shell?
If you are in an interactive shell without a login (non-login shell), it is assumed that you have already visited the login shell, the environment is configured and will be inherited.
In this case, the following two files are executed in order, if they exist:
/etc/bash.bashrc ~ / .bashrc
Not a single option?
If you are neither in the login shell nor in the interactive shell, then your environment will really be empty. This causes a lot of confusion (see cron jobs below).
In this case, bash looks at
BASH_ENV
your environment variable and executes the corresponding file that is listed there.Typical difficulties and rules of thumb
Cron jobs
In 95% of cases, I have debugging the launch of bash due to the fact that the cron job does not work as expected.
This damn task works fine when I run it on the command line, but fails at startup in crontab .
There are two reasons :
- Cron jobs are not interactive.
- Unlike command line scripts, cron jobs do not inherit the shell environment.
You usually don’t notice or care that the shell script is not interactive because the environment inherits from the interactive shell. This means that all
PATH
and alias
set up the way you expect. This is why it is often necessary to install a
PATH
cron specific to a task, as here:* * * * * PATH = $ {PATH}: / path / to / my / program / folder myprogram
Scripts that call each other
Another common problem is when scripts are mistakenly configured to call each other. For example,
/etc/profile
refers to ~/.bashrc
. Usually this happens when someone tried to fix some kind of error and everything seemed to work. Unfortunately, when you need to separate these different types of sessions, new problems arise.
Sandbox Docker Image
To experiment with shell startup, I created a Docker image that you can use to debug shell startup in a safe environment.
Launch:
$ docker run -n bs -d imiell/bash_startup
$ docker exec -ti bs bash
Dockerfile is here .
To force login and simulate login shell:
$ bash --login
To check a set of variables
BASH_ENV
:$ env | grep BASH_ENV
For debugging, a
crontab
simple script (c /root/ascript
) will be executed every minute :$ crontab -l
$ cat /var/log/script.log