In Unix, the environment isn't merely the sandbox you play in; it's an integral part of the Unix clockwork. Furthermore, different Unix versions, even different Unix shells on the same system, can treat the environment differently. It's important for administrators to understand the environment in depth, as intuition is often misleading.

Making Things Visible
In the last column, we mentioned the "env" command as a way to see a visible manifestation of the environment. Another way is to use the "set" command without any arguments:

$ set
PATH=/bin:/sbin:/usr/local/bin
MAIL=/var/mail/james
LOGNAME=james
SHELL=/bin/ksh
HOME=/home/james
TERM=vt100
TZ=US/Eastern
etc.

The "set" command is superior for this purpose, since it's built into the shell itself, whereas the "env" command is a separate program. If things become completely fouled up, you may not be able to find or run the "env" program, but "set" should still be available. As its name implies, "set" is also used to assign values to variables. Windows also has a "set" command:

C:\>set
COMPUTERNAME=TITANIC
HOMEDRIVE=C:
HOMEPATH=\
LOGONSERVER=\\TITANIC
USERNAME=james
etc.

The environment, then, is the set of variables pertaining to me. This is information—my user ID, where to look for files and applications, what my command prompt looks like—that's kept on hand by a process. In this case, the process is the command interpreter, or shell, that I'm currently running. The manual page for the Bourne shell (the /bin/sh program) puts it succinctly: the environment is "a list of name-value pairs." This information is obviously stored somewhere. To understand where, it's necessary to talk a bit about processes.

Processes
Among an operating system kernel's primary functions is process management: arbitrating between processes as they contend for resources. But what exactly is a process? The Unix System Administration Handbook describes things well (as always):

"A process is the abstraction used by Unix to represent a running program. It's the object through which a program's use of memory, processor time, and I/O resources can be managed and monitored… A process consists of an address space and a set of data structures inside the kernel."

So, when you run a program, the kernel allocates a chunk of memory (the "address space"), processor time, and I/O bandwidth to the program, and calls the result a "process" for convenience. A process is an instance of a running program. Although there may be several copies of the same program running, each is a unique process.

As it turns out, the set of variables we call "the environment" resides in the memory allocated to the process. How this happens is of some interest. A new process is created as follows:

1) A process makes a request to run a new program. This process is the parent process.

2) The parent process copies itself using the fork system call, creating a new child process with its own memory, CPU, and other allocated resources. This is called "forking" a new process.

3) The child process runs the requested program using the exec system call.

This sequence of events relates to the user environment in two ways. First, a child process inherits the environment of its parent. This is possible because it is actually a copy of the parent process, created by fork. In fact, if we look at the manual page for fork, it tells us exactly what gets inherited (list abbreviated for brevity, but note that the environment is not the only thing inherited by the child process):

• real user ID, real group ID, effective user ID, effective group ID
• environment
• open file descriptors
• current working directory

Secondly, with very few exceptions, a child process cannot affect the environment of its parent. This makes sense, if you consider that while the "fork" system call is a mechanism by which the parent process can affect the child, there's no "reverse fork" mechanism.

This is not the same as saying that a child process can never affect its parent at all, which would make it very difficult for the administrator to kill a runaway process. There are numerous other methods for inter-process communication, such as signals. The "kill" command, for instance, sends a "kill signal," literally, from one process to the process you want destroyed. Only the process's environment, those name-value pairs, is inviolate, unless you perform some scripting trickery.

At this point, you should be wondering how the system ever starts, because how does the first process get forked without a parent (and does it have a navel)? To circumvent this catch-22, a few processes get started directly by the kernel as the system boots. The Unix booting process is characterized by a rampant lack of standardization, even more than Unix itself. Generally, one of the first processes created is the "init" process, also known as process number one (1). As its name implies, the init process is an overseer of sorts, used to initiate and destroy processes. Once "init" is running, new processes get created according to the sequence described above.

Shells: Manipulating the Environment
Unix command interpreters are commonly known as "shells," a word you've probably noticed me throwing about. The term is metaphorical: The "shell" is the "portion of the operating system that interfaces with the outside world, according to the Free On-Line Dictionary of Computing. Shells originally developed as a way for humans to interact with computers in real time -- or for computers to slow themselves down to human pace, depending on perspective. There's probably a decent history of the religious wars provoked by Unix command shell development waiting to be written.

However, for system administration purposes, shells are probably the most frequently used interface to Unix (other possible interfaces would include C code, assembly language, and so on), and it will behoove you to avoid zealotry and learn several. If you spend a lot of time in the older Unix shells, you may find them a little clunky. Vendors frequently ship outdated shell versions, to boot. As an administrator, you may have users who want to use any or all known shells, so passing familiarity with at least the ancestral shells is desirable. Nearly every shell you're likely to want to use derives in some way from these three:

