 |  |
| |
Pipes are actually a special case of a more general feature: doing more than one thing at a time. any other commercial operating systems don't have this capability, because of the rigid limits that they tend to impose upon users. Unix, on the other hand, was developed in a research lab and meant for internal use, so it does relatively little to impose limits on the resources available to users on a computer -- as usual, leaning towards uncluttered simplicity rather than overcomplexity.
"Doing more than one thing at a time" means running more than one program at the same time. You do this when you invoke a pipeline; you can also do it by logging on to a Unix system as many times simultaneously as you wish. (If you try that on an IBM VM/CMS system, for example, you get an obnoxious "already logged in" message.)
The shell also lets you run more than one command at a time during a single login session. Normally, when you type a command and hit ENTER, the shell lets the command have control of your terminal until it is done; you can't run further commands until the first one finishes. But if you want to run a command that does not require user input and you want to do other things while the command is running, put an ampersand (&) after the command.
This is called running the command in the background, and a command that runs in this way is called a background job; for contrast, a job run the normal way is called a foreground job. When you start a background job, you get your shell prompt back immediately, enabling you to enter other commands.
The most obvious use for background jobs is programs that can take a long time to run, such as sort or gunzip on large files. For example, assume you just got an enormous compressed file loaded into your directory from magnetic tape. Today, the gzip utility is the de-facto file compression utility. gzip often achieves 50% to 90% compression of its input files. The compressed files have names of the form filename.gz, where filename is the name of the original uncompressed file. Let's say the file is gcc-3.0.1.tar.gz, which is a compressed archive file that contains well over 36 MB of source code files.
Type gunzip gcc-3.0.1.tar.gz &, and the system starts a job in the background that uncompresses the data "in place" and ends up with the file gcc-3.0.1.tar. Right after you type the command, you see a line like this:
[1] 4692
followed by your shell prompt, meaning that you can enter other commands. Those numbers give you ways of referring to your background job; Chapter 8 explains them in detail.
You can check on background jobs with the command jobs. For each background job, jobs prints a line similar to the above but with an indication of the job's status:
[1] + Running gunzip gcc-3.0.1.tar.gz
When the job finishes, you see a message like this right before your shell prompt:
[1] + Done gunzip gcc-3.0.1.tar.gz
The message changes if your background job terminated with an error; again, see Chapter 8 for details.
Jobs you put in the background should not do I/O to your terminal. Just think about it for a moment and you'll understand why.
By definition, a background job doesn't have control over your terminal. Among other things, this means that only the foreground process (or, if none, the shell itself) is "listening" for input from your keyboard. If a background job needs keyboard input, it will often just sit there doing nothing until you do something about it (as described in Chapter 8).
If a background job produces screen output, the output will just appear on your screen. If you are running a job in the foreground that also produces output, the output from the two jobs will be randomly (and often annoyingly) interspersed.
If you want to run a job in the background that expects standard input or produces standard output, the obvious solution is to redirect it so that it comes from or goes to a file. The only exception is that some programs produce small, one-line messages (warnings, "done" messages, etc.); you may not mind if these are interspersed with whatever other output you are seeing at a given time.
For example, the diff utility examines two files, whose names are given as arguments, and prints a summary of their differences on the standard output. If the files are exactly the same, diff is silent. Usually, you invoke diff expecting to see a few lines that are different.
diff, like sort and gzip, can take a long time to run if the input files are very large. Suppose you have two large files called warandpeace.html and warandpeace.html.old. The command diff warandpeace.html.old warandpeace.html reveals that the author decided to change the name "Ivan" to "Aleksandr" throughout the entire file -- i.e., hundreds of differences, resulting in large amounts of output.
If you type diff warandpeace.html.old warandpeace.html &, then the system will spew lots and lots of output at you, which it will be very difficult to stop -- even with the techniques explained in Chapter 7. However, if you type:
diff warandpeace.html.old warandpeace.html > wpdiff &
the differences will be saved in the file wpdiff for you to examine later.
Background jobs can save you a lot of thumb-twiddling time (or can help you diet by eliminating excuses to run to the candy machine). But remember that there is no free lunch; background jobs take resources that become unavailable to you or other users on your system. Just because you're running several jobs at once doesn't mean that they will run faster than they would if run sequentially -- in fact, it's usually worse.
Every job on the system is assigned a priority, a number that tells the operating system how much priority to give the job when it doles out resources (the higher the number, the lower the priority). Foreground commands that you enter from the shell usually have the same, standard priority. But background jobs, by default, have lower priority.[14] You'll find out in Chapter 3 how you can override this priority assignment so that background jobs run at the same priority as foreground jobs.
[14] This feature was borrowed from the C shell; it is not present in most Bourne shells.
If you're on a large multiuser system, running lots of background jobs may eat up more than your fair share of the shared resources, and you should consider whether having your job run as fast as possible is really more important than being a good citizen.
On the other hand, if you have a dedicated workstation with a fast processor and loads of memory and disk, then you probably have cycles to spare and shouldn't worry about it as much. The typical usage pattern on such systems largely obviates the need for background processes anyway: you can just start a job and then open another window and keep working.
Speaking of good citizenship, there is also a shell command that lets you lower the priority of any job: the aptly-named nice. If you type the following, the command will run at a lower priority:
nice command
You can control just how much lower by giving nice a numerical argument; consult the man page for details.[15]
[15] If you are a system administrator logged in as root, you can also use nice to raise a job's priority.
|  | |
| 1.7. Input and Output |  | 1.9. Special Characters and Quoting |
Copyright © 2003 O'Reilly & Associates. All rights reserved.