diff options
| author | Gabriel Schneider <[email protected]> | 2026-09-28 14:59:17 -0300 |
|---|---|---|
| committer | Gabriel Schneider <[email protected]> | 2026-10-01 00:12:15 -0300 |
| commit | d70f0029f0808e0a3724150a081015e0f943dfb5 (patch) | |
| tree | 32cd92b54c52f2e6d9c6fec6d5ef42e34af7b9e4 /test | |
| parent | ada81f05127506dec0dbb7af390cb43fd0da9d40 (diff) | |
| download | pardes-d70f0029f0808e0a3724150a081015e0f943dfb5.tar.gz pardes-d70f0029f0808e0a3724150a081015e0f943dfb5.zip | |
A command pane's command is over when its process exits, not when its pty closes
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]>
Diffstat (limited to 'test')
| -rw-r--r-- | test/snapshots/cmdexit.golden | 14 | ||||
| -rw-r--r-- | test/snapshots/cmdexit.snap | 26 |
2 files changed, 40 insertions, 0 deletions
diff --git a/test/snapshots/cmdexit.golden b/test/snapshots/cmdexit.golden new file mode 100644 index 00000000..58412752 --- /dev/null +++ b/test/snapshots/cmdexit.golden @@ -0,0 +1,14 @@ +== snap opened grid=120x31 cursor=7,3 +|Newcol Joincol Find Grep Help Changelog Tutor Dump NextColor Debug Exit +| New Tty Find Grep Joincol Delcol +| /tmp/pardes-snap/cmdexit/cwd/cmds.txt Save Tty Collapse Del +| 1 sleep 30 & echo BG''STARTED +| 2 exec </dev/null >/dev/null 2>&1; sleep 1; false +== snap background grid=120x31 cursor=7,3 +|17: /tmp/pardes-snap/cmdexit/cwd (sleep 30 & echo BG''STARTED) exit 0 Kill Save Collapse Del +|18: BGSTARTED +|19: exit 0 +== snap letgo grid=120x31 cursor=7,3 +|17: /tmp/pardes-snap/cmdexit/cwd (exec </dev/null >/dev/null 2>&1; sleep 1; false) exit 1 Kill Save Collapse Del +|20: % exec </dev/null >/dev/null 2>&1; sleep 1; false +|21: exit 1 diff --git a/test/snapshots/cmdexit.snap b/test/snapshots/cmdexit.snap new file mode 100644 index 00000000..ff60a881 --- /dev/null +++ b/test/snapshots/cmdexit.snap @@ -0,0 +1,26 @@ +# A command pane's command is over when its process exits, not when its pty +# closes. A job it leaves in the background holds the pty open, and the pane +# still says `exit 0` as soon as the command itself is done; a command that +# lets go of its terminal and runs on is not hung up at its pty's end, and +# says how it ended when it does. +file cmds.txt sleep 30 & echo BG''STARTED\nexec </dev/null >/dev/null 2>&1; sleep 1; false +config Verbose off +start 31 120 cmds.txt +wait 8000 cmds.txt +stable 700 20000 +snap opened +# line 1: `sleep 30` keeps the pty, and the pane says exit 0 regardless +press middle 7 4 +drag middle 34 4 +release middle 34 4 +wait 10000 exit 0 +stable 700 15000 +snap background +# line 2, in the same pane now its command is done: its end of file comes at +# once, and its exit a second later, from `false` +press middle 7 5 +drag middle 54 5 +release middle 54 5 +wait 10000 exit 1 +stable 700 15000 +snap letgo |