An environment variable is a user-definable value that can affect the way running processes will behave on a computer.
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.
In all Unix and Unix-like systems, as well as on Windows, each process has its own separate set of environment variables.
Shell scripts and batch files use environment variables to communicate data and preferences to child processes.
The dynamic linker will usually load code from locations specified by the environment variables $LD_LIBRARY_PATH and $LD_PRELOAD and run it with the process's authority.
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.
In DOS, OS/2 and Windows command-line interpreters such as COMMAND.COM and CMD.EXE, an environment variable is retrieved by placing a % 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.
So to see the home drive and path, the user may type this: The command SET (with no arguments) displays all environment variables and their values.
unset is a builtin command implemented by both the Bourne shell family (sh, ksh, bash, etc.)
In CMD.EXE, it is possible to assign local variables that will not be global using the SETLOCAL command and ENDLOCAL to restore the environment.
In PowerShell, the assignment follows a syntax similar to Unix: Examples of environment variables include:
Under DOS, the master environment is provided by the primary command processor, which inherits the pre-environment defined in CONFIG.SYS when first loaded.
Local environment segments inherited to child processes are typically reduced down to the size of the contents they hold.
Some command-line processors (like 4DOS) allow to define a minimum amount of free environment space that will be available when launching secondary shells.
[10] While the content of environment variables remains unchanged upon storage, their names (without the "%") are always converted to uppercase, with the exception of pre-environment variables defined via the CONFIG.SYS directive SET under DR DOS 6.0 and higher[11][12] (and only with SWITCHES=/L (for "allow lowercase names") under DR-DOS 7.02 and higher).
[10][13] In principle, MS-DOS 7.0 and higher also supports lowercase variable names (%windir%), but provides no means for the user to define them.
[18] These environment variables refer to locations of critical operating system resources, and as such generally are not user-dependent.
As a general rule, these variables do not refer to critical system resources or locations that are necessary for the OS to run.
The following tables shows typical default values of certain environment variables under English versions of Windows as they can be retrieved under CMD.
Some command-line processors (like DR-DOS COMMAND.COM,[21] Multiuser DOS MDOS.COM/TMP.EXE (Terminal Message Process), JP Software 4DOS, 4OS2, 4NT, Take Command and Windows cmd.exe) support a type of pseudo-environment variables named system information variables (Novell / Caldera terminology)[21] or internal variables (JP Software terminology),[10] which can be used to retrieve various possibly dynamic, but read-only information about the running system in batch jobs.
Unix-like shells have similar dynamically generated variables, bash's $RANDOM being a well-known example.