home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  

Unix Power ToolsUnix Power ToolsSearch this book

24.3. Managing Processes: Overall Concepts

As you know, when you log into your Unix account and start typing, you're talking to the shell (Section 27.1). The shell you use may be a variant of the Bourne shell (such as a standard sh, 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 following:

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 Section 24.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 more .login to view your .login file, the shell starts up the more 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 new one. Built-in shell commands (Section 1.9) such as cd don't start a child process.

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 X (Section 1.22) and 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 background. You do this by putting an ampersand (&) character at the end of the command, for example, xterm &. The shell will start the child process and then immediately 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 job control (Section 23.1) 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 start up the editor vi, suspend it (Section 24.6), 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 MS-DOS stores information such as the current directory in a global area that is referenced by all programs. If it is necessary to communicate information from a child back to a parent shell, other methods are needed (Section 24.10, Section 35.29).

One more useful concept: when a process exits, it returns a numeric exit status (Section 35.12) to its parent process. By convention, a zero status means success; nonzero means some kind of failure.

Just as there are ways to modify the environment and the current working directory of the shell, there are also useful ways to manipulate file descriptors (Section 36.16).

-- JIK

Library Navigation Links

Copyright © 2003 O'Reilly & Associates. All rights reserved.