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's vi editor, and assigning the ~ tilde character as the home directory in all POSIX shells.
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't seen any substantial improvement since the 1970s.
It would be very helpful if shell job control could address available processors (and become aware of asymmetric big/LITTLE configurations), hold jobs until CPUs become available, and keep a list of failed jobs for retry.
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.
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.)
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 "There are stopped jobs." warning when I attempt to exit a shell/window, which makes cleanup slightly more tedious.)
It will prevent the process from getting SIGHUP when the terminal is closed, but it won't change the pty or stdin/stdout/stderr of the process, so it may still abort if/when I/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/O errors to the terminal.
Also, some terminals (e.g. kitty) will not auto-close when bash exits if there are still processes having the PTY open. Here's a simple example to play around with to see some different possibilities (and check how your shell handles things). NB: It runs "exit" at the end, so run in a fresh terminal window/tab
If you run this in a terminal that doesn't close when your shell exits if any other process still has the pty open, then the tab/window will hang around for 5 seconds and then disappear; /tmp/got-here will exist. If you run in a terminal that does close when your shell exits (e.g. xterm), then /tmp/got-here will never be created and you'll see an IO error message in /tmp/test-stderr
I'm curious to see how many engineers here use shell/*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.
Most platforms have a POSIX implementation, and a place for the POSIX shell (which standardizes job control that originated in Bill Joy's csh).
This includes Microsoft, who was the biggest UNIX vendor of the 80s with their Xenix series that was sold to SCO.
Microsoft Windows NT also implements a POSIX subsystem, which has waxed and waned over the life of Windows. The POSIX shell is quite relevant to modern Windows, and is worthy of study by any serious user.
I think it mostly depends on the particular engineer and the engineering culture of the team/company. I was hanging out in a coffee shop a while back, and some software engineers who looked extremely young happened to sit at a nearby table. I couldn't help but overhear them excitedly sharing their fun terminal/shell customizations with each other.
I don't think a willingness to engage in such things is a prerequisite to being a great software engineer, but it somehow warmed my heart to see that the younger generation could still find joy in such things.
https://en.wikipedia.org/wiki/ADM-3A
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't seen any substantial improvement since the 1970s.
It would be very helpful if shell job control could address available processors (and become aware of asymmetric big/LITTLE configurations), hold jobs until CPUs become available, and keep a list of failed jobs for retry.
The standards will likely never implement this functionality. This is the fault of the Austin Group.