Environment Variables and PATH

Every running process, including your shell, keeps a table of environment variables - named strings like HOME, USER, or PATH that configure how programs behave.

Reading a variable

Put a $ in front of a variable's name and the shell substitutes its value before running the command:

echo $HOME
echo "Logged in as $USER"

Wrap the name in ${ } when you need to be explicit about where the name ends, which matters right before more text:

echo "${USER}_backup.tar"

Variables only expand when unquoted or inside double quotes. Single quotes turn expansion off - echo '$HOME' prints the literal text $HOME, not its value.

Setting a variable

export STAGE=production   # define STAGE for this shell and any command it starts
echo $STAGE
env                        # list every variable currently exported

Any process you start after export inherits a copy of these variables - that is what "environment" means: it travels with the process, not just the current line.

PATH: how the shell finds commands

PATH is the most important environment variable of all. It is a colon-separated list of directories the shell searches, in order, whenever you type a bare command name like ls instead of a full path like /bin/ls. A typical value looks like:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

If a command reports "not found" even though the file exists, it is almost always because the directory holding it is missing from PATH.

Try it

export BUILD_ENV=staging
echo $BUILD_ENV
export BUILD_ENV=production
echo "now building for $BUILD_ENV"
env

Further reading

• "Learning the bash Shell" by Cameron Newham (O'Reilly) - the definitive guide to shell variables, quoting rules, and the startup files (.bashrc, .bash_profile) that set them up for you automatically.
• "The Linux Command Line" by William Shotts (No Starch Press) - the "Environment" chapter in Part II walks through exactly this material with more real-world examples.