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.
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.
Login name of the account under which this session is logged in (BSD convention).
Login name of the account under which this session is logged in (System V convention).
Home directory of the user running this session.
The number of character-cell columns on the controlling terminal or terminal-emulator window.
The number of character-cell rows on the controlling terminal or terminal-emulator window.
The name of the user's command shell (often used by shellout commands).
The list of directories that the shell searches when looking for executable commands to match a name.
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.
