38.3 Managing Processes: Overall Concepts

As you know, when you log into your UNIX account and start typing, you're talking to the shell ( 8.1 ) . 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 user ID (UID) tells who the process belongs to. This determines what files and directories the process is allowed to read from or write to, ( 22.1 ) as well as who is allowed to kill the process ( 38.10 ) (tell it to stop running).

• 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 echo $HOME at the shell and it prints out the name of your home directory ( 1.20 ) , it has told you the contents of the environment variable ( 6.1 ) called HOME .

• The current working directory ( 14.3 ) 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 pathname ( 14.2 ) -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 job control ( 12.8 ) have process groups . A process group is used for distribution of signals ( 38.8 , 38.9 , 38.12 ) . 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 more .login to view your .login file, the shell starts up the more ( 25.3 ) 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 ( 1.10 ) 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 X ( 1.31 ) 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 ( 1.26 ) . 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 ( 12.8 ) 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 ( 12.4 ) , 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, other methods are needed . ( 38.8 , 44.23 )

[One more concept that I think is useful: When a process exits, it returns a numeric exit status ( 44.7 ) to its parent process. By convention, a zero status means success; non-zero means some kind of failure. -JP ]

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 ( 45.20 , 45.21 , 45.22 ) .