Environment Variable List: Complete Reference with Commands and Purposes

Ever spent 30 minutes chasing a missing PATH entry because a program couldn’t find its binary?
Environment variables are the small text settings that decide where files live, which editor opens, and how apps run.
This post is a complete reference: the 12 most common variables, cross-OS name differences, commands to view and edit them, and quick notes on when to change them so you can debug setups faster and avoid breaking login shells.

Comprehensive Reference: The Most Common Environment Variables and Their Meanings

Environment variables are named settings that tell your system and apps how to behave. They store things like file paths, user preferences, and system config that programs read at runtime.

Knowing the common ones helps you understand how your OS organizes directories, finds commands, and handles user sessions. These variables exist across all major operating systems, though the names and formats differ between Unix-like systems (Linux, macOS) and Windows. System variables affect everything globally and are available to everyone, while user variables apply only to your current session and can override system settings.

Here are the 12 you’ll run into most often:

• PATH – Colon-separated (Unix) or semicolon-separated (Windows) list of directories where the system looks for executables. Example: PATH=/usr/local/bin:/usr/bin:/bin
• HOME (Unix) / USERPROFILE (Windows) – Your home directory. Example: HOME=/home/alice or USERPROFILE=C:\Users\Alice
• USER / LOGNAME – Current logged-in username. Example: USER=alice
• SHELL – Path to your default command shell. Example: SHELL=/bin/bash
• TEMP / TMP / TMPDIR – Where temporary files go. Example: TMPDIR=/tmp or TEMP=C:\Users\Alice\AppData\Local\Temp
• LANG / LC_ALL – Locale and language settings for date formats, character encoding, translations. Example: LANG=en_US.UTF-8
• PWD – Current working directory path
• EDITOR / VISUAL – Default text editor used by programs like git and cron. Example: EDITOR=vim
• HOSTNAME / COMPUTERNAME – Machine name on the network
• TERM – Terminal emulator type. Example: TERM=xterm-256color
• UID / GID – Numeric user and group IDs (Unix)
• PS1 – Interactive shell prompt string formatting

PATH, TEMP, and SHELL are system variables that define critical infrastructure. HOME, USER, and EDITOR are user variables that customize individual sessions.

OS-Specific Environment Variable Lists for Windows, Linux, and macOS

Each OS uses different variable names and structures, even when they’re doing the same thing. Linux and macOS follow POSIX conventions and share nearly identical variable sets. Windows does its own thing with registry-based environments and unique naming.

Linux uses variables like HOME for user directories and shell settings like HISTSIZE to control how much command history you keep. macOS inherits standard Unix variables and adds some platform-specific entries for graphical sessions, like XDGSESSIONTYPE to identify whether you’re in a terminal, X11, or Wayland session. Windows is built around drive letters and backslashes in paths, with variables like SystemRoot pointing to the Windows installation and APPDATA storing per-application user data.

Windows has several variables with no direct Unix equivalent. ProgramFiles and ProgramFiles(x86) point to default install directories for 64-bit and 32-bit apps. WINDIR duplicates SystemRoot and points to the Windows folder. HOMEDRIVE and HOMEPATH split your home location into drive letter and path components.

PATH works differently across platforms. Unix uses colons to separate directories, Windows uses semicolons. Both prioritize from left to right when searching for executables.

HOSTNAME on Unix matches COMPUTERNAME on Windows. Both identify the machine on a network, but Windows also provides USERDOMAIN to show the Active Directory domain if joined.

Commands to View Any Environment Variable List from the Terminal or Shell

Five core commands let you inspect environment variables on Linux and macOS. printenv shows all exported environment variables or specific ones when you pass variable names as arguments. Running printenv HOME SHELL shows just those two. env does the same job and also launches programs with modified environments. set shows a broader list: all shell variables, environment variables, and shell functions. Output is longer and includes stuff like PS1 that doesn’t get exported to child processes. declare is a Bash built-in that lists declared shell variables and their attributes, useful for checking variable types and read-only status. echo expands and prints a single variable. echo $HOME shows /home/alice.

The difference between printenv/env and set/declare is scope. The first two show only environment variables that child processes inherit. The second pair includes shell-local variables that exist only in your current session and won’t pass to scripts or commands you run.

