 |  |
| |
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 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.
You can set environment variables with a command like this:
% setenv NAME value C-type shells $ NAME=value; export NAME all Bourne-type shells $ export NAME=value newer Bourne-type shells
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:
% 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 (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):
% echo $TERM xterm
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.