Customizing the shell environment

Login shells and interactive shells read different files

A LOGIN shell — the one you get from a console login or an ssh session — reads /etc/profile, then the first it finds of ~/.bash_profile, ~/.bash_login or ~/.profile. An INTERACTIVE NON-LOGIN shell — a new terminal window inside an already logged-in desktop — reads ~/.bashrc and, on most distributions, /etc/bash.bashrc or /etc/bashrc. That is why a variable that works after ssh is missing in a terminal window, and it is the most common real-world symptom of this objective.

Most distributions paper over the split by having ~/.bash_profile source ~/.bashrc, so everything goes in ~/.bashrc and is read in both cases. /etc/profile.d/ is the system-wide equivalent: drop a .sh file there rather than editing /etc/profile, so a package can add settings without fighting over one file. Logout runs ~/.bash_logout.

What you put in them

Variables: NAME=value defines, export makes it inherited. PATH, EDITOR, LANG and PS1 (the prompt string) are the ones set most often. Aliases: alias ll='ls -l' — an alias only expands as the FIRST word of a command, and it is not inherited by scripts or subshells, which is why anything that has to work in a script belongs in a function or a real command instead.

Taking a variable away again is unset NAME, and the exam separates it from the two things that resemble it, because a program can tell all three apart. NAME= leaves the variable there holding an empty string — still exported, so a child still receives it, and anything that merely asks whether the name is set still finds it. export -n NAME removes only the export attribute: children stop seeing it, set still lists it, and it is still a variable of this shell. unset is the one that removes the name entirely, from the shell and from the environment handed to everything it starts. The exception is a variable made readonly, which cannot be unset at all — the only way out of that is a new shell.

Reading one back has three answers and the exam knows it. echo $PATH is the shell doing the work — it expands the variable and echo never sees a variable at all, which is why it prints a set-but-unexported variable that the other two cannot. printenv PATH asks for one variable by name, and printenv with no argument lists the whole environment. env also prints the environment, and its real job is running a command with a modified one — env VAR=x command — so env | grep '^PATH=' is the roundabout spelling of the same question. set is the fourth and is different again: it lists shell variables AND functions, exported or not.

Functions are defined as name() { …; } and behave like commands, taking $1, $2 and so on. Both aliases and functions are shell-local, so they must be defined in a file the shell reads rather than exported. source FILE (or its synonym . FILE) runs a file in the CURRENT shell rather than a child, which is the whole reason it exists: a script that sets a variable in a child shell changes nothing, and sourcing it changes your shell.

/etc/skel is the template for new accounts — whatever is in it is copied into a new user's home directory when the account is created, which is how every new user gets a sensible .bashrc.