The variable environ points to an array of strings called the
`environment'. (This variable must be declared in the user program, but is
declared in the header file unistd.h in case the header files came from
libc4 or libc5, and in case they came from glibc and _GNU_SOURCE was
defined.) This array of strings is made available to the process by the
exec(3) call that started the process. By convention these strings have
the form ` name=value'. Common examples are:
The name of the logged-in user (used by some BSD-derived
The name of the logged-in user (used by some System-V
A user's login directory, set by login(1) from the
password file passwd(5).
The name of a locale to use for locale categories when not
overridden by LC_ALL or more specific environment variables like
LC_COLLATE, LC_CTYPE, LC_MESSAGES,
LC_MONETARY, LC_NUMERIC, LC_TIME, cf.
The sequence of directory prefixes that sh(1) and
many other programs apply in searching for a file known by an incomplete
path name. 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,
The current working directory. Set by some shells.
The file name 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 user's preferred utility to browse URLs. Sequence of
colon-separated browser commands. See http://www.catb.org/~esr/BROWSER/
Further names may be placed in the environment by the export command and
`name=value' in sh(1), or by the setenv command if you use
csh(1). Arguments may also be placed in the environment at the point of
an exec(3). A C program can manipulate its environment using the
functions getenv(3), putenv(3), setenv(3), and
Note that the behaviour of many programs and library routines is influenced by
the presence or value of certain environment variables. A random collection:
The variables LANG, LANGUAGE, NLSPATH, LOCPATH,
LC_ALL, LC_MESSAGES, etc. influence locale handling, cf.
TMPDIR influences the path prefix of names created by tmpnam(3)
and other routines, the temporary directory used by sort(1) and other
LD_LIBRARY_PATH, LD_PRELOAD and other LD_* variables influence the
behaviour of the dynamic loader/linker.
POSIXLY_CORRECT makes certain programs and library routines follow the
prescriptions of POSIX.
The behaviour 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).
TZ and TZDIR give time zone information used by tzset(3)
and through that by functions like ctime(), localtime(),
mktime(), strftime(). See also tzselect(1).
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
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
There is also the risk of name space pollution. Programs like make and
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