When a Unix program starts up, the environment accessible to it
includes a set of name to value associations (names and values are
both strings). Some of these are set manually by the user; others are
set by the system at login time, or by your shell or terminal
emulator (if you're running one). Under Unix, environment variables
tend to carry information about file search paths, system defaults,
the current user ID and process number, and other key bits of
information about the runtime einvironment of programs. At a shell
prompt, typing set followed by a newline will list
all currently defined shell variables.
In C and
C++ these values
can be queried with the library function
getenv(3). Perl and Python initialize environment-dictionary
objects at startup. Other languages generally follow one of these two
models.
System Environment Variables
There are a number of well-known environment variables you can
expect to find defined on startup of a program from the Unix
shell. These (especially HOME) will often need to be evaluated
before
you read a local dotfile.
-
USER
-
Login name of the account under which this session is logged in
(BSD convention).
-
LOGNAME
-
Login name of the
account under which this session is logged in (System V
convention).
-
HOME
-
Home directory of the user running this
session.
-
COLUMNS
-
The number of character-cell columns on the controlling
terminal or terminal-emulator window.
-
LINES
-
The number of character-cell rows on the controlling terminal
or terminal-emulator window.
-
SHELL
-
The name of the user's command shell (often used by shellout
commands).
-
PATH
-
The list of directories that the shell searches when looking
for executable commands to match a name.
-
TERM
-
Name of the terminal type of the session console or
terminal emulator window (see the terminfo case study in Chapter6 for background). TERM is special in
that programs to create remote sessions over the network (such as
telnet and ssh)
are expected to pass it through and set it in the remote
session.
(This list is representative, but not exhaustive.)
The HOME variable is especially important,
because many programs use it to find the calling user's dotfiles
(others call some functions in the C runtime library to get the calling
user's home directory).
Note that some or all of these system environment variables may
not
be set when a program is started by some
other method than a shell spawn. In particular, daemon listeners on a
TCP/IP socket often
don't have these variables set — and if they do, the values are
unlikely to be useful.
Finally, note that there is a tradition (exemplified by the
PATH variable) of using a colon as a separator when an
environment variable must contain multiple fields, especially when the
fields can be interpreted as a search path of some sort. Note that
some shells (notably bash and
ksh)
always
interpret
colon-separated fields in an environment variable as filenames, which
means in particular that they expand ~ in these fields to the user's
home directory.
[an error occurred while processing this directive]
