Linux – Which bash rc files are run on non-interactive/non-login shells

bashbash-scriptingbashrccronlinux

My Understanding

there are no rc files called for non-interactive/non-login shells; for example, those run by cron
(I don't know this for certain and would lean on the community's expertise)
non-interactive shells require the BASH_ENV environment variable to be set, which enables to set it to a particular rc file (e.g., BASH_ENV=$HOME/.bash_profile)

The Hope

I'm not certain about the plethora of rc files available, so am curious if there is ones that I'm not familiar with. Hoping to find an rc file that meets the following conditions:

called regardless of interaction/login mode so global shell environment variables can be set in one place
performs more like csh/tcsh

Best Answer

The answer to your specific question is that often only /etc/bash.bashrc (or /etc/bashrc) is loaded.

There seem to be a couple of ways to address this, most are workarounds unfortunately. In no particular order of preference:

Fake a login

Logins run /etc/profile and often you can place your custom scripts in /etc/profile.d/*.sh

Wrap it in a bash login

Sometimes it is easiest to trigger a login, i.e.

echo "do whatever $PATH $BASH $PS1 $0"

becomes

bash -lc 'echo "do whatever $PATH $BASH $PS1 $0"'

Manually load the profile

Do what logins do, manually load the profile

source /etc/profile;echo "do whatever $PATH $BASH $PS1 $0"

Edit global environment variables

For simple variables you can add to /etc/environment see Ubuntu System-wide_environment_variables but variable expansion does not work

THING_HOME="/opt/thing"
PATH="$PATH:/opt/thing" # this will NOT work

For PATH you could append to it e.g. sudo sed -i 's#PATH=\"[^\"]*#&:/opt/thing#' /etc/environment

Edit all bash shells

You can add to /etc/bash.bashrc (or /etc/bashrc) however this normally exits early if non-interactive so you need to hack your additions on before:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

Do none of these

Consider symlinks if you are trying to add something to the PATH
Consider making your programs/scripts modify their own environment
Systemd has EnvironmentFile and Environment e.g. systemctl edit --full cron.service

I am interested in hearing if anyone else has better workarounds!

Related Solutions

Linux – Where should I export an environment variable so that all combinations of bash/dash, interactive/non-interactive, login/non-login, will pick it up

Shell invocation is a bit of a complicated thing. The bash and dash man pages has INVOCATION sections about this.

In summary they says (there is more detail in the man page, you should read it):

When bash is                   | it reads
-------------------------------|----------
login shell                    | /etc/profile and then the first of ~/.bash_profile, ~/.bash_login or ~/.profile that exists.
                               |
interactive non-login shell    | /etc/bash.bashrc then ~/.bashrc
                               |
non-interactive shell          | The contents of $BASH_ENV (if it exists)
                               |
interactive (as "sh")          | The contents of $ENV (if it exists)

When dash is                   | it reads
-------------------------------|---------
login shell                    | /etc/profile then .profile
                               |
interactive shell              | The contents of ENV (it it exists, can be set in .profile as well as in initial environment)

I don't know about other shells offhand as I never use any of them. Your best bet might be to set a couple environment variables to point at the common location script and manually source that (when appropriate) in the couple of cases that doesn't cover.

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.