Orphan background tasks to work around terminals being sensitive to unreaped processes
When a command like long-running-command & exits, the resulting SIGCHLD
is queued in the topic monitor. We do not process this signal immediately
but only after e.g. the next command has finished. Only then do we reap the
child process.
Some terminals, such as Terminal.app, refuse to close when there are unreaped processes associated with the terminal -- as in, having the same session ID, see setsid(3).
In future, we might want to reap proactively.
For now, apply an isolated workaround: instead of taking care of a child process, double-fork to create an orphaned process. Since the orphan will be reaped by PID 1, we can eventually close Terminal.app without it asking for confirmation.
/bin/sh -c '( "$@" ) >/dev/null 2>&1 &' -- cmd arg1 arg2
This fix confines the problem to the period during which a background process is running. To complete the fix, we would need to call setsid to detach the background process from a controlling terminal. That seems to be desirable however macOS does provide a setsid utility.
setsid cmd arg1 arg2 >/dev/null 2>&1
Fixes #11181
I botched the initial PR description, it's fixed now