environ - user environment
extern char **environ;
environ points to an array of pointers to
strings called the "environment". The last pointer in this array has the
value NULL. (This variable must be declared in the user program, but is
declared in the header file
<unistd.h> if the
_GNU_SOURCE feature test macro is defined.) This array
of strings is made available to the process by the
exec(3) call that started the process. When a child
process is created via fork(2), it inherits a
copy of its parent's environment.
By convention the strings in
environ have the form
value". Common examples
The name of the logged-in user (used by some BSD-derived programs).
The name of the logged-in user (used by some System-V derived programs).
The name of a locale to use for locale categories when not overridden by LC_ALL or more specific environment variables such as LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and LC_TIME (see locale(7) for further details of the LC_* environment variables).
The sequence of directory prefixes that sh(1) and many other programs apply in searching for a file known by an incomplete pathname. The prefixes are separated by ':'. (Similarly one has CDPATH used by some shells to find the target of a change directory command, MANPATH used by man(1) to find manual pages, and so on)
The current working directory. Set by some shells.
The pathname of the user's login shell.
The terminal type for which output is to be prepared.
The user's preferred utility to display text files.
The user's preferred utility to edit text files.
The initial environment of the shell is populated in various ways,
such as definitions from
/etc/environment that are processed by
pam_env(8) for all users at login time (on systems that
employ pam(8)). In addition, various shell
initialization scripts, such as the system-wide
script and per-user initializations script may include commands that add
variables to the shell's environment; see the manual page of your
preferred shell for details.
Bourne-style shells support the syntax
to create an environment variable definition only in the scope of the
process that executes
command. Multiple variable definitions,
separated by white space, may precede
Note that the behavior of many programs and library routines is influenced by the presence or value of certain environment variables. Examples include the following:
LD_LIBRARY_PATH, LD_PRELOAD, and other LD_* variables influence the behavior of the dynamic loader/linker.
POSIXLY_CORRECT makes certain programs and library routines follow the prescriptions of POSIX.
The behavior of malloc(3) is influenced by MALLOC_* variables.
The variable HOSTALIASES gives the name of a file containing aliases to be used with gethostbyname(3).
TERMCAP gives information on how to address a given terminal (or gives the name of a file containing such information).
COLUMNS and LINES tell applications about the window size, possibly overriding the actual size.
PRINTER or LPDEST may specify the desired printer to use. See lpr(1).
The prctl(2) PR_SET_MM_ENV_START and PR_SET_MM_ENV_END operations can be used to control the location of the process's environment.
Clearly there is a security risk here. Many a system command has been tricked into mischief by a user who specified unusual values for IFS or LD_LIBRARY_PATH.
There is also the risk of name space pollution. Programs like
autoconf allow overriding of default utility
names from the environment with similarly named variables in all caps.
Thus one uses CC to select the desired C compiler (and
similarly MAKE, AR,
AS, FC, LD,
LEX, RM, YACC, etc.).
However, in some traditional uses such an environment variable gives
options for the program instead of a pathname. Thus, one has
MORE, LESS, and GZIP.
Such usage is considered mistaken, and to be avoided in new programs.
The authors of
gzip should consider renaming their option to
This page is part of release 5.10 of the Linux
project. A description of the project, information about reporting bugs,
and the latest version of this page, can be found at