Questions about startup script order

[bodisha]

I'm trying to understand the order startup scripts run for interactive vs non-interactive modes. I've put simple echo commands in everything but the /etc/environment & BASH_ENV aren't working how I expected they would (I understand they aren't technically startup scripts)

The way I understand the /etc/environment file is it sets global variables and is read by PAM... Because of this I'm expecting the variables set here to appear for all users... But it only seems to be running for root in a non-interactive terminal

And I can't figure out how to get the $BASH_ENV to work at all... My understanding of it is you point it to a file with variables and it reads them in

Code: Select all

BASH_ENV=/etc/bash_env.txt

and it's suppose to import everything it finds. I've set this in my /etc/profile... But when I echo it's contents I just get the file location and name instead of it's contents.

Could someone set me straight about them? I would greatly appreciate it!

[aks]

/etc/environment is usually read by pam_env.so and AFAIK pam_env doesn't support expanding variables (so $VAR is $VAR literal not the conents of $VAR). Also that's only read, if the pam_env is in your PAM stack and is used by whatever is doing your login.

Because of this I'm expecting the variables set here to appear for all users

Not necessarily so, the shell *may* overwrite those things (it used to ages ago). You're better off putting things in /etc/profile.d (IMO).

For more about BASH_ENV, have a look at https://www.gnu.org/software/bash/manua ... Files.html (specifically non-interactive login).

[TrevorH]

And don't forget that systemd has its own set of rules and (at least some of the time) doesn't use PAM at all.

[sml]

Around 2015, then on Debian Jessie, I wrote a shell snippet ~/.shenv that gets sourced from startup configuration for different shells and sets environment variables. I'm still using it today. At the top, it contains a lengthy comment about how different pieces of environment come together. While I updated it from time to time, it may be not quite up-to-date and should be taken with a grain of salt. Here is the said comment:

Code: Select all

# Common environment for POSIX-compliant shells/xsession

# This file gets sourced from ~/.profile for login POSIX-conform shells,
# i.e. dash, posh, ksh93, mksh always and bash, yash, zsh when in POSIX mode
# (or from ~/.{bash_,yash_,z}profile for bash, yash, zsh in their native modes,
# respectively).
# Fo GUI logins it gets sourced from ~/.xsessionrc instead

# Do not confuse it with ~/.zshenv that gets invoked by zsh both for inter-
# active and non-interactive shells. A non-interactive shell usually needs
# some variables defined, too, e.g. PATH, HOSTNAME, USER, LOGNAME, LANG et al.
# Most of them are taken care of in some other place like
# /etc/locale.conf, /etc/environment, /etc/security/pam_env.conf, etc.

#/etc/security/pam_env.conf sets nothing by default
#/etc/environment sets nothing by default
#$HOME/.pam_environment currently not used
#/etc/pam.d/{fingerprint,password,system}-auth call 'auth required pam_env.so'
#/etc/pam.d/{atd,gdm-launch-environment} also call 'auth required pam_env.so'
#/etc/locale.conf sets $LANG ($LC_{NUMERIC,TIME,MONETARY,PAPER,MEASUREMENT})
#$HOME/.i18n sets nothing by default ($LC_ALL may go here)

## login
#/etc/login.defs sets no env vars by default (not even $MAIL)
# pam_mail.so could also set $MAIL, but never used in /etc/pam.d/*
# login uses /etc/login.defs and starts login shell ($SHELL)
# Starting console sets $TERM
# bash sets [E]UID internally
#/etc/profile sets PATH, USER=$LOGNAME, MAIL, HOSTNAME, HISTSIZE, HISTCONTROL
# Some /etc/profile.d scriptlets:
#  flatpak.sh sets $XDG_DATA_DIRS
#  lang.sh sets vars from /etc/locale.conf and $HOME/.i18n
#  less.sh sets LESSOPEN (user-defined filters go to ~/.lessfilter)
#  modules.sh sources /usr/share/Modules/$shell
#    $shell scripts set ENV,BASH_ENV,PATH,MANPATH (ksh, zsh also set FPATH)
#    they also set initial values for MODULESHOME, MODULEPATH, LOADEDMODULES
#  scl-init.sh sets MODULESHOME, augments MODULEPATH
#  vte.sh sets PROMPT_COMMAND unconditionally under bash (duh!)
#  sh.local gets sourced at last (empty by default)
# for bash, /etc/bashrc gets sourced (non-login bash initializations):
#   interactive?
#     set PROMPT_COMMAND if not already set
#       for non-login xterm|vte: to /etc/sysconfig/bash-prompt-xterm
#       for screen:              to /etc/sysconfig/bash-prompt-screen
#       otherwise:               to /etc/sysconfig/bash-prompt-default
#   non-login?
#     set $SHELL
#     source /etc/profile.d/*.sh
#       PROMPT_COMMAND gets redefined by vte.sh (duh!),
#       sh.local doesn't get sourced (duh!).

## GUI login: $HOME/.xsessionrc is sourced

## Already set at this point: $HOME, $USER, $LOGNAME, $SHELL

# Starting a terminal emulator (xterm, rxvt etc.) sets $TERM

# Note: /etc/mkshrc sets and exports $SHELL. It's only an example of user
# shell resource file ~/.mkshrc and never gets executed on its own.

# $LINES and $COLUMNS get set for non-interactive shells by zsh and mksh only.
# They can be set from a shell script by `tput lines` and `tput cols`
# provided $TERM is set beforehand, which is usually the case if the script
# is called from the console or terminal emulator. Setting them when you are
# NOT in a terminal makes little sense anyway.
# Alternatively, they can be set from `stty size`, but I'm not aware of a ter-
# minal emulator not setting $TERM on start.

[pjsr2]

It is rather overwelming: https://blog.flowblok.id.au/2013-02/she ... ripts.html