Job control

[magicant]

• Start a foreground job, await it, and come back to the foreground
  • External utility in simple command 4e04f7c
  • Subshell for independent redirections in simple command a38df36
  • Multi-command pipeline b08c118
  • Subshell command fb15dc9
• Add job to job list when foreground job suspends #244
• Start a background job 0189fdf
• Stop if in the background before running each pipeline 1433b62
• Do not redirect the standard input to /dev/null in asynchronous lists 02b34e7
• Do not ignore SIGINT or SIGQUIT in asynchronous lists Ignore SIGINT and SIGQUIT in asynchronous command #247
• Ignore SIGTTIN, SIGTTOU, SIGTSTP (only when interactive) a963c6e ffd5edc
  • Restore SIGTTIN, SIGTTOU, SIGTSTP when starting controlled jobs Internal handlers for SIGINT, SIGTERM and SIGQUIT #253
    • Keep SIGTTIN, SIGTTOU, and SIGTSTP ignored in non-job-controlled subshells spawned from an interactive job-controlling shell Stopper handlers in non-controlled job #258
• Report job status before printing prompt (only when interactive) Report job status on each prompt #407
• Document job control behavior in the manual

---

• System::setpgid 8e8bc23
• System::tcsetpgrp
• Keep an FD to /dev/tty in Env
• Extend Env::start_subshell
  • Subshell in separate process group #243
  • Don't make jobs out of subshells a567529
• Keep the shell process group ID in Env 5f0a3f9
• Consider removing Env::wait_for_subshell_to_finish

---

We must not create a process group for a built-in in a single-command pipeline, so we need to handle single-command and multi-command pipelines separately.

Questions:

• When should the shell move itself back to the foreground?
  • For consistency and stability, the shell should move itself back to the foreground after running each job rather than only before performing I/O.
• Does the parent process need to call setpgid after forking? → Yes, at least for the background job
  • The fg and bg built-ins have to send a SIGCONT to the target job, which must have been created. The parent process has to make sure the child is in its own process group when starting the job.
• Does the parent process need to call tcsetpgrp after forking? → No
  • The shell have to call setpgid and tcsetpgrp to turn a child process into a foreground job. Since the two function cannot be called atomically, the job is in the background between the two calls. The child process has to call tcsetpgrp to bring itself to the foreground before starting its task.
  • The child blocks SIGTSTP until it finishes tcsetpgrp. Therefore, if the child stops, it has called tcsetpgrp, so it won't call tcsetpgrp after it is resumed (either in the foreground or background).
  • When the parent finishes waiting for the child to terminate or stop, the child must have called tcsetpgrp, so it is surely in the foreground.
• The shell should suspend itself if it is in the background when it is manipulating jobs. Exactly when?
  • An interactive shell ignores SIGTTIN, SIGTTOU, and SIGTSTP by default, so it should not rely on automatically sent signals to stop it. Instead, it should "kill" itself or call tcsetpgrp to suspend itself.
  • When the shell starts a foreground job, the shell should be in the foreground.
  • When the shell starts a background job, the shell does not have to be in the foreground.
  • When the shell runs a built-in, the shell should be in the foreground because the (non-special) built-in should behave the same as the corresponding external utility.
  • To sum up, it will suffice for the shell to check the foreground-ness before running each pipeline.
• Implication of suspending a process that is not a direct child of the job-controlling shell #299