[Chapter 6] Shell and Environment Variables
Author: Jerry Peek, Tim O'Reilly & Mike Loukides
Date: 1998-10-23T15:37:54Z

#

| Chapter 6 |

# 6. Shell and Environment Variables

Contents:
What Environment Variables Are Good For
Parent-Child Relationships
Predefined Environment Variables
The PATH Environment Variable
PATH and path
The TZ Environment Variable
What Time Is It in Japan?
Shell Variables
Special C Shell Variables
Running a Command with a Temporarily Different Environment

## 6.1 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.

What kinds of information? Well, to start with, a lot of programs (particularly editors) need to know what kind of terminal you're using. The shell needs to know where any commands you want to use are likely to be found. Lots of UNIX programs (like mail programs) include a command to start an editor as a subprocess; they like to know your favorite editor. And so on.

Of course, one could always write programs that made you put all this information on the command line. For example, you might have to type commands like:

>     % mail -editor vi -term aardvark48 -favoritecolor blue_no_red

But your favorite editor probably doesn't change every day. (Nor will your favorite color.) The terminal you use may change frequently, but it certainly won't change from the time you log in until the time you log out. And you certainly wouldn't want to type something like this whenever you want to send mail.

Rather than forcing you to type this information with every command, UNIX uses environment variables to store information that you'd rather not worry about. For example, the TERM (5.10) 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 (6.4) 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 (4.2), and you'll need to tell the shell how to find them (8.7).

Warning! | Environment variables are managed by your shell. The difference between environment variables and regular shell variables (6.8) 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 (38.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.

You can set environment variables with a command like this:

    ;
    % setenv NAME value   C shell
    $ NAME=value; export NAME   Bourne or Korn shell

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" (6.3) 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 that are used by standard UNIX programs all have uppercase names. [I usually make my shell variable names lowercase so it's easy to tell the difference. -JP ]

If you want the C shell to forget that an environment variable ever existed, use the command unsetenv NAME. (Some Bourne shells, but not all, have a similar command: unset NAME.)

printenv env | If you want to list all of your environment variables, use printenv or env. (Both are on the CD-ROM.) The printenv command also lets you ask about a particular variable. Here's a typical report:

>     % printenv EDITOR
>     EDITOR=/usr/local/bin/emacs
>     % printenv
>     HOME=/home/los/mikel
>     SHELL=/bin/csh
>     TERM=sun
>     USER=mikel
>     PATH=/usr/local/bin:/usr/ucb:/bin:/usr/bin:.:/home/los/mikel/bin
>     LOGNAME=mikel

>     PWD=/home/los/mikel/power/articles
>     PRINTER=ps
>     EDITOR=/usr/local/bin/emacs

The set (6.8) command provides a similar listing of shell variables.

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

>     % echo $TERM
>     xterm

- ML

5.12 Initializing the Terminal with tput |  | 6.2 Parent-Child Relationships