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 <cols> <rows> | 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.

1 files changed, 37 insertions, 0 deletions

diff --git a/src/look.zig b/src/look.zig
index 90945013..c98e7988 100644
--- a/src/look.zig
+++ b/src/look.zig
@@ -1064,6 +1064,43 @@ pub fn ttyTaken(shell_pid: libc.pid_t, master_fd: c_int) bool {
     }
 }
 
+/// DELIVER A SIGNAL TO WHATEVER IS ON THIS PANE'S TTY — the host half of
+/// `pty/ctl`'s `sig` verb, shared by every frontend that owns pane shells so
+/// that the target is decided once instead of three times.
+///
+/// THE TARGET IS THE FOREGROUND PROCESS GROUP, not the shell's pid, and the
+/// difference is the whole usefulness of the verb. `tcgetpgrp` on the master
+/// answers with the number the kernel would deliver a ^C to (see the comment
+/// on the declaration above), which is the running build, the pager, the
+/// agent — the thing a script means when it says `sig INT`. Aimed at the pid
+/// instead, `sig INT` would reach an interactive shell, which ignores SIGINT
+/// while it waits for a job: the verb would appear to work and do nothing on
+/// the one case anybody wants it for. At an idle prompt the two are the same
+/// number, because forkpty made the shell its own group leader.
+///
+/// The pid is the FALLBACK, for an OS or a host whose master end will not
+/// answer the ioctl. There `sig KILL` still ends the shell, which is the case
+/// where being ignored is not an acceptable outcome.
+pub fn signalTty(shell_pid: libc.pid_t, master_fd: c_int, which: pardes.PtySignal) void {
+    // Whatever `std.c.SIG` spells these as on this platform, unconverted: the
+    // one call below wants exactly that type (see the `kill` beside `harvest`).
+    const sig = switch (which) {
+        .int => libc.SIG.INT,
+        .term => libc.SIG.TERM,
+        .hup => libc.SIG.HUP,
+        .quit => libc.SIG.QUIT,
+        .kill => libc.SIG.KILL,
+    };
+    const fg = tcgetpgrp(master_fd);
+    // A process GROUP is addressed as its negated leader; `fg` is already a
+    // group id, so this is `kill(-fg)` and not `kill(-leader_of(fg))`.
+    if (fg > 0) {
+        _ = libc.kill(-fg, sig);
+        return;
+    }
+    if (shell_pid > 0) _ = libc.kill(shell_pid, sig);
+}
+
 /// Read a small /proc text in one go. These files are generated on read and
 /// answer completely in a single call at these sizes; a short read would only
 /// truncate a field, which every parser below treats as "no answer".