Linux online course

Common Linux Environment Variables

Learn what common Linux environment variables mean, how shells inherit them, how to inspect and change them, and why values differ across sessions.

Linux programs often need context: which user started them, where personal files are stored, which commands are available, what language to use, and which terminal or display is active. Much of this context is supplied through environment variables.

An environment variable is a named value passed from a process to programs it starts. A program can read the value and use it to configure its behavior. Variable names are conventionally uppercase, although the operating system does not require uppercase names; the program consuming a name determines its meaning.

How environment variables work

A shell variable is a value maintained by the shell. It is not automatically visible to programs started by that shell. The shell's export operation marks a variable for inheritance. A program started by the shell is a child process; it receives a copy of the parent's exported environment.

project_root="$HOME/projects/demo"
printf '%s\n' "$project_root"

# A child shell cannot see this until it is exported
bash -c 'printf "child: %s\n" "$project_root"'

export project_root
bash -c 'printf "child after export: %s\n" "$project_root"'

Each process receives its own copy. If a child changes its environment, that change does not travel back into the parent shell.

Values can differ according to the user, distribution, login method, shell, terminal emulator, graphical session, system configuration, and the program that launched the process. An interactive terminal, an SSH session, a cron job, a container, and a systemd service should not be assumed to have identical environments.

Inspecting values

printf '%s\n' "$HOME"
printf '%s\n' "$PATH"

printenv
env

Shell expansion replaces $HOME with its value. Double quotes preserve spaces and other special characters in the resulting value. printenv and env list exported environment variables, not every shell-local variable.

Common Linux environment variables at a glance

User, host, and location variables

USER, HOME, PWD, HOSTNAME, and MAIL

• USER identifies the account name associated with the session. Programs may use it for display or default behavior, but authorization should be determined through operating-system identity and permissions rather than trusting this string.
• HOME is the user's home-directory path, such as /home/alex. Applications commonly look there for personal configuration files, caches, keys, and data. A program running under another account may have a different value.
• PWD is the shell's current working-directory path. Running cd /tmp changes it. It is a shell-maintained representation of the current directory; programs can also determine their working directory through operating-system facilities.
• HOSTNAME exposes a host name to the session. It is useful for prompts and logs, but names can be configured differently across containers, virtual machines, and network contexts.
• MAIL conventionally points to an expected local mailbox or mail spool. Its presence does not prove that mail is delivered there; many systems use remote services, Maildir layouts, or other arrangements.

Shell and command lookup variables

SHELL

SHELL commonly contains the configured login-shell path, such as /bin/bash. It is a preference or account configuration value, not a guaranteed description of the shell currently interpreting every command. A script can be launched by one shell even when SHELL names another shell. To investigate the current Bash process, shell-specific checks such as echo "$BASH_VERSION" may help.

For background on Bash, see Bourne Again Shell Bash.

PATH

PATH is a colon-separated, ordered list of directories. When you type a command without an absolute path such as /usr/bin/grep or a relative path such as ./tool, the shell searches PATH from left to right.

printf '%s\n' "$PATH"
command -v python
type -a ls

If two directories contain an executable with the same name, the first matching directory normally wins. A personal directory at the front takes priority over system directories; placing it at the end gives system commands priority.

export PATH="$HOME/.local/bin:$PATH"   # personal tools take priority
export PATH="$PATH:$HOME/bin"           # personal tools are fallback choices

For more command-lookup practice, see Show The Full Path Of Shell Commands.

MANPATH, EDITOR, and VISUAL

MANPATH lists directories where manual pages may be searched. It can be unset because the man command often derives sensible defaults from system configuration. Setting it incorrectly can hide installed manual pages.

EDITOR names a preferred text editor for compatible command-line programs. VISUAL is a commonly used companion variable; many programs give it priority over EDITOR because it traditionally represents a full-screen editor. Applications may instead have their own configuration or precedence rules.

export EDITOR=vim
EDITOR=nano some-command

