35.3. What Environment Variables Are Good For

Many Unix utilities, including the shell, need information about you and what you're doing in order to do a reasonable job.

Rather than forcing you to type this information with every command, Unix uses environment variables to store information you'd rather not worry about. For example, the TERM (Section 5.2) environment variable tells programs what kind of terminal you're using. Any programs that care about your terminal type know (or ought to know) that they can read this variable, find out your terminal type, and act accordingly.

Similarly, the directories that store the commands you want to execute are listed in the PATH (Section 35.6) variable. When you type a command, your shell looks through each directory in your PATH variable to find that command. Presumably, Unix wouldn't need a PATH variable if all commands were located in the same directory, but you'll soon be writing your own commands (if you aren't already), and storing them in your own "private" command directories (Section 7.4), and you'll need to tell the shell how to find them (Section 27.6).

Environment variables are managed by your shell. The difference between environment variables and regular shell variables (Section 35.9) is that a shell variable is local to a particular instance of the shell (such as a shell script), while environment variables are "inherited" by any program you start, including another shell (Section 24.4). That is, the new process gets its own copy of these variables, which it can read, modify, and pass on in turn to its own children. In fact, every Unix process (not just the shell) passes its environment variables to its child processes.

There's nothing particularly special about the NAME; you can create environment variables with any names you want. Of course, these don't necessarily do anything for you; variables like PATH and TERM are important because lots of programs have "agreed" (Section 35.5) that these names are important. But if you want to create an environment variable that holds the name of your lover, that's your business:

% setenv LOVER Judy

If you're so inclined, you could write a program called valentine that reads the LOVER environment variable and generates an appropriate message. If you like short-term relationships or tend to forget names, this might even be convenient!

By convention, the names of environment variables use all uppercase letters. There's nothing to enforce this convention -- if you're making your own names, you can use any capitalization you please. But there's no advantage to violating the convention, either. The environment variables used by standard Unix programs all have uppercase names. Making shell variable names lowercase so it's easy to tell the difference is helpful.

If you want the C shell to forget that an environment variable ever existed, use the command unsetenv NAME. The tcsh understands filename wildcard (Section 1.13)-type expressions -- for instance, unsetenv VAR* would unset all environment variables whose names start with VAR. Most Bourne-type shells, but not all, have a similar command, unset NAME, but it doesn't understand wildcards like the tcsh version. The bash version accepts multiple names as arguments, however, and can also unset functions with the -f option.

Go to http://examples.oreilly.com/upt3 for more information on: printenv, env

If you want to list all of your environment variables, use printenv or env. The printenv command also lets you ask about a particular variable. Here's a typical report:

The set (Section 35.9) command provides a similar listing of shell variables and functions (in newer Bourne-like shells such as bash).

You can also use the echo command to show the value of a particular variable by preceding the variable name with a dollar sign (which tells the shell to substitute the value of the variable):

Or -- and this is particularly useful when you want a shell or environment variable's value interpolated into a line -- you can surround the variable name with curly brackets:

% echo ${TERM}
vt100
% echo ${TERM}-like
vt100-like

-- ML

---

35.2. Everyone Should Learn Some Shell Programming		35.4. Parent-Child Relationships

---

Copyright © 2003 O'Reilly & Associates. All rights reserved.