<!-- Note to editors regarding embedded anchors: In order to distinguish between environment variables for Unix, DOS and Windows in incoming links, all anchors for Unix/OSX-variables are prefixed with $, all anchors for DOS/MDOS/GEM/NetWare-variables are framed like %variable%, all anchors for OS/2-variables are prefixed with %, and all anchors for Windows-variables are not prefixed at all. Environment variables are listed as they are stored in the environment, although some systems are case-insensitive in regard to their case. If a variable exists in several case-variants, they should be listed separately (f.e. %COMSPEC% and %ComSpec%) and independent anchors should be created for them as well. (At present there are some parsing problem with links to %BETA%, %FBP_USER%, %DAY%, %DAY_OF_WEEK%, %CD%, %DATE%.) -->
An environment variable is a user-definable value that can affect the way running processes will behave on a computer. Environment variables are part of the environment in which a process runs. For example, a running process can query the value of the TEMP environment variable to discover a suitable location to store temporary files, or the HOME or USERPROFILE variable to find the directory structure owned by the user running the process.
They were introduced in their modern form in 1979 with Version 7 Unix, so are included in all Unix operating system flavors and variants from that point onward including Linux and macOS. From PC DOS 2.0 in 1982, all succeeding Microsoft operating systems, including Microsoft Windows, and OS/2 also have included them as a feature, although with somewhat different syntax, usage and standard variable names.
Design
In all Unix and Unix-like systems, as well as on Windows, each process has its own separate set of environment variables. By default, when a process is created, it inherits a duplicate run-time environment of its parent process, except for explicit changes made by the parent when it creates the child. At the API level, these changes must be done between running <code>fork</code> and <code>exec</code>. Alternatively, from command shells such as bash, a user can change environment variables for a particular command invocation by indirectly invoking it via <code>env</code> or using the <code>ENVIRONMENT_VARIABLE=VALUE <command></code> notation. A running program can access the values of environment variables for configuration purposes.
Shell scripts and batch files use environment variables to communicate data and preferences to child processes. They can also be used to store temporary values for reference later in a shell script. However, in Unix, non-exported variables are preferred for this as they do not leak outside the process.
In Unix, an environment variable that is changed in a script or compiled program will only affect that process and possibly child processes. The parent process and any unrelated processes will not be affected. Similarly, changing or removing a variable's value inside a DOS or Windows batch file will change the variable for the duration of <code>COMMAND.COM</code>or <code>CMD.EXE</code>'s existence, respectively.
In Unix, the environment variables are normally initialized during system startup by the system init startup scripts, and hence inherited by all other processes in the system. Users can, and often do, augment them in the profile script for the command shell they are using. In Microsoft Windows, each environment variable's default value is stored in the Windows Registry or set in the <code>AUTOEXEC.BAT</code> file.
On Unix, a setuid program is given an environment chosen by its caller, but it runs with different authority from its caller. The dynamic linker will usually load code from locations specified by the environment variables <code>$LD_LIBRARY_PATH</code> and <code>$LD_PRELOAD</code> and run it with the process's authority. If a setuid program did this, it would be insecure, because its caller could get it to run arbitrary code and hence misuse its authority. For this reason, libc unsets these environment variables at startup in a setuid process. setuid programs usually unset unknown environment variables and check others or set them to reasonable values.
In general, the collection of environment variables function as an associative array where both the keys and values are strings. The interpretation of characters in either string differs among systems. When data structures such as lists need to be represented, it is common to use a colon (common on Unix and Unix-like) or semicolon-delineated (common on Windows and DOS) list.
Syntax
The variables can be used both in scripts and on the command line. They are usually referenced by putting special symbols in front of or around the variable name.
By convention, names of environment variables are normally expressed in all capital letters. This helps keep environment variables distinctly different from other variables and identifiers used in programming codes. Nevertheless, note that case sensitivity in environment variable names differs between operating systems. That is, Unix-like operating systems are case-sensitive with respect to environment variable names, while DOS, OS/2, and Windows are not case-sensitive.
Unix
In most Unix and Unix-like command-line shells, an environment variable's value is retrieved by placing a <code>$</code> sign before the variable's name. If necessary, the name can also be surrounded by braces.
To display the user home directory, the user may type:
<syntaxhighlight lang="bash">
echo $HOME
</syntaxhighlight>
In Unix and Unix-like systems, the names of environment variables are case-sensitive.
The command <code>env</code> displays all environment variables and their values. The command <code>printenv</code> can also be used to print a single variable by giving that variable name as the sole argument to the command.
DOS, OS/2 and Windows
In DOS, OS/2 and Windows command-line interpreters such as <code>COMMAND.COM</code> and <code>CMD.EXE</code>, an environment variable is retrieved by placing a <code>%</code> sign before and after it.
In DOS, OS/2 and Windows command-line interpreters as well as their API, upper or lower case is not distinguished for environment variable names.
The environment variable named <code>HOMEDRIVE</code> contains the drive letter (plus its trailing <code>:</code> colon) of the user's home directory, whilst <code>HOMEPATH</code> contains the full path of the user's home directory within that drive.
So to see the home drive and path, the user may type this:
<syntaxhighlight lang="batch">
ECHO %HOMEDRIVE%%HOMEPATH%
</syntaxhighlight>
The command <code>SET</code> (with no arguments) displays all environment variables and their values. In Windows NT and later <code>set</code> can also be used to print all variables whose name begins with a given prefix by giving the prefix as the sole argument to the command.
In Windows PowerShell, the user may type the following:
<syntaxhighlight lang="powershell">
"$Env:HomeDrive$Env:HomePath"
</syntaxhighlight>
or one of the following redundant equivalents:
<syntaxhighlight lang="powershell">
Write-Output "$Env:HomeDrive$Env:HomePath"
echo "$Env:HomeDrive$Env:HomePath"
write "$Env:HomeDrive$Env:HomePath"
return "$Env:HomeDrive$Env:HomePath"
Write-Host "$Env:HomeDrive$Env:HomePath"
</syntaxhighlight>
In PowerShell, upper or lower case is not distinguished for environment variable names.
The following command displays all environment variables and their values:
<syntaxhighlight lang="powershell">
Get-ChildItem env:
</syntaxhighlight>
Assignment: Unix
The commands <code>env</code> and <code>set</code> can be used to set environment variables and are often incorporated directly into the shell.
The following commands can also be used, but are often dependent on a certain shell.
VARIABLE=value # (there must be no spaces around the equals sign)
export VARIABLE # for Bourne and related shells
export VARIABLE=value # for ksh, bash, and related shells
setenv VARIABLE value # for csh and related shells
A few simple principles govern how environment variables achieve their effect.
Environment variables are local to the process in which they were set. If two shell processes are spawned and the value of an environment variable is changed in one, that change will not be seen by the other.
When a child process is created, it inherits all the environment variables and their values from the parent process. Usually, when a program calls another program, it first creates a child process by forking, then the child adjusts the environment as needed and lastly the child replaces itself with the program to be called. This procedure gives the calling program control over the environment of the called program.
In Unix shells, variables may be assigned without the <code>export</code> keyword. Variables defined in this way are displayed by the <code>set</code> command, but are not true environment variables, as they are stored only by the shell and are unknown to all other processes. The <code>printenv</code> command will not display them, and child processes do not inherit them.
VARIABLE=value
The prefix syntax exports a "true" environment variable to a child process without affecting the current process:
<syntaxhighlight lang="php">
putenv("VARIABLE_NAME"="VALUE");
</syntaxhighlight>
Examples
Examples of environment variables include:
- <code>PATH</code>: a list of directory paths. When the user types a command without providing the full path, this list is checked to see whether it contains a path that leads to the command.
- <code>HOME</code> (Unix-like) and <code>USERPROFILE</code> (Microsoft Windows): indicate where a user's home directory is located in the file system.
- <code>HOME/{.AppName}</code> (Unix-like) and <code>APPDATA\{DeveloperName\AppName}</code> (Microsoft Windows): for storing application settings. Many applications incorrectly use <code>USERPROFILE</code> for application settings in Windows: <code>USERPROFILE</code> should only be used in dialogs that allow user to choose between paths like <code>Documents/Pictures/Downloads/Music</code>; for programmatic purposes, <code>APPDATA</code> (for roaming application settings shared across multiple devices), <code>LOCALAPPDATA</code> (for local application settings) or <code>PROGRAMDATA</code> (for application settings shared between multiple OS users) should be used.
;<code>%APPDATA%</code><!-- all-uppercase at least under XP -->: Contains the full path to the Application Data directory of the logged-in user. Does not work on Windows NT 4.0 SP6 UK.
;<code>%LOCALAPPDATA%</code>: This variable is the local data files of Applications. Its uses include storing of desktop themes, Windows error reporting, caching and profiles of web browsers.
;<code>%ComSpec%</code><!-- mixed case for CMD under XP -->/<code>%COMSPEC%</code>:The <code>%ComSpec%</code> variable contains the full path to the command processor; on the Windows NT family of operating systems, this is cmd.exe, while on Windows 9x, <code>%COMSPEC%</code> is COMMAND.COM.
;<code>%OS%</code>:The <code>%OS%</code> variable contains a symbolic name of the operating system family to distinguish between differing feature sets in batchjobs. It resembles an identically named environment variable <code>%OS%</code> found in all DOS-related operating systems of Digital Research-origin like Concurrent DOS, Multiuser DOS, REAL/32, DOS Plus, DR DOS, Novell DOS and OpenDOS. <code>%OS%</code> always holds the string "<code>Windows_NT</code>" on the Windows NT family.).
;<code>%CommonProgramFiles%</code>, <code>%CommonProgramFiles(x86)%</code>, <code>%CommonProgramW6432%</code>: This variable points to the Common Files subdirectory of the Program Files directory. The default on English-language systems is "<code>C:\Program Files\Common Files</code>". In 64-bit editions of Windows (XP, 2003, Vista), there are also <code>%ProgramFiles(x86)%</code>, which defaults to "<code>C:\Program Files (x86)</code>", and <code>%ProgramW6432%</code>, which defaults to "<code>C:\Program Files</code>". The <code>%ProgramFiles%</code> itself depends on whether the process requesting the environment variable is itself 32-bit or 64-bit (this is caused by Windows-on-Windows 64-bit redirection).
;<code>%OneDrive%</code>: The <code>%OneDrive%</code> variable is a special system-wide environment variable found on Windows NT and its derivatives. Its value is the path of where (if installed and setup) the Onedrive directory is located. The value of <code>%OneDrive%</code> is in most cases "<code>C:\Users\{Username}\OneDrive\</code>".
;<code>%SystemDrive%</code>: The <code>%SystemDrive%</code> variable is a special system-wide environment variable found on Windows NT and its derivatives. Its value is the drive upon which the system directory was placed. The value of <code>%SystemDrive%</code> is in most cases "<code>C:</code>".
;<code>%SystemRoot%</code>:The <code>%SystemRoot%</code> variable is a special system-wide environment variable found on the Windows NT family of operating systems. Its value is the location of the system directory, including the drive and path. The drive is the same as <code>%SystemDrive%</code> and the default path on a clean installation depends upon the version of the operating system. By default:
:* Windows XP and newer versions use "<code>\WINDOWS</code>".
:* Windows 2000, NT 4.0 and NT 3.1 use "<code>\WINNT</code>".
:* Windows NT 3.5 and NT 3.51 uses "<code>\WINNT35</code>".
:* Windows NT 4.0 Terminal Server uses "<code>\WTSRV</code>".
;<code>%windir%</code><!-- all-lowercase at least under Windows 95–98/98SE and Windows XP -->:This variable points to the Windows directory. (On the Windows NT family of operating systems, it is identical to the <code>%SystemRoot%</code> variable). Windows 95–98 and Windows ME are, by default, installed in "<code>C:\Windows</code>". For other versions of Windows, see the <code>%SystemRoot%</code> entry above.
User management variables store information related to resources and settings owned by various user profiles within the system. As a general rule, these variables do not refer to critical system resources or locations that are necessary for the OS to run.
;<code>%ALLUSERSPROFILE%</code><!-- all-uppercase at least under XP --> (<code>%PROGRAMDATA%</code> since Windows Vista): This variable expands to the full path to the All Users profile directory. This profile contains resources and settings that are used by all system accounts. Shortcut links copied to the All Users\' Start menu or Desktop directories will appear in every user's Start menu or Desktop, respectively.
;<code>%USERDOMAIN%</code><!-- all-uppercase at least under XP -->: The name of the Workgroup or Windows Domain to which the current user belongs. The related variable, <code>%LOGONSERVER%</code>, holds the hostname of the server that authenticated the current user's login credentials (name and password). For home PCs and PCs in a workgroup, the authenticating server is usually the PC itself. For PCs in a Windows domain, the authenticating server is a domain controller (a primary domain controller, or PDC, in Windows NT 4-based domains).
;<code>%USERPROFILE%</code><!-- all-uppercase at least under XP -->: A special system-wide environment variable found on Windows NT and its derivatives. Its value is the location of the current user's profile directory, in which is found that user's HKCU registry hive (<code>NTUSER</code>). Users can also use the <code>%USERNAME%</code> variable to determine the active users login identification.
Optional System variables are not explicitly specified by default but can be used to modify the default behavior of certain built-in console commands. These variables also do not need to be explicitly specified as command line arguments.
Default values
The following tables shows typical default values of certain environment variables under English versions of Windows as they can be retrieved under <code>CMD</code>.
(Some of these variables are also defined when running <code>COMMAND.COM</code> under Windows, but differ in certain important details: Under <code>COMMAND.COM</code>, the names of environment variable are always uppercased. Some, but not all variables contain short 8.3 rather than long file names. While some variables present in the <code>CMD</code> environment are missing, there are also some variables specific to the <code>COMMAND</code> environment.)
{| class="wikitable"
|-
! Variable
! Locale specific
! Windows XP (CMD)
! Windows Vista and later (CMD)
|-
|
References
Further reading
External links
- User Environment Variables
- fix setx.exe not found bug
