[ad_1]
Logging into a Linux machine running Bash causes certain files to be read. They set up your shell environment. But which files are read and when can be confusing. This is what really happens.
The different types of shell
The environment you get when you start a shell is defined by the settings that are kept in the configuration or profile files These contain information that sets things like text colors, command prompt, aliases, and the path that executable files are searched for when you type a program’s name.
There are a number of different files, in different locations on the file system, where these settings are stored. But before looking at what files are read when you start a shell, we need to be clear about what kind of shell you are using.
A login shell is a shell that you log into. When you start your computer and log in, below your graphical desktop environment is a login shell. If you connect to another computer via an SSH connection, you will also be logged into a login shell.
The type of shell you get when you open a terminal window is a non-login shell. You do not need to authenticate to start a shell when you are already logged in. The login and non-login shells are interactive shells. You use them by typing instructions, pressing the “Enter” key, and reading responses on the screen.
There are also non-interactive shells. These are the type of shells that are started when a script is executed. The script starts in a new shell. the case #!/bin/bash at the top of the script dictates which shell to use.
#!/bin/bash echo -e "Hello, World!n"
This script will run in a non-interactive Bash shell. Note that although the shell is not interactive, the script itself can be. This script prints to the terminal window and could easily accept user input.
RELATED: 9 Examples of Bash Scripts to Get You Started on Linux
non-interactive shells
Non-interactive shells do not read any profile files when they start. They inherit environment variables, but they won’t know anything about aliases, for example if they are defined on the command line or in a configuration file.
You can test whether or not a shell is interactive by looking at the options passed to it as command line parameters. If there is an “i” in the options, the shell is interactive. Bash’s 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 will also check that we have a $PATH variable set
alias xc=cat
echo $PATH
We’ll try to access both from within this little script. Copy this script into an editor and save it as “int.sh”.
#!/bin/bash xc ~/text.dat echo "Variable=$PATH"
we will have to use chmod to make the script executable.
chmod +x int.sh
Let’s run our script:
./int.sh
In your non-interactive shell, our script can’t use the alias, but 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 allows you to log in to your computer. On desktops, this is typically the shell that underlies your desktop environment. Whether you’re using a windowed or tiled desktop environment, something has to authenticate you with the Linux system and allow you to log in.
On servers without a desktop environment installed, log in directly to an interactive shell. You can do the same thing on a desktop computer by leaving the desktop environment and accessing a terminal. In GNOME you can do this with the key combination Ctrl + Alt + F3. To return to your GNOME session, press the key combination Ctrl + Alt + F2. The shell you connect to via SSH is also a login shell.
The profile and configuration files that are called can be configured using environment variables, so they may vary from distribution to distribution. Also, not all distributions use all files. In a generic Bash installation, interactive login shells read the “/etc/profile” file. This contains shell configuration options for the entire system. If they exist, this file also reads files like “/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 it is unlikely to read “~/.profile”.
Often you’ll find something like this in your “~/.bash_profile” file or, as a sort of fallback, 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 so, it looks for a “~/.bashrc” file and reads it if it finds one.
Interactive shells without login
An interactive shell without a Bash login reads “/etc/bash.bashrc” and then reads the file “~/.bashrc”. This allows Bash to have system-wide and user-specific settings.
This behavior can be changed with compiler flags when Bash is compiled, but it would be a rare and peculiar circumstance to find a version of Bash that doesn’t get or read the “/etc/bash.bashrc” file.
Every time you open a terminal window on your desktop, these two files are used to set up the environment for that interactive non-login shell. The same is true 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 shell aliases and functions can be defined in “~/.bashrc”, and will be read and made available to you in all interactive shells.
If your distribution doesn’t read your “~/.bashrc” in login shells, and you want 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 the best
If you have a lot of aliases, or want to use the same aliases on multiple machines, it’s 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, aliases are stored in a file called “.bash_aliases” and a file called “.bash_functions” contains the shell functions.
You can read them from 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 allows you to easily move your aliases and roles between computers easily. You just need to add the above lines 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 definitions from “~/.bashrc” on one computer to “~/.bashrc” files on each of the other computers. It’s also better than copying the entire “~/.bashrc” file between computers, especially if they run 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 save settings for individual users. Used by login shells.
- ~/.bashrc: Used to save settings for individual users. Used by interactive shells without login. It can also be called from your “~/.bash_profile” or “~/.profile” file for login shells.
A 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 saved in a 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.
[ad_2]
