# 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 ` 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.