Filter long lists with grep to find specific variables or patterns. printenv | grep HOME returns all variables containing “HOME” in the name or value. Use printenv | grep -i node for case-insensitive searching. Pipe to less or more for easier scrolling: set | less.

Most useful commands:

• printenv – show all environment variables
• printenv PATH – display the PATH variable value
• env – list all environment variables
• set – show environment variables, shell variables, and functions
• declare – list declared shell variables (Bash)
• echo $HOME – print a single variable’s value
• printenv | grep -E 'HOME|USER' – filter multiple variables by name
• env | less – page through the environment list

Windows uses different commands. In cmd.exe, set lists all variables and echo %VARIABLENAME% prints a specific one: echo %PATH%. PowerShell uses Get-ChildItem Env: to list everything and $env:VARIABLENAME to read individual values: $env:PATH.

Categorized Environment Variable Lists: System, User, Application, and Temporary

System variables define infrastructure settings that apply globally. PATH tells the OS where to find executables. SystemRoot (Windows) and standard filesystem layout variables (Linux/macOS) define core directory structures. ProgramFiles points to default install locations. These get set at the OS level, apply to all users, and rarely change unless you install new software or modify system config files.

User variables customize behavior for individual accounts. HOME or USERPROFILE points to your personal directory. SHELL defines which command interpreter runs when you open a terminal. EDITOR and VISUAL determine which text editor programs like git and cron invoke. USER, LOGNAME, USERNAME, and UID identify who’s logged in. These load from user config files like ~/.bashrc or Windows user registry keys and can differ between accounts on the same machine.

Application and temporary variables serve specialized purposes. JAVAHOME, PYTHONPATH, GOPATH, and NODEENV get set by developers or installers to configure language runtimes and build tools. They’re not part of the base OS but are commonly required for development work. Temporary variables include TMPDIR, TEMP, and TMP, which point to scratch space for short-lived files, plus runtime overrides you set for single commands or sessions without persisting them to disk.

Common examples across categories:

• System: PATH, SystemRoot, ProgramFiles
• User: HOME, USERPROFILE, SHELL, EDITOR
• Application: JAVAHOME, PYTHONPATH, NODEENV
• Temporary: TMPDIR, TEMP, session-specific test variables

Application variables are usually exported so child processes inherit them. When you run a Python script, it checks PYTHONPATH to locate modules. Temporary variables might be shell-local or exported depending on how you set them. Use export VAR=value to make a variable available to commands you run. Skip export if the value only matters in your current shell.

Managing and Editing Your Environment Variable List Safely

Temporary variables last only for your current shell session and disappear when you log out or close the terminal. Create them with export MYVAR=value on Linux/macOS or $env:MYVAR='value' in PowerShell. These work well for testing, overriding defaults during a single task, or experimenting without affecting future sessions. They’re also safer. If you break something, just open a new terminal and the problem’s gone.

Permanent variables persist across logins and reboots because they’re written to config files or the Windows registry. On Linux and macOS, you add export statements to shell startup files. On Windows, you use the System Properties GUI or the setx command to write values into the registry. Permanent changes need more care because typos or syntax errors can break login shells or cause programs to misbehave every time they start.

