Run bash in detail

If you found this page in the search, you are surely trying to solve a problem with running bash.

Perhaps bash does not set the environment variable in your environment and you do not understand why. You may have stuck something in various bash boot files or profiles, or all files at random, until it worked.

In any case, the point of this note is to explain how to start bash as easily as possible so that you can deal with the problems.
')

Diagram

This flowchart summarizes all the processes running bash.



Now take a closer look at each part.

Login Shell?

First you need to choose whether you are in the login shell (login shell) or not.

The login shell is the first shell you get into when logging in for an interactive session. The login shell does not require entering a username and password. You can force the launch of the login shell by adding the --login flag when invoking bash , for example:

  bash --login 

The login shell sets up the base environment when the bash shell is first launched.

Interactive?

Then you determine whether the shell is interactive or not.

This can be checked by the presence of the variable PS1 (it sets the function to enter commands):

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

Or see if the -i option is set using a special dash variable in bash, for example:

  $ echo $ - 

If in the output there is a symbol i , then the shell is interactive.

In the login shell?

If you are in the login shell, bash looks for the file /etc/profile and starts it if it exists.

Then 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 been in 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 

Neither 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 below for cron tasks).

In this case, bash looks at the BASH_ENV variable of your environment and executes the corresponding file that is listed there.

Typical difficulties and rules of thumb

Cron jobs

In 95% of cases, I debug bash startup due to the fact that the cron job does not work as expected.

This damned task works fine when I run it on the command line, but it fails when I run it in crontab .

Here are two reasons :

• Cron jobs are not interactive.
  
• Unlike scripts on the command line, cron jobs do not inherit the shell environment.

Usually you do not notice or care that the shell script is not interactive, because the environment is inherited from the interactive shell. This means that all PATH and alias configured as you expect.

This is why it is often necessary to set a specific PATH for the cron task, like this:

  * * * * * PATH = $ {PATH}: / path / to / my / program / folder myprogram 

Scripts calling 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 correct a mistake and everything seemed to work. Unfortunately, when you need to separate these different types of sessions, new problems arise.

Docker image in the sandbox

To experiment with running the shell, I created a Docker image that you can use to debug the shell launch in a safe environment.

Run:

 $ docker run -n bs -d imiell/bash_startup $ docker exec -ti bs bash 

Dockerfile is here .

To force login and login shell simulation:

 $ bash --login 

To check the BASH_ENV variable BASH_ENV :

 $ env | grep BASH_ENV 

To debug a crontab simple script (in /root/ascript ) will be executed every minute:

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