|< Day Day Up >|
3.5. Customization and Subprocesses
Some of the
Now for the answer, which (like many UNIX concepts) is
Which things are known depends on whether the subprocess in question is a bash program (see Chapter 4) or an interactive shell. If the subprocess is a bash program, then it's possible to propagate nearly every type of thing we've seen in this chapteroptions and variablesplus a few we'll see later.
3.5.1. Environment Variables
It should be clear why these and other variables need to be known by subprocesses. For example, text editors like
need to know what kind of terminal you are using; the environment variable
Any variable can become an environment variable. First it must be defined as usual; then it must be exported with the command: 
can be a list of variable
It is also possible to define variables to be in the environment of a particular subprocess (command) only, by
varname = value command
You can put as many assignments before the command as you want.  For example, assume that you're using the emacs editor. You are having problems getting it to work with your terminal, so you're experimenting with different values of TERM . You can do this most easily by entering commands that look like:
TERM= trythisone emacs filename
emacs will have trythisone defined as its value of TERM , yet the environment variable in your shell will keep whatever value (if any) it had before. This syntax is surprisingly useful, but not very widely used; we won't see it much throughout the remainder of this book.
Nevertheless, environment variables are important. Most .bash_profile files include definitions of environment variables; the sample built-in .bash_profile earlier in this chapter contained six such definitions:
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin SHELL=/bin/bash MANPATH=/usr/man:/usr/X11/man EDITOR=/usr/bin/vi PS1='\h:\w$ ' PS2='> ' export EDITOR
You can find out which variables are environment variables and what their values are by typing export without arguments or by using the -p option to the command.
Some environment variable names have been used by so many applications that they have become standard across many shell environments. These variables are not built into
, although some
Table 3-9. Standard variables
You may well find that some of these already exist in your own environment, most likely set from the system /etc/profile file (see Chapter 10). You can define them yourself in your .bash_profile and export them, as we did earlier.
220.127.116.11 Terminal types
The variable TERM is vitally important for any program that uses your entire screen or window, like a text editor. Such programs include all screen editors (such as vi and emacs ), more , and countless third-party applications.
Because users are spending more and more time within programs, and less and less using the shell itself, it is extremely important that your TERM is set correctly. It's really your system administrator's job to help you do this (or to do it for you), but in case you need to do it yourself, here are a few guidelines.
The value of
must be a short character string with lowercase
Names of terminal description files are the same as that of the terminal being described; sometimes an abbreviation is used. For example, the DEC VT100 has a description in the file
Sometimes your UNIX software will set up
incorrectly; this usually happens for X terminals and PC-based UNIX systems. Therefore, you should check the value of
before going any further. If you find that your UNIX system isn't setting the right value for you (
The best way to find the
valueif you can't find a local guru to do it for youis to guess the
name and search for a file of that
$ cd /usr/lib/terminfo $ ls 7/7*
If you are successful, you will see something like this:
70092 70092A 70092a
In this case, the three names are likely to be synonyms for (links to) the same terminal description, so you could use any one as a value of TERM . In other words, you could put any of these three lines in your .bash_profile :
TERM=70092 TERM=70092A TERM=70092a
If you aren't successful,
will print an error message, and you will have to make another guess and try again. If you find that
contains nothing that resembles your terminal, all is not lost. Consult your terminal's manual to see if the terminal can emulate a more popular model; nowadays the odds for this are
may have several entries that relate to your terminal, for submodels, special modes, etc. If you have a choice of which entry to use as your value of
, we suggest you test each one out with your text editor or any other
The process is much simpler if you are using a windowing system, in which your "terminals" are logical portions of the screen rather than physical devices. In this case, operating system-dependent software was written to control your terminal window(s), so the odds are very good that if it
18.104.22.168 Other common variables
Some programs, such as mail , need to know what type of editor you would like to use. In most cases they will default to a common editor like ed unless you set the EDITOR variable to the path of your favorite editor and export it in your .bash_profile .
Some programs run shells as subprocesses within
You may have noticed that the value of SHELL looks the same as BASH . These two variables serve slightly different purposes. BASH is set to the pathname of the current shell, whether it is an interactive shell or not. SHELL , on the other hand, is set to the name of your login shell, which may be a completely different shell.
COLUMNS and LINES are used by screen-oriented editors like vi . In most cases a default is used if they are undefined, but if you are having display problems with screen-oriented applications then you should check these variables to see if they are correct.
3.5.2. The Environment File
Although environment variables will always be known to subprocesses, the shell must be explicitly told which other variables, options, aliases, and so on, are to be communicated to subprocesses. The way to do this is to put all such definitions into the
's default environment file is the
file that we touched on
Remember, if you take your definitions out of .bash_profile and put them in .bashrc , you will have to have the line source .bashrc at the end of your .bash_profile so that the definitions become available to the login shell.
The idea of the environment file comes from the C shell's
As a general rule, you should put as few definitions as possible in
and as many as possible in your environment file. Because definitions add to rather than take away from an environment, there is little chance that they will cause something in a subprocess not to work properly. (An exception might be name
The only things that really need to be in .bash_profile are environment variables and their exports and commands that aren't definitions but actually run or produce output when you log in. Option and alias definitions should go into the environment file. In fact, there are many bash users who have tiny .bash_profile files, e.g.:
stty stop ^S intr ^C erase ^? date source .bashrc
Although this is a small
|< Day Day Up >|