Bash launch in detail

Original author: Ian Miell
  • 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.

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 --loginwhen called bash, for example:

bash --login

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 PS1(it sets the command input function):

if ["$ {PS1-}"]; then
  echo interactive
  echo non-interactive

Or see if the parameter is set -iusing 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/profileand 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:

~ / .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_ENVyour 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 PATHand aliasset up the way you expect.

This is why it is often necessary to install a PATHcron 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/profilerefers 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.


$ 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 crontabsimple script (c /root/ascript) will be executed every minute :

$ crontab -l
$ cat /var/log/script.log

Also popular now: