23.4. Some Gotchas with Job Control

1. If you're using Bourne-type shells, you have to watch out for putting a series of commands separated by semicolons (Section 28.16) into the background. These shells put only the last command on the line into the background, but wait for the first.

   An easy way to test this is with the following command line, which waits for 15 seconds, then does an ls:

   $ sleep 15; ls &

   In Bourne-like shells, you won't get your prompt back until the sleep (Section 25.9) command has finished.

   With Bourne-type shells, the proper way to put a series of commands into the background is to group them with parentheses:

   ( ) Section 43.7

   $ (sleep 15; ls)&

   This may strike you as a defect, but in fact, it's a sign of the greater precision of Bourne shell syntax, which makes it somewhat exasperating for interactive use but much better for programming.

2. It doesn't make any sense to run an interactive program such as an editor in the background. For example, if you type this from the C shell:

   % vi &
   [1] 3071

   you'll get a message like the following:

   [1]  + Stopped (tty output) vi

   vi can be active only in the foreground. However, it does make sense to have vi stopped (Section 23.1) in the background.

   If you are running vi or any other interactive program, you can quickly get back to the shell by typing CTRL-z to stop the program. The shell will take control of your terminal and print another shell prompt.

   Stopping vi (Section 23.6) is more efficient than using its shell escape mechanism (Section 17.21), since it lets you go back to your original shell rather than starting a new one. Simply type fg to get back to where you were in editing.

3. We have had the misfortune to share a system with new users who were overenthusiastic in their use of background processes, rather like the man who loved loving so much he sought many lovers. Because each background process is competing for the same resources, running many of them can be a drain on the system, and everything takes longer for everyone. We knew people who thought that if they ran three troff processes at once, they'd get their three files formatted faster than if they did them one after another. Boy, were they mistaken.[68]

   [68]In the old days, Unix systems gave all processes to a single CPU. Modern Unix systems can have multiple CPUs. On these systems, you may be able to do several jobs almost as quickly as one.

4. If you use the Bourne shell, any background processes you have running will normally be terminated when you log out. To avoid this, use the nohup (Section 23.10) command.

5. Not all processes are created equal. Unix maintains a queue of processes ordered by priority. Foreground processes, such as a user typing a command at a prompt, often receive higher priority than background processes. However, you may want to run background processes at an even lower priority, by using nice ( Section 26.5). This is a relatively painless way of being kind to other users -- and making your foreground job run faster -- though it will make your background tasks take a little longer.

--TOR and DD

23.3. Using jobs Effectively		23.5. The "Current Job" Isn't Always What You Expect

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