| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A dogfood agent's background jobs died when the command that started them
finished, even under nohup. The command's shell leads its terminal's
session, and on its exit the kernel hangs up the terminal's foreground
group, which with job control off is the shell's and every job's. The line
now runs with job control on (bash, sh, dash, zsh, ksh -m; fish status
job-control full), so a job has a group of its own and lives on, printing
below exit N, and survives the pane closing. While a job holds the pty the
pane is not reused, so the directory's next command gets a second pane
(cmdexit's golden, re-recorded by name).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
|
|
A job left in the background (sleep 100 &) held the pty open, so the pane
stayed running and the child a zombie until the job ended; a command that
closed its terminal and ran on got its end of file at once, the host waited
100 ms for an exit, reported exit ? and hung it up. Now each command's child
is watched on a thread (waitid with WNOWAIT, so its pid stays its own until
the host reaps it), and the host tells the core the exit from that: after the
pty's end of file, so the output before the exit is in, or 50 ms after the
exit without one, a job holding the pty. The pty stays open until both, so a
command that let go of its terminal is never hung up by it. All four front
ends; a host that cannot start the watcher reads the exit at end of file as
before. Tests: host_io's for both cases, and cmdexit.snap end to end.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