The second line supplies nano only to some-command, if that command honors EDITOR.

Locale, time, and operating-system identity

LANG and LC_* variables

A locale is a group of language and regional settings affecting translated messages, character handling, sorting, date formatting, numbers, and related behavior. LANG supplies the default locale selection, for example en_US.UTF-8.

Category-specific variables such as LC_TIME can override LANG for one category. LC_ALL overrides the other locale settings and is generally best used as a temporary diagnostic or command-specific override, not as a permanent global setting.

locale
LANG=C date
printf 'LANG=%s LC_ALL=%s LC_TIME=%s\n' "$LANG" "$LC_ALL" "$LC_TIME"

The selected locale must be generated and supported by the operating system. An invalid locale can produce warnings or cause programs to fall back to unexpected behavior.

TZ

TZ is a time-zone setting for programs that honor it. It can override the time zone for one command without changing the machine's system-wide time-zone configuration.

TZ=UTC date
TZ=America/New_York date

This is a session or process override. It does not reconfigure the operating system clock or the system-wide time zone.

OSTYPE

OSTYPE is commonly provided by shells such as Bash as an operating-system-family indication, for example linux-gnu. It is not a universal cross-shell standard. Portable scripts should detect required capabilities, commands, or operating-system interfaces rather than relying only on OSTYPE.

Terminal, prompt, and graphical-display variables

TERM

TERM identifies terminal capabilities. Terminal-aware programs and libraries use it to choose control sequences for colors, cursor movement, alternate screens, function keys, and line drawing. Values such as xterm and xterm-256color are examples for compatible terminals, not values that every terminal should use.

Manually assigning an incorrect TERM can cause broken borders, colors, keys, or cursor behavior because applications select capabilities that the actual terminal emulator does not provide. Prefer the value supplied by the terminal emulator, and do not export a fixed TERM globally without understanding the sessions it affects.

printf 'TERM=%s\nDISPLAY=%s\n' "$TERM" "$DISPLAY"

PS1

PS1 is the primary interactive prompt format in shells such as Bash. It is a shell setting rather than a general environment variable that every program uses. Prompt formats can include a username, host name, current directory, a privilege indicator, color escape sequences, and command substitution.

PS1='\u@\h:\w\$ '
# \u = user, \h = host, \w = current directory, \$ = privilege marker

A prompt can distinguish an unprivileged shell from an administrative shell by using a different privilege marker or color. Complex command substitutions should be used carefully because they run while the prompt is displayed.

DISPLAY, X11, and Wayland

X11 is a windowing system whose client applications use DISPLAY to locate an X server. A conventional local value is often :0. In an SSH session with X11 forwarding, a value such as localhost:10.0 can point to a forwarded display instead of the ordinary local display.

DISPLAY applies to X11. Modern Wayland sessions may additionally use variables such as WAYLAND_DISPLAY and XDG_RUNTIME_DIR. A graphical program failing remotely may need forwarding, authentication, and permissions; assigning DISPLAY randomly is not a substitute for those requirements.

Command history settings

In Bash, HISTFILESIZE controls the maximum number of lines or size retained in the history file, depending on the shell's documented behavior and version. It differs from HISTSIZE, which controls how many commands may be retained in the shell's in-memory history list.

History behavior is shell configuration, not universal environment behavior. The history-file location, when entries are written, duplicate handling, and synchronization between sessions depend on shell settings and startup configuration. Other shells may use different names or mechanisms.

Environment variables versus shell-specific settings

Viewing, setting, exporting, and overriding values

Assigning and exporting

project_root="$HOME/projects/demo"   # shell variable
export project_root                   # now inherited by child processes
export EDITOR=vim                     # assign and export in one operation

Exporting affects the current shell and processes subsequently started by it. It does not automatically update already-running programs, other terminal windows, or the parent process.

One-command overrides

TZ=UTC date
LANG=C date
EDITOR=nano some-command

