Exercise 2: A Background Job That Wants Input — Possible Solution
===================================================================

  $ read -p "Name? " name &
  [1] 51301
  $ jobs
  [1]+  Stopped (tty input)     read -p "Name? " name

Why: a background job isn't allowed to read from the terminal, because
the foreground (here, your shell prompt) owns the keyboard. When `read`
tries to read, it is sent the SIGTTIN signal, which stops it. Bash
shows the reason, "tty input", in the jobs list.

To finish it, bring it to the foreground:

  $ fg
  read -p "Name? " name
  Philip

A subtle extra: because the job ran in the background, bash ran it in
a separate subshell. After it finishes, `echo $name` in your shell
prints nothing — the variable was set in the subshell, not in your
shell. Built-in commands like `read` are rarely worth running in the
background for that reason.

WHY THIS WORKS AS AN ANSWER
------------------------------
It connects the "Stopped (tty input)" state to SIGTTIN, shows how to
recover, and notes a real surprise about background subshells.