Table of Contents
Introduction
Environment variables are named pieces of information that the shell and programs use to understand the context in which they are running. They describe things such as who you are, where your home directory is, what language you prefer, and where to find executable programs.
Unlike normal variables that you might later use in shell scripting, environment variables are designed to be inherited by child processes. When you start a program from the shell, it receives a copy of your environment variables and can change its behavior based on them.
Environment variables are part of your process environment and are automatically inherited by programs you start. They can control how programs behave and where they look for files and settings.
Viewing Environment Variables
To see all environment variables available in your current shell session, you can use the printenv or env commands. For example, typing printenv and pressing Enter will list each variable and its value, one per line, in the form NAME=value.
You can also display the value of a single variable by giving its name to printenv, such as printenv PATH or printenv HOME. If you want to examine variables using the shell itself, you can echo their value. In the shell, environment variables are referred to with a dollar sign in front of their names, for example echo $USER or echo $SHELL.
Values can contain many characters, including spaces, but you usually see them without quotes. If a variable is not set, using echo $NAME will print an empty line, and printenv NAME will produce no output.
Common Environment Variables
Several environment variables are particularly important because many programs depend on them. The following examples are common across most Linux systems.
HOME points to your home directory, such as /home/alice. Programs use this to know where to store user specific configuration and personal files. echo $HOME reveals this path.
USER or sometimes LOGNAME contains your username, such as alice. Programs can use this to display messages that include your name or to select user-specific settings.
SHELL shows the path of your default login shell, for example /bin/bash or /usr/bin/zsh. This indicates which program is started for you when you log in to a text console or open certain terminals.
PWD stands for “present working directory” and always reflects the directory you are currently in, the same one you see when you run pwd. It changes automatically when you move around the filesystem with commands that affect your current directory.
LANG and related variables such as LC_ALL or LC_* describe your language and locale preferences, including language, region, and formatting rules for dates and numbers. For example, LANG=en_US.UTF-8 means United States English with UTF-8 character encoding.
PATH is one of the most important variables, because it governs where the shell looks for programs when you type a command name. It contains a list of directories separated by colons, for example /usr/local/bin:/usr/bin:/bin. When you type ls, the shell searches each directory in PATH in order until it finds an executable file named ls.
The PATH variable is a colon-separated list of directories. When you run a command like ls, the shell searches each directory in PATH in order and runs the first matching executable it finds.
Shell Variables vs Environment Variables
In a shell session there are two related concepts. Shell variables live only inside the current shell. Environment variables are shell variables that have been marked to be part of the process environment. The important difference is inheritance.
A plain shell variable is visible only inside that single shell. When you start a child process, for example by running ls or opening a subshell, that child does not see this plain variable. Once you export a variable to the environment, child processes will receive a copy of it and can use it.
In practice this means you might first define a shell variable, then decide to make it an environment variable. You can think of exporting as promoting a shell variable so that it becomes part of your environment that other programs see.
Creating and Modifying Environment Variables
You can create or update an environment variable for your current shell by using assignment syntax. For example, typing NAME="Alice" creates or changes a shell variable named NAME with the value Alice. The shell does not print anything when you do this. You can check its value with echo $NAME.
At this point NAME is only a shell variable, not an environment variable. To make it part of the environment, you use the export command. If the variable already exists as a shell variable, you can run export NAME. If it does not exist, you can both assign and export in one step by writing export NAME="Alice".
After a variable is exported, you can verify that it now appears among other environment variables by running printenv NAME. Previously, printenv NAME would not show this variable, but once exported it behaves like any other environment variable and is inherited by commands you run.
If you want to change the value of an existing environment variable, you simply assign a new value with the same syntax. For example you might write PATH="/my/custom/bin:$PATH" to prepend a new directory to your existing PATH. The right hand side can use the current value of the variable, which the shell expands when it processes the assignment.
Sometimes you want to set an environment variable that applies only to a single command. You can do this by putting the assignment directly before the command on the same line. For example, typing LANG=fr_FR.UTF-8 ls will run ls with LANG set to French, but after that command finishes your current shell will still have its previous LANG. This pattern is useful when you want to temporarily adjust settings for just one program.
Using export NAME=value creates or updates an environment variable. Using NAME=value command sets NAME only for that single command without changing your current shell environment.
Unsetting Environment Variables
Sometimes a variable is set to a value that interferes with how a program behaves. In such cases you can remove the variable entirely from your shell using the unset command. For example, unset NAME will delete both a shell variable and its exported environment form with that name, if either exists.
After you unset a variable, it disappears from the environment of future child processes and is also unavailable in the current shell. Running echo $NAME will show nothing and printenv NAME will produce no output. Unsetting is different from setting a variable to an empty value. If you write NAME="", the variable still exists but with an empty string as its value, which some programs treat differently from a completely absent variable.
Environment Inheritance and Processes
When you start a new process from your shell, that process receives a copy of your current environment variables. This means that if you export a variable, then start a program, that program can read the variable but any changes it makes will not affect your shell.
The environment flows only from parent to child. For example, your terminal starts a login shell with an initial environment, that shell starts other commands with copies of its environment, and so on. If a graphical application launches a terminal, the terminal shell will inherit the environment from the graphical environment.
This inheritance is one reason why environment variables are such a common way to configure programs. For instance, if you set a variable to tell a tool where to find its configuration directory, every instance of that tool you start from your shell will see the same setting without needing a separate configuration file for each run.
Persistent Environment Variables
So far, all changes you make to environment variables apply only for the lifetime of your current shell session. When you close the terminal, your changes vanish. To keep some environment variables across logins or new terminals, you place assignments and exports into shell startup configuration files. Those files will be read each time a new shell begins, which makes the environment changes persistent.
Exactly which file you use can depend on the type of shell you are using and on whether it is a login shell or an interactive non-login shell. For the Bourne compatible shells such as bash, zsh, or dash, a common pattern is to place environment variable exports into files that are designed to be read at login time or at shell startup, for example a configuration file in your home directory for your chosen shell.
Within such a file you can use the same syntax as in the interactive shell. For instance you may include lines such as export EDITOR=vim or export PATH="$HOME/bin:$PATH". After saving the file and opening a new terminal, these variables will be set automatically. If you want your current shell to read updated configuration without closing it, you can source the file with a command like . ~/.bashrc or source ~/.bashrc, depending on your shell, which directly executes the contents in the running shell.
Because persistent environment configuration affects all future shells and programs you start, it is important to keep these files tidy and to avoid accidental mistakes such as overwriting PATH without including the old value.
Security Considerations
Environment variables are powerful but they can also have security implications. Some variables, such as those that hold tokens or passwords, may be sensitive. Although it is better to avoid storing secrets in environment variables when possible, some tools use this pattern. In that case, be careful not to accidentally reveal them.
For example, running simple commands like env or printenv will display every variable, which could expose secrets to anyone reading your screen or viewing your terminal history. Another concern appears if you add untrusted directories to your PATH. If a malicious program with a common command name appears in such a directory, your shell may run that program instead of the expected system tool.
You should also be cautious when placing environment variable definitions into configuration files. Incorrect settings can break your login environment or make standard commands unavailable. When changing key variables such as PATH, it is usually safer to extend existing values instead of replacing them entirely, by using a pattern like PATH="$HOME/bin:$PATH" so that the original directories remain included.
By understanding what environment variables are, how they are inherited, and how to manage them, you gain a flexible way to customize how Linux programs behave in your shell environment.