Background, and the signal that is real

An & at the end of a command backgrounds it. The shell does not wait, the next prompt comes back immediately, and the command's status is not in $? — because $? belongs to the shell, and the shell did not run it in front of you.

$! is the pid of the job you just backgrounded, and wait is how you collect what it did. Without one of those, a backgrounded command's failure is invisible: $? after an & is the status of starting it, which is always zero.

This shell runs a backgrounded command to completion where you wrote it, rather than alongside the next one. A world holding a running coroutine could not be replayed, and replay is what lets a run be graded and stepped back through. $!, the status wait reports and the row in jobs are all true; the overlap is the part that is not simulated, and jobs says Done because the job is done.

Signals are how one process interrupts another, and trap is how a script decides what to do about it. The handler runs between commands rather than in the middle of one, which is why a long-running utility does not stop the instant you press Ctrl-C.

EXIT is the one worth knowing: it fires however the script ends, which makes it the place to remove a temporary file.

One signal here is not a story about signals: SIGPIPE genuinely happens. When head has what it needs it closes the pipe, the next write by whatever was feeding it fails, and the writer is killed. The scheduler raises it because a pipe really has no reader left, not because a rule says to.

That is why an infinite producer terminates, and why a process can end with status 141 — 128 plus 13 — without anybody typing kill.

Open the processes pane after yes | head -2: one row exited 0, and the other says killed by SIGPIPE.