Bash shell: how to reconcile portable configuration files and GUI terminal start-up types (login or interactive)

bashbashrcguishellterminal

In an attempt to "properly" implement a standard configuration of my preferred shell, bash, for use across multiple platforms, I've come across some confusion when dealing with terminals that are inconsistent with their choice of shell start-up types (login or interactive).

Bash Start-Up Files

From the bash manual, I've determined the difference between the start-up files and order/cases in which they are sourced (/etc/profile, ~/.bash_profile, ~/.bash_login, and ~/.profile for login shells, and ~/.bashrc for interactive non-login shells). The documentation suggested that you store your bash-specfic login configuration in ~/.bash_profile and your bash-specific interactive ones in your ~/.bashrc. The manual itself even suggested adding if [ -f ~/.bashrc ]; then source ~/.bashrc; fi to the ~/.bash_profile file so login shells inherit your interactive shell settings.

From what I've read in the manual and in various online forums/docs, it also seemed prudent to abstract your non-bash specific login configuration to ~/.profile since other shells can source this file. This may be an edge-case for people who may use Bourne shell in addition to bash (which is not really likely in my case), but it seems like a good habit to form.

So far this all seems pretty straight forward and logical, especially in an environment where the distinction between the various shell start-up types are apparent: on systems or terminals where the command-line is the primary interface, login shells are your primary session shells, interactive shells are subsequent shells launched in that session, and your non-interactive shells are script-running shells.

The real confusion is what constitutes a login shell when your shell is started from a terminal within a GUI environment where you are already authenticated to the system? It seems to me that the default behavior in Mac OSX Terminal.app is for the shell running in each window to start a login shell, whereas in xterm, each new window is an interactive shell.

It is possible that I am seeing a problem where one does not exist, however consider the following: the terminal situation suggests that I put the vast majority of my configuration in ~/.bashrc to avoid losing functionality should I be working on a terminal that starts bash as an interactive shell. Being unfamiliar with the intricacies of when bash might be spawned as interactive shells, I have to rely on this statement that abusing ~/.bashrc like this will eventually cause problems where login shell configuration being misplaced is detrimental to normal shell functioning. It isn't hard to imagine that problems might arise when you ignore the manual's advice and use configuration files inappropriately.

Since you can't really rely on using ~/.bashrc as your catch-all, it seems like you might need to treat your ~/.bash_profile and ~/.bashrc files differently depending on the terminal you are using. This seems like it would result in a lot of headaches and is counter to the purpose of having these distinct start-up files in the first place!

So finally my questions are as follows:

How do current Bash shell users address the issue of GUI terminal inconsistencies between starting login and interactive shells?
How do you create a single-set of bash start-up files for cross-platform (and cross-terminal) use, without running into problems?

Thank you for your assistance and advice.

Best Answer

The most common problem caused by misuse of shell startup files is that if you define environment variables in .bashrc as opposed to .profile, they are not defined in applications that are not launched from a shell in a terminal but rather from a GUI menu.

Defining environment variables from .bashrc is generally not a good idea, but that's primarily because it's generally useless as the variables should already have been set at login time. It can cause a problem in practice if you (or an application) have deliberately changed the value of a variable (e.g. PATH) in a program and you launch a shell from that program and expect the setting to have remained the same.

You can avoid the problem of environment variables being reset by defining a “sentinel” value, and not defining anything if the sentinel value is set:

if [ -z "$JMLANE_PROFILE_READ" ]; then
  export ...
  export JMLANE_PROFILE_READ=1
fi

Another problem caused by terminals starting login shells is that there are things that should only be done once when you log in, for example starting a password agent (e.g. ssh-agent), or initiating a session (e.g. running startx in certain circumstances). The sentinel variable avoids these issues.

A shell inside a terminal is always interactive. As long as you source .bashrc from .bash_profile when the shell is interactive, you don't need to worry about the terminal starting a login shell.

An additional wart of bash's startup file handling is that .bashrc is read by non-interactive shells invoked by rshd or sshd. For example, when you do rsync somefile host.example.com:, if your login shell on host.example.com is bash, you can use .bashrc there to set the path to include rsync. You can tell you're in this situation because .bashrc is read from a non-interactive shell.

## .bashrc
if [[ $- != *i* ]]; then
  # either .bashrc was executed explicitly or this is a noninteractive rsh/ssh session
fi

Related Solutions

GVim does not source .bashrc, .bash_profile, or .profile from non-interactive non-login shell

What you describe is normal behavior. Starting bash with the -c option will launch an non-interactive, non-login shell. This means that bash will not source any of its classic configuration files but the variable $BASH_ENV instead. As explained in the bash man page:

non-interactive, non-login shell:
When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following command were executed:
```
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
```
interactive, login shell:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
interactive, non-login shell

When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc.

So, if you want your non-interactive, non-login shell to source ~/.bahsrc, you will need to set the value of BASH_ENV to ~/.bashrc. Add this line to your ~/.bashrc or ~/.profile files:

export BASH_ENV=~/.bashrc

Linux – Why do we have login, non-login, interactive, and non-interactive bash shells

These are my thoughts on the different "types"of shells -- unfortunately I didn't witnessed the rise of the Un*x right from the beginning (I assume this concept is grown historically to a good extend), so please be critical.

When I log into a system (nowadays via the graphical X login), there might be some tasks which should run once, e.g. establish a connection to some kind of server, present me a the today's todo list, autostart some commands, etc. This shouldn't happed every time I open up a new terminal. So there's a set of config files (/etc/profile, ~/.bash_login and so on, refer to the manual for an accurate list) sourced only by login shells.
Accordingly, to close the connections, kill some programs, run a backup script there is ~/.bash_logout when the login shell exists.
so, the "normal" shell I use in a terminal, shouldn't ba a login shell, but nevertheless should read my personal preferences from ~/.bashrc, because I want my keybindings to interact with the shell -- hence this is an interactive, non-login shell.
and last, but not least when bash is used for scripting, neither of this is important. bash should start as fast as it can, i.e. shouldn't read any config files. This is a non-interactive, non-login shell.

So, my answer to your question What would we lose if we only had one type of shell? is in one word: "Flexibility."

The answer to your second question is easy:

$- lists the current set of options. These can either be set by command line parameters to bash or via the set builtin. So you have to look at two places in the manual:

OPTIONS section:

-i        If the -i option is present, the shell is interactive.

SHELL BUILTIN COMMANDS section, subsection set:

-h      Remember the location of commands as they are looked up for execution.  This is enabled by default.
-m      Monitor  mode.  Job control is enabled.  This option is on by default for interactive shells on systems that sup‐
        port it (see JOB CONTROL above).  Background processes run in a separate process  group  and  a  line  containing
        their exit status is printed upon their completion.
-B      The shell performs brace expansion (see Brace Expansion above).  This is on by default.
-H      Enable !  style history substitution.  This option is on by default when the shell is interactive.

Bash Start-Up Files

Best Answer

Related Solutions

GVim does not source .bashrc, .bash_profile, or .profile from non-interactive non-login shell

Linux – Why do we have login, non-login, interactive, and non-interactive bash shells

Related Question