Environment variables and shell configuration files form the backbone of how Unix/Linux shells initialize and share state across processes. Every shell session — whether opened by logging in, launching a terminal, running a cron job, or spawning a subshell — loads a specific subset of configuration files determined by its type, and understanding that type-to-file mapping is the single most important mental model for diagnosing "why doesn't my variable work here?" problems. The distinction between a shell variable (local to the current shell) and an environment variable (inherited by child processes) is equally foundational: export is the bridge between the two. Mastering PATH management, the source built-in, and tools like direnv transforms scattered, session-losing configuration into reproducible, project-aware environments.
What This Cheat Sheet Covers
This topic spans 17 focused tables and 129 indexed concepts, 112 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Shell Session Types
Every shell falls into one of four quadrants formed by two independent axes: login vs. non-login, and interactive vs. non-interactive. Which configuration files get sourced depends entirely on these two attributes, not on which shell you use.
| Type | Example | Description | |
|---|---|---|---|
ssh userbash --login | • Reads /etc/profile then the first of ~/.bash_profile, ~/.bash_login, or ~/.profile it finds• this is where session-wide env vars should be set | ||
Opening a new terminal tab | • Reads only ~/.bashrc (bash) or ~/.zshrc (zsh)• the most common day-to-day shell | ||
bash script.shcron job | • Reads the file named by $BASH_ENV if set• no standard startup files are sourced automatically | ||
ssh host cmd | • Reads ~/.bashrc in bash (treated as non-interactive remote)• behavior differs slightly from local shells |