As you know, when you log into your UNIX account and start typing, you're talking to the . The shell you use may be a variant of the Bourne shell (such as a standard sh, or ksh or the GNU shell bash), or perhaps it is a variant of the C shell, csh (such as, perhaps, the tcsh shell that includes line- and history-editing features). Alternatively, you may be using a somewhat less common shell such as rc.
Your shell is a process, one of many individual programs running at the same time on the machine. Every process has certain pieces of information associated with it, including:
The process ID (PID) is a number assigned to the process when it is started up. Process IDs are unique (that is, they cycle and are eventually re-used, but no two processes have the same process ID at the same time).
The group ID (GID) is similar to the user ID, but tells which group the process belongs to. On some systems, this controls the group assigned to files created by the process. See articles 22.5, 22.13, and 22.2.
The environment contains a list of variables and associated
values. For example, when you type
at the shell and it prints out the name of your
told you the contents of the
The is the directory that is currently the default. When you specify a filename to a program but do not say explicitly where to look for it [with a -JP ], the program will look in the current working directory-if the PATH variable contains the current directory (article 6.4 explains).
File descriptors are a record of which files a process has opened for reading or writing, as well as the current position in each file. Articles 45.20 through 45.23 explain file descriptor use in the Bourne shell.
Versions of UNIX with have process groups. A process group is used for . It's also used to control which process can read from a terminal. A process that has the same process group as the terminal is "in the foreground" and can read from the terminal. Other processes are stopped when they try to read from the terminal.
When you're typing commands at the shell, it is the controlling process of your terminal, meaning that it (the shell) is the process that gets the input you type. See article 38.6.
Normally, when you type a command at the shell prompt, that command runs and
is allowed by the shell to take over the terminal for its lifetime.
For example, if you type
.login to view your .login
file, the shell starts up the
program and then sits around waiting
for it to finish; while more is running, you can type commands to
page through the file and more (not the shell) will see them.
The command you run is called a child or subprocess of the
shell process, which is its parent.
All process information (user ID, group ID, etc.) is inherited by the child
from its parent, except for the process ID, since the child is assigned a
like cd don't start a child process. -JP ]
Although the normal behavior is for the shell to wait until any
command you run has finished before it becomes active again, there are
some situations in which you don't want this to occur. For example,
if you're using a window system such as
want to start up a new xterm window from your shell, you don't
want to type just
xterm, because then your original shell will
wait until the xterm finishes before allowing you to type any more
commands. This would mean that you still have only one shell to work
in, thus defeating the purpose of starting the new xterm.
When you don't want a process to finish before getting back to the
shell, you can run it in the
You do this by putting
an ampersand (
&) character at the end of the command, for example,
&. The shell will start the child process and then
prompt you for another command. Note that in this situation, the
shell retains control of the terminal and the newly created background
process cannot read input. Some shells have additional
features (processes that are running in the background are
often described as background jobs or just jobs) that enable
you to do things such as kill jobs or bring a job from the background
into the foreground so that it becomes the controlling process of
the terminal and you can type input at it.
An important thing to remember is that although process information is inherited by children when they are started, it is impossible for the parent to affect its child's process information (or vice versa) after that point. For example, if you , and then use the cd command in the shell to change directories, vi will still have the old working directory when you bring it back into the foreground. Similarly, if you write a shell script that changes some environment variables, those variables will contain their old values in the shell when the shell script exits. This sometimes confuses MS-DOS users, since information such as the current directory is stored in a global area which is referenced by all programs. If it is necessary to communicate information from a child back to a parent shell,