Logging onto a Linux machine running Bash causes certain files to be read. They configure your shell environment. But which files are read, and when, can be confusing. Here’s what really happens.
The Different Types of Shell
The environment you get when you launch a shell is defined by settings held in configuration or profile files. These hold information that establishes such things as your text colors, your command prompt, aliases, and the path that is searched for executable files when you type the name of a program.
There are a number of different files—in different locations in the file system—where these settings are stored. But before we get into looking at which files are read when you launch a shell, we need to be clear about what type of shell you’re using.
A login shell is a shell that you log into. When you boot your computer and log in, underneath your graphical desktop environment there’s a login shell. If you connect to another computer over an SSH connection, you’ll log into a login shell too.
The type of shell you get when you open a terminal window is a non-login shell. You don’t need to authenticate to launch a shell when you’re already logged in. Login and non-login shells are interactive shells. You use them by typing instructions, hitting the “Enter” key, and reading the on-screen responses.
There are also non-interactive shells, too. These are the type of shells that get launched when a script is executed. The script is launched in a new shell. The shebang #!/bin/bash at the top of the script dictates which shell should be used.
#!/bin/bash echo -e "Hello, World!n"
This script will be run in a non-interactive Bash shell. Note that even though the shell is non-interactive, the script itself can be. This script prints to the terminal window, and could just as easily accept user input.
RELATED: 9 Bash Script Examples to Get You Started on Linux
Non-Interactive Shells
Non-interactive shells don’t read any profile files when they launch. They do inherit environment variables, but they won’t know anything about aliases, for example, whether they’re defined on the command line or in a configuration file.
You can test whether a shell is interactive or not by looking at the options that were passed to it as command line parameters. If there is an “i” in the options, the shell is interactive. The Bash special parameter $- contains the command line parameters for the current shell.
[[ $- == *i* ]] && echo 'Interactive' || echo 'Non-interactive'
Let’s create an alias called xc that will mean “cat.” We’ll also check that we have a $PATH variable set.
alias xc=cat
echo $PATH
We’ll try to access both of these from inside this small script. Copy this script into an editor and save it as “int.sh.”
#!/bin/bash xc ~/text.dat echo "Variable=$PATH"
We’ll need to use chmod to make the script executable.
chmod +x int.sh
Let’s run our script:
./int.sh
In its non-interactive shell, our script cannot use the alias, but it can use the environment variable. Interactive shells are more interesting in their use of profile and configuration files.
RELATED: How to Set Environment Variables in Bash on Linux
Interactive Login Shells
There are two types of interactive login shells. One is the shell that lets you log in to your computer. On desktops, this is commonly the shell underlying your desktop environment. Whether you use a windowed or tiling desktop environment, something has to authenticate you with the Linux system and permit you to log in.
On servers without a desktop environment installed, you log in directly into an interactive shell. You can do the same sort of thing on a desktop computer if you drop out of the desktop environment and access a terminal. On GNOME you can do this with the Ctrl+Alt+F3 key combination. To go back into your GNOME session press the Ctrl+Alt+F2 key combination. The shell you connect to over an SSH is a login shell too.
The profile and configuration files that are called can be set using environment variables, so they can vary from distribution to distribution. Furthermore, not all files are used by every distribution. In a generic Bash installation, interactive login shells read the “/etc/profile” file. This holds system-wide shell configuration options. If they exist, this file also reads files such as “/etc/bash.bashrc” and “/usr/share/bash-completion/bash_completion”.
Bash then looks for a “~/.bash_profile” file. If it doesn’t exist, Bash looks for a “~/.bash_login” file. If that file doesn’t exist, Bash tries to find a “.profile” file. Once one of these files is found and read, Bash stops searching. So in most cases, “~/.profile” is unlikely to be read at all.
Often, you’ll find something like this in your “~/.bash_profile” or, as a sort of backstop, in your “~/.profile” file:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
This checks that the active shell is Bash. If it is, it searches for a “~/.bashrc” file and reads it if one is found.
Interactive Non-Login Shells
A Bash interactive non-login shell reads “/etc/bash.bashrc” and then reads “~/.bashrc” file. This allows Bash to have system-wide and user-specific settings.
This behavior can be changed with compilation flags when Bash is compiled, but it would be a rare and peculiar circumstance to encounter a version of Bash that doesn’t source and read the “/etc/bash.bashrc” file.
Each time you open a terminal window on your desktop, these two files are used to configure the environment of that interactive, non-login shell. The same thing happens for shells launched by applications, such as the terminal window in the Geany IDE.
Where Should You Put Your Configuration Code?
The best place to put your personal customization code is in your “~/.bashrc” file. Your aliases and shell functions can be defined in “~/.bashrc”, and they’ll be read in and available to you in all the interactive shells.
If your distribution doesn’t read your “~/.bashrc” in login shells, and you’d like it to, add this code to your “~/.bash_profile” file.
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
Modularity Is Best
If you have a lot of aliases, or you want to use the same aliases across a number of machines, it is best to store them in their own file, and the same with your shell functions. You can call those files from your “~/.bashrc” file.
On our test computer, the aliases are stored in a file called “.bash_aliases” and a file called called “.bash_functions” holds the shell functions.
You can read them from within your “~/.bashrc” file like this:
# read in my aliases if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi # read in my shell functions if [ -f ~/.bash_functions ]; then . ~/.bash_functions fi
This lets you easily move your aliases and functions between computers easily. You just need to add the lines above to the “~/.bashrc” file on each computer and copy the files containing your aliases and shell functions to your home directory on each computer.
It means you don’t need to copy all of the definitions from the “~/.bashrc” on one computer to the “~/.bashrc” files on each of the other computers. It’s also better than copying your entire “~/.bashrc” file between computers, especially if they are running Bash on different distributions.
In Summary
The files you really need to know about are:
- /etc/profile: System-wide configuration settings. Used by login shells.
- ~/.bash_profile: Used to hold settings for individual users. Used by login shells.
- ~/.bashrc: Used to hold settings for individual users. Used by interactive non-login shells. Might also be called from your “~/.bash_profile” or “~/.profile” file for login shells.
One convenient method is to put your personal settings in “~/.bashrc”, and make sure your “~./bash_profile” file calls your “~/.bashrc” file. That means your personal settings are held in one single file. You’ll get a consistent shell environment across login and non-login shells. Combining this with storing your aliases and shell functions in non-system files is a neat and robust solution.
