 |  |
| |
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:
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 reused, 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 (Section 50.1), as well as who is allowed to kill the process (Section 24.12) (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 Section 50.2.
The environment contains a list of variable names and associated values. For example, when you type echo $HOME at the shell and it prints out the name of your home directory (Section 1.15), it has told you the contents of the environment variable (Section 35.3) called HOME.
The current working directory (Section 31.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 (Section 31.2), the program will look in the current working directory -- if the PATH variable contains the current directory (Section 35.6 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.
Versions of Unix with job control (Section 23.1) have process groups. A process group is used for distribution of signals (Section 24.10, Section 24.11, Section 24.14). 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 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
|  | |
| 24.2. fork and exec |  | 24.4. Subshells |
Copyright © 2003 O'Reilly & Associates. All rights reserved.