1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
# Open questions
Decisions deliberately left open, with what is known so far, so they can be
picked up without redoing the research.
## Where does an unknown command word run?
Raised 2026-09-27 in the review of pardes against acme (Plan 9 source at
`~/05-genizah/principia-softwarica`).
**Decided 2026-09-28: a command pane.** Clicked or written at an interactive
terminal at its prompt, the line is typed into that shell, whose state the
clicker can see. From anywhere else it runs as its own terminal pane whose
child is the root ctl's `Shell` run with `-c` and the line, in the pane's
directory: full emulation
(colours, `less`, `vim`, `sudo`'s prompt work), the exit status from waiting
on the child (`exit N`, `exit 127` for a misspelling, no prompt marks
needed), Kill signalling its process group, `run`/`exit` records in the log,
and `exec` answering its serial. One command pane per directory is reused
once done, and keeps what it showed, as acme appends to `+Errors` and never
clears it (util.c:213-221). Chosen over acme's process-into-`+Errors` because
it keeps interactive programs working without a streaming runner, and over
a PATH check before typing into a shell, which misjudges builtins, aliases
and functions and leaves the shell's state in the way. The analysis below is
what it was decided from.
**Today.** A middle-click, an `exec` write or a tag word that is not a builtin
is typed into a terminal pane: the pane itself when it takes a command line,
else a shell for the pane's directory (`execute`, `ttyForDir` in
`src/exec.zig`). The command shares that shell's cwd, environment, history
and aliases, and its output lands in the terminal.
**acme.** An external command runs as its own process: stdin from
`/dev/null`, stdout and stderr to the directory's `+Errors` window, `$winid`
and `%` set for it (`editors/acme/exec.c`, `run()` and its callers around
:1180-1300 and :1425). No shell state is shared between commands.
**What each costs.**
* Typing into a shell: interactive programs work, and so do aliases and
functions. But every command depends on that shell's state (is it busy,
which directory it is in, what was typed at its prompt), and a misspelled
builtin silently becomes a shell command. The 9P `exec` file cannot report
that the command failed.
* A process per command: the misspelling hazard goes away at the root, the
editor knows each command's exit status and output, and `exec` could answer
the way `pty/run` does. But aliases, shell functions and interactive
programs need a terminal of their own, and output goes to a `+Errors`-style
buffer rather than a live terminal.
**Evidence from use (2026-09-28).** A fresh agent driving pardes through
9P wrote a misspelled word to `exec`; it was typed into a terminal's fish
shell ("Unknown command"), nothing reached `log`, and the write succeeded.
Its report ranked this among the confusing behaviours.
**Related.** `pty/run` (see `docs/fs.md`) already gives an agent the second
behaviour inside a chosen terminal: a line in, `exit N` and its output out.
The planned root `ctl` (session builtins) and pane `ctl` (pane builtins)
refuse unknown words, whatever is decided here; the question is only what
`exec` and the middle-click do with them.
## Where does an exec from a code file go?
**Decided 2026-09-28: to a REPL bound for its language, when one is.**
`Repl python` binds a terminal; then an exec made by a gesture (a middle
click, the execute key, a selection or a single word) on the body of a file
in that language, or on the REPL's own body, is typed into the REPL
instead of run. What stays a command whatever is bound: a builtin's word,
a word in a tag, `Exec <text>` run by name, a command word @`cmd` in the
text, and a 9P `exec` write (a script writes the REPL's `pty/data`). An
event record written back is done as the click it was, REPL and all. With
several bound the pane asks which, one key answering, and remembers
nothing. A REPL takes text only while its program has the terminal, and a
done command pane cannot be bound. Chosen over a per-file or per-directory
binding, which would need a place to keep and show it; bindings are not
dumped. `docs/fs.md` has the behaviour.
|
