Every Linux process inherits a set of environment variables from its parent. These key-value pairs control how shells behave, where programs look for executables, and which configuration a running application picks up. Get them wrong and your deployment breaks at 2 AM. Get them right and you’ve got a clean, portable system config that travels with your user profile or your entire server.
Whether you’re configuring a fresh VPS, debugging a broken CI pipeline, or deploying a Python app that refuses to find its database, environment variables are at the center of it. They’re one of those foundational Linux concepts that you’ll use every single day once you understand them.
This guide walks through the commands you’ll actually use day to day: listing, printing, setting, persisting, and deleting Linux environment variables. We’ll also cover best practices and common pitfalls that trip up even experienced sysadmins.
What Are Environment Variables in Linux
Environment variables are dynamic key-value pairs that shape how shells and processes behave on a Linux system. Run printenv in a terminal and you’ll see dozens of them: PATH tells the shell where to find executables, HOME points to your user directory, SHELL identifies which shell you’re running, and LANG sets your locale.
Admins use them to share configuration across applications without hardcoding values. A single PATH variable, for example, lets every program on the system locate binaries without each one maintaining its own search list. Think of environment variables as a shared bulletin board that every process on the system can read.
Linux draws a line between two types of variables. Environment variables have a global scope. They’re visible to child processes, subshells, and any program launched from that session. Shell variables, on the other hand, exist only in the current session. Spawn a subshell with bash and they vanish.
That distinction matters more than it sounds. It’s the reason your script works perfectly when you run it interactively but falls over when launched by cron, systemd, or another user. The calling process doesn’t carry your shell variables along, and the script finds an empty value where it expected a path.
How to Manage Linux Environment Variables
Managing environment variables on a Linux system means knowing four operations: list them, print a specific one, set new ones, and remove what you don’t need. Everything below works on any standard Linux distribution, from Ubuntu and Debian to CentOS and Arch. Connect via SSH or open your local terminal and you’re ready to go.
How to List Environment Variables in Linux
The fastest way to list environment variables in Linux is the printenv command:
printenvThat dumps every variable and its value to stdout. The output gets long fast, so pipe it through less for something scrollable:
printenv | lessThe env command works almost identically to printenv. Where things differ: the set command in Linux prints both environment and shell variables, giving you the full picture. If you only want shell variables, filter with grep:
set | grep -i my_varSome variables you’ll see constantly across Linux distributions:
PATH– directories the shell searches for executable filesHOME– the current user’s home directoryUSER– the logged-in user account nameSHELL– path to the current user’s shellPWD– the current working directoryEDITOR– the system’s default text editor
These come pre-set on virtually every Linux distribution. You can define your own for any purpose: custom application configs, deployment flags, service endpoints. That’s where things get interesting.
How to Print Environment Variables in Linux
To print a single environment variable in Linux, use the echo command with a dollar sign prefix:
echo $PATHThe linux echo command reads the variable’s current value and writes it to the terminal. It’s case-sensitive, so $path and $PATH are different things.
You can also use printenv with the variable name directly:
printenv HOMENeed to check whether a variable exists at all? Pipe printenv through grep:
printenv | grep USERFor querying multiple variables at once:
printenv HOME PATH SHELLEach value prints on its own line. Quick, no fuss. This is handy when you’re writing a setup script and need to confirm several values are in place before proceeding.
Set Environment Variable in Linux Using Export
The export command in Linux creates a temporary global environment variable. Here’s the basic syntax:
export MY_VAR="some_value"That variable is now visible to the current shell and any child process you spawn from it. Print it to confirm:
echo $MY_VARYou can assign multiple values separated by colons, which is how PATH works:
export PATH="$PATH:/opt/myapp/bin"Here’s the catch: this is temporary. Reboot your system, open a new terminal session, and it’s gone. The linux export command only affects the running session and its children. This trips up beginners constantly. They set a variable, it works, they reboot, and it’s vanished.
For a local shell variable (one that doesn’t propagate to child processes), skip the export keyword:
my_local_var="test"Convention says lowercase for local, uppercase for global. Stick to it. Future you will appreciate the clarity when you’re troubleshooting at midnight.
How to Make Persistent Environment Variables
Temporary variables disappear on reboot. For permanent environment variables in Linux, you need to write them into configuration files. Which file depends on who should see the variable.
User-Specific Environment Variables
Edit the bashrc file to set variables that persist for a single user. Open it with any text editor:
nano ~/.bashrcAdd your export statement at the bottom:
export API_URL="https://api.example.com"Save and exit. The variable won’t take effect in your current session until you reload the file:
source ~/.bashrcThe source bashrc command re-reads the file without requiring you to log out and back in. It’s the single most common command people forget when they add a new variable and wonder why it doesn’t show up.
You can also use ~/.profile if you need variables available in login shells. The distinction: .bashrc runs for every interactive shell, .profile runs once at login. Pick the one that matches your use case. If you’re not sure, .bashrc is the safer default for most scenarios.
System-Wide Environment Variables
For variables every user on the system needs, edit /etc/environment:
sudo nano /etc/environmentAdd plain key-value pairs without the export keyword:
JAVA_HOME="/usr/lib/jvm/java-17"Save, then reboot or re-login for changes to take effect.
An alternative approach: create a shell script in /etc/profile.d/. This directory is sourced at login for all users:
sudo nano /etc/profile.d/custom_env.shInside the file, use export as you normally would:
export LOG_LEVEL="info"Give it a descriptive filename. You’ll thank yourself when the directory has 15 scripts and you need to find the one that sets the proxy config. Reboot to apply, then confirm with printenv. The /etc/profile.d/ approach is cleaner for managing multiple groups of variables because each concern gets its own file.
Delete Environment Variables in Linux
The unset command removes an environment variable from the current session:
unset MY_VARGone. But only for this session. If that variable lives in ~/.bashrc or /etc/environment, it comes right back after a reboot. The unset command is temporary by design.
To permanently remove an environment variable in Linux, open the config file where it’s defined and delete (or comment out) the line. Commenting is safer and saves you from future grief:
# export API_URL="https://api.example.com"A hash symbol at the start disables it without destroying it. When the inevitable “why did we remove that?” question comes up three weeks later, you can uncomment it in seconds instead of reconstructing the value from memory.
Using Environment Variables in Development
Here’s where environment variables earn their keep. Storing database credentials, API keys, and service URLs as environment variables keeps them out of your codebase. No secrets in version control. No accidentally pushing a production database password to a public GitHub repo. If you’ve ever seen a company in the news for leaked credentials, odds are good someone skipped this step.
The pattern works like this. You define different variables for each stage:
export APP_ENV="staging"export DB_HOST="staging-db.internal"When you deploy to production, you swap the values. The application code reads $APP_ENV and $DB_HOST and behaves accordingly. No code changes between environments. The same Docker image, the same binary, the same script runs everywhere with different behavior based purely on the variables it inherits.
This approach also simplifies automation. A deployment script can set environment variables before launching an application, and every config value flows from one place. Compare that to maintaining separate config files per environment, each one a potential source of drift and mistakes. Three environments with five config files each is fifteen files to keep in sync. Environment variables cut that down to one mechanism.
Environment Variables Best Practices
Knowing the commands is half the battle. Using them well is what separates a clean system from one that breaks in mysterious ways.
Use Descriptive Variable Names
VAR1 tells you nothing. POSTGRES_CONNECTION_STRING tells you everything. Descriptive names prevent the scenario where you’re staring at 40 exported variables and can’t figure out which one controls the log output directory.
Follow a consistent naming convention. Prefix related variables with the application or service name: MYAPP_DB_HOST, MYAPP_DB_PORT, MYAPP_LOG_PATH. When another team member inherits your server, they’ll figure out the system in minutes instead of hours. Vague names create tribal knowledge. Descriptive names create documentation that lives where it’s actually used.
Manage Variable Scope Correctly
A common trap: you create a shell variable with the same name as a global environment variable. The shell doesn’t know which one you mean, and suddenly your application reads the wrong value. I’ve seen this tank a production deployment because someone had a local PATH override they’d forgotten about.
Use local (shell) variables for throwaway work: a loop counter in a script, a temp file path, a one-off test value. Use global environment variables for anything shared across processes: database URLs, log levels, feature flags.
Stick to the convention. Lowercase for local shell variables, uppercase for globals. PATH is system-wide. path_to_tmp is session-only. That visual distinction keeps you honest.
Audit Environment Variables Regularly
Variables accumulate. Old API keys linger. Deprecated service URLs stick around. Someone set a debug flag six months ago and forgot about it, and now your production server is writing verbose logs to a disk that’s 94% full. This happens more often than anyone likes to admit.
Dump your current variables to a file periodically:
set > env_audit_$(date +%Y%m%d).txtCompare against previous dumps. Remove what’s dead. Rotate credentials that show up in the export list. Check that nothing sensitive leaked into a system-wide file that every user can read. This isn’t glamorous work, but it’s the kind of hygiene that prevents security incidents and mysterious production failures. Treat it like changing the oil: boring, necessary, catastrophic if neglected.
Linux Environment Variables FAQ
How Do I See Environment Variables in Linux
Run printenv or env to list all environment variables. Use echo $VARIABLE_NAME to check a specific one. The set command shows both shell and environment variables together. Pipe any of these through grep to filter for what you need. For a scrollable view of all variables, try printenv | less.
What Are the Types of Environment Variables
Linux has two main categories. Local (shell) variables exist only in the current session and disappear when you close the terminal or spawn a subshell. Global environment variables persist across child processes and come in two flavors: user-specific (stored in ~/.bashrc or ~/.profile) and system-wide (stored in /etc/environment or scripts in /etc/profile.d/).
Local vs Global Environment Variables
Local variables are confined to the current shell. Launch a subshell and they’re gone. Global variables propagate to every child process, subshell, and program started from that session. If your script needs a value and it’s running as a child process, it must be a global (exported) variable. Use lowercase names for local variables and uppercase for global ones to keep them distinct.
Where Are Environment Variables Stored in Linux
User-level persistent variables typically live in ~/.bashrc or ~/.profile in the user’s home directory. System-wide variables go in /etc/environment or as individual shell scripts in /etc/profile.d/. Temporary variables exist only in memory for the current session and aren’t stored in any file. They vanish on logout or reboot.
How to Add Environment Variable in Linux
For a temporary variable, use export VAR="value" in the terminal. Add that same export line to ~/.bashrc and run source ~/.bashrc to load it immediately, for a permanent user-level variable. For a system-wide variable, add the key-value pair to /etc/environment (without the export keyword) and reboot or re-login.