An assignment immediately before a command creates an exported environment value for that command. The current shell's value remains unchanged after the command finishes. This is useful for testing locales, time zones, editors, and program modes.

Unsetting variables

unset EDITOR

After unsetting a variable, programs may use their own default or behave differently. Removing PATH can prevent ordinary command lookup; removing TERM can break terminal-aware behavior; removing LANG can change locale defaults. Keep a command's absolute path available if experimenting with PATH, for example /usr/bin/printf.

Persistent environment configuration

To make a change survive new sessions, place it in the startup file read by the relevant shell and session type. For Bash, common user-level files include login startup files such as ~/.bash_profile or ~/.profile, and interactive-shell configuration such as ~/.bashrc. The exact file depends on whether the shell is login and/or interactive, how the terminal starts it, and the distribution's conventions.

System-wide initialization can involve files such as /etc/profile, files under /etc/profile.d/, and shell-specific system configuration. Graphical desktop managers may initialize variables separately. SSH, terminal emulators, cron, systemd services, containers, and sudo can each provide a different environment or deliberately remove variables.

After editing a startup file, start a new matching session. In an appropriate interactive shell, you can source a file to test it, but sourcing the wrong file can apply settings to an unsuitable shell context.

Where environment settings may be initialized

Safe inspection and debugging workflow

1. Record the relevant values in the session where the problem occurs: USER, HOME, PWD, SHELL, TERM, LANG, and PATH.
2. Compare the output with a new terminal, an SSH login, or the process that behaves differently. Differences are evidence about where initialization diverges.
3. Use command -v name to identify the command selected through PATH, and type -a name to list shell-known candidates.
4. Run a suspected executable by absolute path. This separates a PATH lookup problem from a failure inside the program.
5. Where permissions allow, inspect a process environment through a proc filesystem entry:

tr '\0' '\n' < /proc/PID/environ

Access to another user's process environment may be restricted. Treat your own environment and any process output as sensitive because it can expose credentials, tokens, proxy authentication, and other private data.

Useful diagnostic patterns

• Command unavailable: inspect PATH, run command -v and type -a, check whether the changed PATH was exported, and compare interactive and noninteractive environments.
• Wrong executable: use type -a, inspect PATH order, and refresh the shell's command lookup cache when required by that shell.
• Incorrect text, sorting, or messages: run locale, inspect LANG and LC_* variables, and choose a locale supported by the system. Remember that LC_ALL can temporarily override expected settings.
• Broken terminal display: inspect TERM and open a fresh terminal rather than guessing a replacement value. Capability definitions must match the actual terminal.
• Remote graphical application cannot open a display: check DISPLAY, confirm that X11 forwarding was requested and permitted, and verify display authentication. Do not set DISPLAY arbitrarily.
• Preferred editor ignored: check whether VISUAL takes precedence, whether EDITOR is exported, and whether the application has its own editor setting.
• Prompt or history changes fail in a new shell: identify the active shell and whether it is login or interactive, then place PS1 or HISTFILESIZE in the appropriate shell-specific startup file.

Key exam-relevant notes

• Shell variables are not inherited unless exported.
• PATH is searched from left to right, so directory order changes command selection.
• SHELL names the configured login shell; it does not always identify the current command interpreter.
• PS1 and HISTFILESIZE are primarily shell settings, especially in Bash, rather than universal application environment variables.
• LANG is a default locale; LC_ALL and category-specific LC_* variables can override it.
• TZ is commonly a process or session override, not a replacement for system-wide time-zone configuration.
• TERM describes terminal capabilities and should match the actual terminal.
• DISPLAY is for X11. Wayland sessions may use WAYLAND_DISPLAY and XDG_RUNTIME_DIR as well.
• Environment values vary by how a process was started. Never assume a cron job, service, SSH command, container, and terminal have the same environment.

For shell fundamentals and initialization context, continue with Linux and Bourne Again Shell Bash.