Linux and macOS load environment variables from a hierarchy of files. System-wide settings live in /etc/environment (simple KEY=value pairs, no shell syntax), /etc/profile (runs for login shells, allows full shell scripting), and /etc/profile.d/*.sh (modular scripts sourced by /etc/profile). User settings go in ~/.bashrc (interactive non-login Bash shells), ~/.bash_profile or ~/.profile (Bash login shells), ~/.zshrc (Zsh interactive shells), or ~/.config/environment.d/*.conf (systemd user sessions, KEY=value format). Many setups have ~/.bash_profile source ~/.bashrc so variables appear in both login and interactive contexts.

Windows persistence works differently. Use the Environment Variables dialog in System Properties to set user or system variables through the GUI. From the command line, setx MYVAR value writes to the user registry. setx MYVAR value /M writes system-wide (needs admin rights). PowerShell profiles ($PROFILE file path) can also initialize variables on startup. Be aware that older Windows versions had a setx bug that truncated PATH at 1024 characters. Back up PATH before modifying it with setx.

File-Specific Behavior and Reloading

Login shells (when you SSH in or open a terminal that requires authentication) load /etc/profile and ~/.bash_profile or ~/.profile. Interactive non-login shells (new terminal tabs, script subshells) load ~/.bashrc. Zsh loads ~/.zshenv for all shells, ~/.zprofile for login, and ~/.zshrc for interactive. After editing a file, run source ~/.bashrc (or whichever file you changed) to apply changes immediately without logging out.

Five common mistakes when editing environment variables:

• Overwriting PATH instead of appending. Use export PATH="$HOME/bin:$PATH", not export PATH="$HOME/bin"
• Adding export syntax to /etc/environment, which doesn’t support it. Use plain KEY=value
• Forgetting quotes around values with spaces. export MYVAR="my value", not export MYVAR=my value
• Editing the wrong file for the shell type. Putting Bash exports in ~/.zshrc or vice versa
• Not sourcing changes and wondering why new terminals don’t see the updated variable

Always test changes in a new terminal session before logging out completely. If a mistake breaks your login, you can often recover from a virtual console (Ctrl+Alt+F2 on many Linux systems) or safe mode.

Troubleshooting Broken or Missing Environment Variables

Missing or incorrect environment variables usually cause “command not found” errors, programs failing to locate config files, or scripts that can’t find dependencies. Check if a variable exists using printenv VARNAME. No output means it’s unset. Compare what you expect with what’s actually set using echo $VARNAME. If a variable is set but empty, echo prints a blank line. If unset, the output is also blank, so use printenv or the Bash test [ -v VARNAME ] to tell the difference.

Path problems are the most common issue. If a command worked before and now returns “command not found,” PATH is probably broken. View it with echo $PATH and verify each directory exists and contains the expected executable. Directories are checked left to right, so if you have duplicate entries or an override in the wrong position, the wrong version of a tool might run. On Unix, PATH entries are separated by colons. On Windows, by semicolons. A missing or misplaced separator breaks the entire list.

Quick troubleshooting actions:

• Use printenv | grep VARNAME to check if the variable is set and what its value is
• Run getconf -a | grep MAX to see system limits on environment size (useful if you hit length restrictions)
• Test xargs --show-limits to check ARG_MAX and environment overhead limits
• Reload your shell config with source ~/.bashrc after editing, then verify with echo $VARNAME
• Check file syntax. /etc/environment uses KEY=value, no export. Shell files need export KEY=value
• Look for typos in variable names. They’re case-sensitive, and Path isn’t the same as PATH

Theoretical maximum variable length is around 32,760 characters on most Unix systems, but practical limits are lower. execve system call limits (check man 2 execve) and shell buffer sizes can cause failures. On Windows, old versions of setx truncated PATH at 1024 characters. Always back up PATH before using setx and verify the result afterward.

If a variable is set in your config file but doesn’t appear in new shells, check which file is actually being sourced. Login shells ignore ~/.bashrc unless ~/.bash_profile explicitly sources it. Non-login shells ignore ~/.bash_profile. Run echo $0 to see if you’re in a login shell (-bash) or not (bash). Permissions also matter. If your config file isn’t readable, the shell skips it silently.

Final Words

in the action, we mapped common variables (PATH, HOME, TMP, USER) with example values, showed OS-specific differences, and gave the quick commands to inspect them.

You got a simple classification—system vs user vs application vs temporary—plus where to persist changes and a short troubleshooting checklist for broken paths or truncated values.

Use this environment variable list as a hands-on reference when you audit or fix configs. Small fixes now save you wasted debugging time later.

FAQ

Q: How do I list all environment variables or see my environment variables?

A: To list all environment variables, run printenv or env on Linux/macOS, use set in Windows cmd, or Get-ChildItem Env: / $env:VAR in PowerShell. Pipe to grep/find to narrow results.

Q: What are examples of environment variables?

A: Examples of environment variables include PATH, HOME (or USERPROFILE on Windows), TEMP/TMP, USER/USERNAME, SHELL, LANG, and EDITOR. Example values: PATH=/usr/local/bin:/usr/bin:/bin; HOME=/home/username; TEMP=/tmp; USER=username.