From 5f4719da21f06b58694d52d354f5fda431ff8543 Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Thu, 27 Aug 2026 15:32:02 -0300 Subject: acmefs: a pane's terminal gets pty/data, pty/ctl and pty/status Step 3 of the 9P chain (docs/9p.typ 12.3, docs/registry.typ 9P-8). Nothing here is about 9P: it lands in the FUSE-served tree and any later transport inherits it. A script could write into a terminal that already existed and read its rendered scrollback. It could not START one, RESIZE one or SIGNAL one. Two of those were already effects the core emits, so `exec` and `winsize` are existing capabilities acquiring a name; only `sig` is new, and it brings the one new host method, `push_pty_signal`. pty/ctl winsize | sig INT|TERM|HUP|QUIT|KILL | exec one verb per line, validate-all then apply-all, EINVAL applies nothing -- `writeCtl`'s shape and `writeCtl`'s reason pty/status cols, rows, tty-taken as three %11d fields pty/data write is input to the process; read is the RAW output stream, gated on a reader count so a pane nobody reads costs one branch A pane that is not a terminal has no pty/ at all: the lookup is ENOENT and readdir does not list it. `PaneFile` is an enum(u4) and this takes it from 11 values to 15. ONE REMAINS. That is also why pty/ is a DIRECTORY and not three more flat names -- a subdirectory costs one value and buys its own namespace, so `ctl` and `data` did not have to be renamed. Two things the core does not know, and which are therefore not invented: a child's EXIT STATUS (a shell's death is `Event.eof`, which removes the pane, so there is no directory left to read it in) and RAW/COOKED (the core never sets a termios; the mode belongs to the program on the far side). Verified live against a daemon: pty/ appears only on the terminal pane; a `winsize 0 24` and a `sig SIGINT` are refused; a bad verb beside a good one applies neither; `echo pty-works` written to pty/data runs in the shell and its output reaches the body; and a blocking read of pty/data returns the raw stream, OSC 133 marks and all. fs-bench unchanged and still zero allocations. --- src/detached/wire.zig | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) (limited to 'src/detached/wire.zig') diff --git a/src/detached/wire.zig b/src/detached/wire.zig index a84c2a68..23a85158 100644 --- a/src/detached/wire.zig +++ b/src/detached/wire.zig @@ -39,16 +39,18 @@ //! frontend must not have to have been built with the core's options — so it is //! ALWAYS on the wire and dropped on arrival by a build with nowhere to put it. //! -//! WHAT IS NOT HERE. The seam has twenty-one methods; this carries FIVE of +//! WHAT IS NOT HERE. The seam has twenty-two methods; this carries FIVE of //! them — `push_present` as `frame`, `push_set_clipboard`, -//! `pull_read_clipboard`, `push_open_link` and `push_detach` — and the sixteen -//! it does not are named here with their reasons. The five are spelled out -//! because this arithmetic has now gone stale twice in one day, once when the -//! machine-local eight moved into the daemon and once when `detach` arrived, -//! and a count nobody can check against a list is a comment that rots quietly. -//! * The eight machine-local ones — `push_spawn`, `push_pty_write`, -//! `push_pty_resize`, `push_write_file`, `push_write_dump`, -//! `push_watch_file`, `push_watch_theme`, `push_dump_themes` — are +//! `pull_read_clipboard`, `push_open_link` and `push_detach` — and the +//! seventeen it does not are named here with their reasons. The five are +//! spelled out because this arithmetic has now gone stale twice in one day, +//! once when the machine-local eight moved into the daemon and once when +//! `detach` arrived, and a count nobody can check against a list is a comment +//! that rots quietly. +//! * The nine machine-local ones — `push_spawn`, `push_pty_write`, +//! `push_pty_resize`, `push_pty_signal`, `push_write_file`, +//! `push_write_dump`, `push_watch_file`, `push_watch_theme`, +//! `push_dump_themes` — are //! performed by the detached core ITSELF, through `host_io.zig`. A unix //! socket means it is on the same machine, so there is no question of //! whose disk or whose process table is meant, and a pane's shell has to -- cgit v1.3