Reasons to use your shell's job control

Historically, job control was written by Bill Joy for the csh, while he was working on a new, cheap serial terminal - the Lear-Siegler ADM-3A. This terminal is famous for defining the arrows for Joy&#x27;s vi editor, and assigning the ~ tilde character as the home directory in all POSIX shells.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;ADM-3A" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;ADM-3A</a><p>It is unfortunate that Bill Joy was both the first and last word in job control (even as his csh has been largely abandoned), as this functionality has been copied first into the Korn shell, then into the POSIX shell, and hasn&#x27;t seen any substantial improvement since the 1970s.<p>It would be very helpful if shell job control could address available processors (and become aware of asymmetric big&#x2F;LITTLE configurations), hold jobs until CPUs become available, and keep a list of failed jobs for retry.<p>The standards will likely never implement this functionality. This is the fault of the Austin Group.

I love job control! And as usual, Julia Evans explains it in a clear and straightforward fashion.<p>I would add that as a shortcut, you can just type % (without fg) to foreground the current job, or % and a number to foreground a particular job. (In Bash, anyway.)<p>I use tmux, but I often use job control as an extra dimension, having several jobs in any given tmux window. (Yes, this leads to the inevitable &quot;There are stopped jobs.&quot; warning when I attempt to exit a shell&#x2F;window, which makes cleanup slightly more tedious.)

One nitpick on disown:<p>It <i>will</i> prevent the process from getting SIGHUP when the terminal is closed, but it won&#x27;t change the pty or stdin&#x2F;stdout&#x2F;stderr of the process, so it may still abort if&#x2F;when I&#x2F;O is performed. Using e.g. nohup solves this problem more completely. If you see programs abort even with disown, they are probably aborting on I&#x2F;O errors to the terminal.<p>Also, some terminals (e.g. kitty) will not auto-close when bash exits if there are still processes having the PTY open. Here&#x27;s a simple example to play around with to see some different possibilities (and check how your shell handles things). <i>NB: It runs &quot;exit&quot; at the end, so run in a fresh terminal window&#x2F;tab</i><p><pre><code> { set -e; rm -f &#x2F;tmp&#x2F;got-here; sleep 5; echo hi; touch &#x2F;tmp&#x2F;got-here; } 2&gt;&#x2F;tmp&#x2F;test-stderr &amp; disown; exit </code></pre> If you run this in a terminal that doesn&#x27;t close when your shell exits if any other process still has the pty open, then the tab&#x2F;window will hang around for 5 seconds and then disappear; &#x2F;tmp&#x2F;got-here will exist. If you run in a terminal that <i>does</i> close when your shell exits (e.g. xterm), then &#x2F;tmp&#x2F;got-here will never be created and you&#x27;ll see an IO error message in &#x2F;tmp&#x2F;test-stderr

I&#x27;m curious to see how many engineers here use shell&#x2F;*nix tooling on a day to day basis. My experience has been that newer engineers have no experience nor desire to learn any of it, whereas it was basically required when I was coming up.

The usefulness of job control to me is why I can’t stand to use PowerShell and a few other “modern” fancy shells for command line work.

If a program is not responding to ctrl-c, sometimes ctrl-\ (which sends sigquit instead of sigint) can kill it.