Environment variables & PATH

export, $VAR, .bashrc, and how $PATH works.

Beginner12 min · lesson 10 of 25

Environment variables are named values that the shell and the programs it launches can read — a simple key/value store that carries configuration and context. Some are set by the system (your username, home directory, terminal type); you set others to configure how programs behave. They are how a shell session remembers things and how you pass settings to commands without hardcoding them.

terminal
$ echo $HOME # read a variable with $
/home/deploy
$ echo $USER
deploy
$ printenv | head -4 # list environment variables
HOME=/home/deploy
USER=deploy
SHELL=/bin/bash
LANG=en_US.UTF-8

Setting variables, and export

You set a variable with NAME=value (no spaces around the =). But a plain assignment only exists in your current shell; to make it available to programs you launch, you export it. That distinction matters constantly: a variable you set but do not export is invisible to the command you then run, which is a common "why is my setting being ignored?" puzzle.

terminal
$ GREETING="hello" # set a variable in this shell only
$ echo $GREETING
hello
$ export API_URL="https://api.internal" # export = available to launched programs
$ node server.js # server.js can now read process.env.API_URL
# a common pattern: set a variable just for one command
$ LOG_LEVEL=debug ./myapp # LOG_LEVEL is set only for this one run

PATH: how the shell finds commands

The most important variable is PATH — a colon-separated list of directories the shell searches, in order, to find the program for a command you type. When you type ls, the shell looks through each PATH directory until it finds an executable called ls. This is why which shows where a command resolves, and why the order matters: the first match wins. Adding a directory to PATH lets you run your own tools by name.

terminal
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/home/deploy/.local/bin
# the shell searches these left to right; the first "ls" it finds is the one that runs
$ export PATH="$HOME/bin:$PATH" # add your own bin dir to the FRONT of PATH
$ which mytool
/home/deploy/bin/mytool

Making it permanent: .bashrc

Variables you set in a shell vanish when you close it. To make settings persist, put them in a startup file that the shell reads every time it opens — ~/.bashrc for interactive shells (or ~/.profile / ~/.bash_profile at login). Adding your exports and PATH changes there means every new terminal has them. After editing, source the file (or open a new shell) to apply it without logging out.

~/.bashrc
export EDITOR=vim
export PATH="$HOME/bin:$PATH"
export API_URL="https://api.internal"
# apply changes to the current shell without logging out:
# $ source ~/.bashrc
Never put secrets in exported env vars or .bashrc
It is tempting to export a password or API token as an environment variable — but env vars leak: they appear in a process’s /proc/<pid>/environ, in ps output in some cases, in crash dumps, and in child processes, and a token hardcoded in .bashrc sits in a file anyone who reads your home directory can see. Use env vars for non-sensitive config; for real secrets use a secrets manager or a file with tight permissions, exactly as the container and CI courses insist. A secret in the environment is a secret one command away from a log.