The env & export command in Linux
Environment variables are named strings every process inherits from its parent: PATH tells the shell where to find commands, HOME is your directory, EDITOR your preference, and countless apps read their config (DATABASE_URL…) from them. The rules of inheritance — downward only, at launch time — explain every "why didn't my variable work" mystery.
How env & export works
The environment is a block of KEY=value strings handed to every process at the moment of exec, along with its arguments. Inheritance is a copy made once, at launch: children receive a snapshot of the parent's environment, and nothing a child changes flows back. Every "my export disappeared" mystery reduces to this one rule plus process boundaries — the script was a child; your shell never changed.
Inside the shell there are two tiers: plain variables (VAR=x) live in the shell's own memory, invisible to children; export promotes a variable into the environment block that future children will copy. PATH is simply the most consulted entry: an ordered list of directories the shell walks to resolve command names — order is precedence, which is why prepending ~/.local/bin makes your builds win over the system's.
Syntax
export VAR=value | env | printenv [VAR] Common options
| Option | What it does |
|---|---|
VAR=value | A shell variable — visible to the shell only. |
export VAR=value | Promote to environment: children inherit it. |
printenv / env | Show the current environment. |
VAR=value command | Set for ONE command only (prefix form). |
unset VAR | Remove it. |
source ~/.bashrc | Re-run your config in THIS shell after editing. |
How to use env & export: examples
$ echo $PATH | tr ":" "\n" The command-search directories, one per line — where the shell hunts for executables, in order.
$ export PATH="$HOME/.local/bin:$PATH" Put your own tools first. Persist it by adding this line to ~/.bashrc.
$ DEBUG=1 ./app One-shot variable: set for this command, gone after.
$ printenv | sort | less Audit the full environment.
Real-world use cases for env & export
Twelve-factor configuration
The same app image runs everywhere because config rides the environment: DATABASE_URL, API_KEY, LOG_LEVEL injected per environment by systemd EnvironmentFile, Docker -e, or CI secrets. Understanding inheritance IS understanding modern deployment.
Untangling version chaos
Wrong python runs: echo $PATH | tr : '\n' shows the search order, type -a python shows every candidate in it, and the fix is a PATH edit in .bashrc. The ritual that resolves every "but I installed the new version" ticket.
Pro tips and common mistakes
- Variables flow down at launch, never up or sideways — recite this before debugging any "it disappeared".
- source ~/.bashrc after editing it; open shells predate your change.
- VAR=x command (prefix form) scopes a variable to one command — cleaner than export-then-unset.
Frequently asked questions about env & export
I set a variable in a script and it vanished — why?
The script ran as a child process; environments flow down, never up. To affect your current shell, source the file: source script.sh (or put exports in ~/.bashrc).
.bashrc or .profile?
.bashrc runs for interactive shells (aliases, prompt, PATH tweaks); .profile/.bash_profile at login. When unsure, .bashrc — and log-out/in or source it.
"command not found" for something installed?
Its directory is not on PATH. Find the binary (find / -name tool 2>/dev/null or dpkg -L pkg), then add its dir to PATH in .bashrc.
Related commands
Print text and variables, and write or append to files with > and >>.
aliasName your habits: shortcuts, safer defaults, and where to keep them.
which & typeWhich binary actually runs when you type a name — and unmask aliases.