Have you ever faced a scenario where you needed to set an environment variable or run a program to alter your shell or desktop environment, but didn't know the best place to call it from?
This is a common situation. Many tasks require environment variables to function correctly, from running Debian packaging utilities to managing IaaS and everything in between.
Sometimes a program usually only needs to run once when you first log in, such as the xrandr command. Also, programs occasionally expect to be injected into the shell, such as rbenv, rvm or SitePoint's own envswitch utility.
These settings shouldn't just be loaded from anywhere. Sometimes there are a number of factors that should be considered before making a judgement about the best place.
Let's take a look at some common options present on a Debian GNU/Linux Jessie installation, and try to make sense of it all.
/etc/profile
By default, Debian provides /etc/profile, which is immediately used to set the $PATH (used to declare command search paths).
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH
For convenience, the root user (user ID 0) gets different paths defined to everyone else. That's because system binary (sbin) locations are ideally reserved for system administration or programs that must run as root. The games paths are omitted for root because you should never run programs as the root user unless absolutely necessary.
Next up, /etc/profile handles the setup of $PS1, which is used to set the primary prompt string. The default values defined are '$ ' (or '#' for root), unless the shell is Bash. If the shell is Bash, /etc/bash.bashrc is sourced to handle it (amongst other things) instead. We'll talk about /etc/bash.bashrc shortly.
So at this point, we can deduce that /etc/profile is read by all shells during login (i.e. by the login command). Instead of using the more efficient Bash built-in variable ${UID} to determine the user ID, /etc/profile calls the id command for this instead. Instead of defining a fancy shell prompt, a Bash-specific configuration was sourced, since Bash supports backslash-escaped special characters such as \u (username) and \h (hostname), which many other shells would not. /etc/profile should try to be POSIX compliant, so as to be
compatible with any shell the user might install for herself.
Debian GNU/Linux often comes pre-installed with Dash, which is a basic shell that only aims to implement POSIX (and some Berkeley) extensions. If we modify /etc/profile (make a backup first!) to have the PS1='$ ' line set a different value and simulate a Dash login (via the dash -l command), we can see Dash uses the prompt we defined. However, if we instead call the dash command without the -l argument, /etc/profile is not read, and Dash falls back to a default value (which incidentally is what the original PS1 value was before we modified it).
The last interesting thing to note about /etc/profile is the following snippet at the end:
if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi
In other words, anything readable matching the /etc/profile.d/*.sh glob is sourced. This is important, because it indicates that editing /etc/profile directly is never actually required (so restore that backup you made earlier!). Any variables defined above can be overridden in a separate file. One benefit of doing this is that it allows system upgrades to automatically add changes to /etc/profile, since Debian's Apt package management system typically won't touch modified configuration files.
Continue reading %Understanding *NIX Login Scripts%
by Adam Bolte via SitePoint
