Linux Environment Variables

What Environment Variables Are

Environment variables are named values that programs read at runtime. They are a simple way to pass configuration such as paths, usernames, regions, API endpoints, and feature flags into shells and processes.

Common examples include HOME, USER, SHELL, and PATH.

To inspect variables, you can use:

printenv
env
echo $HOME
echo $PATH

• printenv prints environment variables
• env shows the environment for the current process
• echo $VAR prints one variable

Shell Variables vs Environment Variables

A shell can store local variables that only exist inside that shell session. A variable becomes part of the environment when you export it.

PROJECT_NAME=devops-platform
echo $PROJECT_NAME
export PROJECT_NAME
env | grep PROJECT_NAME

In that example:

• PROJECT_NAME=... creates a shell variable
• export PROJECT_NAME makes it available to child processes

This distinction matters because many tools only see exported variables.

Tip: If a script cannot see a variable that works in your terminal, check whether you exported it.

Scope and Process Inheritance

Environment variables are inherited downward. If you export a variable in one shell and start a child process, that child receives the variable. But the parent shell does not learn variables from the child.

Example:

export APP_ENV=staging
bash -c 'echo $APP_ENV'

The child bash process can read APP_ENV. If the child changes it, that change does not automatically flow back up to the original shell.

This one-way inheritance explains why scripts often need to be sourced when you want them to affect your current shell.

Persisting Variables Across Sessions

A variable set in the terminal normally disappears when the session ends. To make it persistent, place it in a startup file.

~/.bashrc

Used for interactive Bash shells. Good for aliases, exports, and shell customizations.

echo 'export EDITOR=vim' >> ~/.bashrc
source ~/.bashrc

~/.bash_profile and ~/.profile

These are read for login shells, depending on shell and distribution behavior. They are often used for variables that should exist at login time.

echo 'export APP_ENV=development' >> ~/.profile
source ~/.profile

/etc/environment

This file is system-wide and is often used for variables that should apply to many users. Its format is usually simple KEY=value lines rather than shell scripting.

sudo sh -c 'echo "JAVA_HOME=/usr/lib/jvm/java-21-openjdk" >> /etc/environment'

Note: Be careful with system-wide files. A bad edit can affect every user and service on the host.

Understanding PATH

PATH is one of the most important environment variables in Linux. It tells the shell where to look for executable commands.

View it with:

echo $PATH

You will usually see several directories separated by colons, such as /usr/local/bin:/usr/bin:/bin.

When you type python3, the shell searches those directories in order.

Adding a directory to PATH

For the current shell:

export PATH="$HOME/bin:$PATH"

To make it persistent for Bash:

echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Order matters. If two directories contain commands with the same name, the first one in PATH wins.

.env Files and Sourcing

Projects often keep environment settings in a .env file.

Example .env content:

APP_ENV=production
APP_PORT=8080
DATABASE_URL=postgres://app:secret@db:5432/app

A plain .env file is just text until you load it. One simple approach is sourcing a shell-friendly file:

set -a
source .env
set +a

set -a tells the shell to automatically export variables created while the file is sourced.

This pattern is useful for local development, but secrets in .env files should be handled carefully and usually should not be committed to Git.

A Practical Example

Suppose you installed a CLI tool into $HOME/bin, and the command is not found.

A sensible troubleshooting flow is:

echo $PATH
ls $HOME/bin
export PATH="$HOME/bin:$PATH"
which mytool

If that works, persist the PATH change in the appropriate profile file.

Environment variables are simple, but they influence many Linux workflows: shells, scripts, containers, systemd services, CI pipelines, and application configuration.

What You Should Remember

Use printenv, env, and echo $VAR to inspect environment data. Use export when child processes need access. Store persistent values in the right startup file, and understand that PATH controls command lookup order.

Once you are comfortable with environment variables, many Linux behaviors become easier to explain and troubleshoot.

Test Your Understanding