Background jobs: &, jobs, fg, bg

The shell waits, unless you tell it not to

Normally the shell starts a command, hands it the terminal and waits until it exits before printing the next prompt. That command is the foreground job. Append an ampersand, &, and the shell starts the command and comes straight back to you: the command runs in the background, sharing the screen but not the keyboard. The shell answers with two numbers, [1] 1012: the job number in brackets, which is local to this shell, and the PID, which is system-wide.

~% sleep 300 &
[1] 1012
~% echo $!
1012
~% sleep 400 &
[2] 1015
~% jobs
[1]   Running                    sleep 300
[2]   Running                    sleep 400
~% kill %1
~% jobs
[1]   Terminated                 sleep 300
[2]   Running                    sleep 400

jobs lists the background jobs of *this shell* with their number, state and command line. A job number prefixed with % names the job in other commands: kill %1, fg %2, wait %1. The variable $! holds the PID of the most recent background job, which is what scripts save when they need to signal or wait for it later. Remember from lesson 51: a job is just a process that happens to have been started with &; ps shows it like any other.

Ctrl-Z, fg and bg

Forgot the &? You do not have to kill the command and start over. Press Ctrl-Z and the foreground job is stopped: frozen, still in memory, with STAT T in ps. The shell prints [1]+ Stopped sleep 300 and gives you a prompt. From there, bg resumes the job in the background, as if you had typed & from the start, and fg resumes it in the foreground and makes the shell wait again. Both take %N; with no argument they act on the most recent job, the one jobs marks with +.

Ctrl-C is different: it sends SIGINT to the foreground job and normally kills it (lesson 55 covers signals). Ctrl-Z pauses; Ctrl-C ends. Neither reaches a background job, because the keyboard belongs to the foreground only. That is also why a background job that tries to *read* from the keyboard gets stopped automatically with Stopped (tty input): bring it to the foreground with fg to answer it.

wait

~% sleep 5 &
[1] 1020
~% wait $!
~% echo $?
0
~% (sleep 2; exit 3) &
[1] 1023
~% wait %1; echo "exit status $?"
exit status 3

wait blocks until a background job finishes and then returns *its* exit status, which is how a script can start several slow commands in parallel and collect the results. wait alone waits for every job; wait $! or wait %1 waits for one. In the lab's single shell it is mostly a way to confirm the idea: the shell's own $? after wait is the exit status of the child.