The Bourne-again shell (/bin/bash), a powerful shell from the Free Software Foundation that combines C and Korn shell features, is also extremely popular. If you only have time to learn only one shell, learn the Bourne shell, as any other Unix shell is likely to be Bourne-compatible. You'll be able to maneuver anywhere without too much trouble with Bourne under your belt -- kind of like learning to driving a stickshift.

Startup Files
Clearly, the environment doesn't persist when the computer is turned off, since random-access memory (RAM) requires flowing current in order to store information. So your environment has to be regenerated when the computer is turned back on and you log in. This means that the components of the environment are stored somewhere physically, and get read into memory when a process starts.

Besides obtaining variables from the fork system call, each shell process reads information from several startup files. The names of the files are embedded in the shell programs themselves, and normally can't be overridden unless you recompile the shell program itself from its source code.

These files are the equivalent of the various .INI, .DAT, and .BAT files used to generate a user's environment in Windows, but are most similar to .BAT files because they're interpreted. Unix startup files are actually scripts that get executed, just as the CMD.EXE program is used to run a .BAT file on Windows.

Note that some of the names are prefixed with a dot ( . ), meaning that they're hidden files, and won't show up in a normal file listing. Use the "ls -a" command to reveal them. The list of files above may not be complete or accurate for all systems. Also, some files only get read the first time you log in, but not on any child shells you start subsequently. This behavior also varies between systems, so I'll only mention it here and leave the particulars as an exercise to the reader.

The first item of interest in the above chart is the dollar sign ( $ ). This is an example of variable expansion. "HOME," if you'll recall, is one of the name-value pairs I saw when I used the "set" command at the beginning of the column. Shells will replace the name of a variable, if prefixed by a dollar sign, with the value of the variable. So, if I wanted to find out where my home directory was, I could echo the HOME variable's value at the command prompt:

$ echo $HOME
/home/james

For comparison, echoing the word "HOME" by itself simply spits the word "HOME" back at me.

$ echo HOME
HOME

The second item of interest in the above chart is the order and location of startup files. Some of them reside in the /etc directory, which is a protected directory writable only by the root user. Some of them reside in the user's home directory, but the ones in /etc are read first. This means that you can impose certain requirements on your users before relinquishing the reins. However, they can override your customizations by resetting the variable values. You get the first word in; your users get the last. There are some other shells you can use to restrict users even further; the bash shell even has this capability built in if you start it using the name "rbash."

Setting Variables
Shells are actually limited programming environments, replete with "if-then" conditionals, "while" loops, and other programming constructs. Startup files, like .BAT files, are actually scripts, and may contain complex logic. They're most likely to contain relatively simple logic and lots of simple variable assignment statements, though, because excessively long or complex startup files can cause lengthy login times.

Let's suppose I'm an Oracle DBA, and I want to make things easier for myself. Everything Oracle-related resides here:

/opt/local/oracle/app/oracle/product/8.1.6

I certainly don't want to type that in every time I want to root around in the Oracle directory; not when I can set a variable for this purpose. In the below sequence of commands, I set a variable to the value of the Oracle directory, echo the variable's value to ensure that it was set properly, and then list the contents of that directory using the dollar sign syntax to "expand" the variable:

$ ORACLE_HOME=/opt/local/oracle/app/oracle/product/8.1.6
$ echo $ORACLE_HOME
/opt/local/oracle/app/oracle/product/8.1.6
$ ls $ORACLE_HOME
JRE@ jdbc/ owm/ etc.

The last "ls" command is equivalent to the below, but much easier to type:

$ ls /opt/local/oracle/app/oracle/product/8.1.6

The power of variable expansion should be immediately obvious. To make sure that the variable remained effective the next time I logged in, I'd want to place that variable assignment statement in one of my startup files, namely the .profile file in my home directory, since the dollar sign ( $ ) prompt tells me I'm using the Bourne or Korn shell -- the C shell uses a percent sign ( % ) as its prompt.

'A little knowledge is a dang'rous thing'
- Alexander Pope, An Essay on Criticism

That concludes the four-part introductory Unix-for-NT-administrators series we had planned. Thanks to everyone who's been putting up with what I freely admit is an idiosyncratic and limited overview; Unix is simply too broad a topic to cover in 10,000 words or less. Nevertheless, I hope this series has provided some useful insight and references.

Next time, I'll be talking about some relatively new remote management tools that might be useful to anyone with over two machines to worry about.