fix(console): a path with a space is one argument, not two

[shreethaar]

Fixes #362.

What was broken

kuna decompile is the one surface that reaches the engine through a console
script rather than an in-process call. Every path in that script was
interpolated unquoted, and the console reads a filename with s >> filename —
whitespace-delimited, no quote rule anywhere in the grammar. Any space in a
path split it into two arguments.

load file — read_token returns the head, the command sees a second token,
and re-reads: the head becomes the BFD target and the tail the filename.

$ kuna decompile "/tmp/spaced dir/a.out" add
error: could not build an architecture for /tmp/spaced dir/a.out:
       Unable to recognize imagefile dir/a.out: No such file or directory (os error 2)

With an explicit --target (3 tokens) the tail was dropped entirely and the load
was attempted against the prefix.

openfile write — the same defect on the output side, and the half that does
not need a spaced binary path to bite. The temp file lives in
std::env::temp_dir(), which on Windows is C:\Users\First Last\AppData\Local\Temp
by default, so on any Windows account with a space in the user name every
kuna decompile failed, spaced binary path or not:

$ TMPDIR="/tmp/tmp with space" kuna decompile "/tmp/plain/a.out" add
error: no C output for "add" in /tmp/plain/a.out; decompiler said: <transcript>

And that half was silent data loss, not just a failed run. sync_redirect_file
opened the truncated path with .create(true).truncate(true) and discarded the
error, so the C was written to a file named after the first path component. The run
above created /tmp/tmp containing the decompiled C; on Windows that path is
C:\Users\John, and an existing file there is truncated with no diagnostic.

Quoting at the caller could not have fixed this. A reader with no quote rule
takes the quote as part of the token:

$ printf 'load file "/tmp/spaced dir/a.out"\nquit\n' | decomp_dbg
Unable to recognize imagefile dir/a.out": No such file or directory (os error 2)

Mechanism

The grammar learns a quote rule. New CommandStream::read_filename
(kuna-console/src/interface.rs) layers an optional double-quoted form over
read_token:

• unquoted input is byte-identical to read_token, eof latching included — the
  vendored corpus, every generated script and every hand-typed line without a quote
  parse exactly as before;
• inside quotes, \" and \\ are escapes and every other backslash is literal, so
  "C:\Users\John Doe\a.out" and "C:\\Users\\John Doe\\a.out" both resolve to the
  same path;
• an unterminated quote consumes the rest of the line and latches eof (a diagnostic
  would have to invent a grammar error the C++ console has no wording for).

Wired into the four commands that actually read a path: load file,
openfile write, openfile append, parse file. (callgraph load and
load test file are engine_unavailable stubs — nothing to fix.)

The producers quote conditionally. console_path in kuna-cli/src/decompile.rs
quotes only a path containing whitespace or a quote, so every script that works
today stays byte-identical — including for an older decomp_dbg reached through
--decomp-dbg, which would not understand a quote. scripts/decompile.py carries
the same helper, mirrored.

The silence goes away. sync_redirect_file reports a failed open or write on
stderr instead of discarding it. The CLI already forwards subprocess stderr into its
failure report, so a write that did not happen can no longer read as a decompiler
that produced nothing.

Scope

Only kuna decompile and the console itself were affected. decompile-all,
functions, decompile-project and fid call bootstrap_from_object(&binary, …)
in-process, where the path is a Rust string that is never tokenized — verified
working on the same spaced path that broke decompile. That asymmetry was its own
trap: decompile-all succeeded on a binary decompile rejected as "unsupported".

Deliberately out of scope, for a follow-up: load function <name>,
option <name> <value> and kassert <args> are interpolated into the same script
unquoted and would split the same way on a value containing a space. They are symbol
and option values rather than paths, so routing them through a filename reader is
the wrong shape; they want their own decision. No known binary trips them today.

Not gated behind an option

Per AGENTS.md a feature ships behind a named option, a strict bug fix does not. This
cannot change emitted C for any input that works today — unquoted paths parse
byte-identically, and the CLI emits an unchanged script for every path without
whitespace. No settableTable row, no catalog count change. No measurable speed
delta: the added work is one contains scan per path, per run.

Tests

Where	What
interface.rs (5)	read_filename: quoted paths keep spaces; unquoted is byte-identical to read_token (value and eof) across four line shapes; both Windows spellings and an embedded \"; two quoted args still separate; unterminated quote terminates.
decompile.rs (5)	console_path leaves ordinary paths alone and quotes/escapes when needed; build_script quotes the image, C and regions paths, quotes after a --target, and emits a quote-free script for ordinary paths.
decompile_cli.rs (2)	Real-engine end-to-end: a fixture copied under a spaced directory decompiles; a spaced TMPDIR still yields C and nothing was written to the truncation target.

Both end-to-end tests were verified to fail without the fix, with the exact
diagnostics from #362:

test a_binary_under_a_spaced_directory_decompiles ... FAILED
  the path was split on its space, got: … Unable to recognize imagefile path: No such file…
test a_spaced_temp_dir_still_yields_c ... FAILED
  the redirect was truncated, got: error: no C output for "main" in …

They live in decompile_cli.rs rather than tests/cli/ because nothing currently
runs tests/cli/*.json (noted in the functions-json-size PR body), and rather
than tests/stages/ because the defect is in the CLI/console seam, not the
decompiler phase model — so no stages baseline re-record and no corpus file count
bump.

Gates

Gate	Result
make test	PARITY OK — 675/675
make test-stages	PARITY OK — 574/574
make rust-test	green, 0 failures
make check-spec	green

docs/cli.md documents the behaviour under kuna decompile, including the quoted
form for hand-written console scripts. No docs/spec/ chapter owns
kuna-console — the chapters anchor on kuna-analysis and the phase folders — so
there is no spec chapter to update here.

Verified by hand

$ kuna decompile "…/spaced dir/a.out" add                        # was: architecture error
$ TMPDIR="…/tmp with space" kuna decompile "…/plain/a.out" add   # was: no C output
$ TMPDIR="…/tmp with space" kuna decompile "…/spaced dir/a.out" add --regions
$ kuna decompile "…/spaced dir/a.out" add --target x86:LE:64:default
$ printf 'load file "…/spaced dir/a.out"\nquit\n' | decomp_dbg   # interactive grammar

All succeed; the control run on an unspaced path is unchanged, and no file appears at
any truncation point.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01Jp9d9GVacWoV338MB6Tysf

[mahaloz]

Reviewed — correct, and both halves reproduce and close

Verified against a fresh gcc -O0 fixture, main's binary vs this branch's:

	main	this branch
kuna decompile "<dir with space>/a.out" add	Unable to recognize imagefile dir/a.out	C
TMPDIR="<tmp with space>" kuna decompile <plain>/a.out add	no C output and the C landed in …/repro/tmp	C, and no file at the truncation point
same, with --regions	—	C + regions
--target x86:LE:64:default on the spaced path	prefix-truncated load	loads (byte-identical output to the plain path on main)
printf 'load file "<spaced>"\nquit\n' | decomp_dbg	imagefile dir/a.out"	successfully loaded

The diagnosis holds where it matters: quoting at the caller genuinely cannot fix a reader with no quote rule, so the grammar is the only place the fix can live; and read_filename is byte-identical to read_token for unquoted input including the eof latch, which is what keeps the corpus and every pre-existing script still parsing. Wiring is complete for every live path-taking command — save/restore/addpath are not registered and produce C is an engine_unavailable stub, so load file / openfile write|append / parse file is the whole set. The only remaining script producers in the tree are kuna-cli/src/decompile.rs and scripts/decompile.py, both fixed; the rest of the load file sites are tests over space-free in-repo paths.

Both end-to-end probes are load-bearing: reverting only console_path's quoting predicate fails both, with the #362 diagnostics.

Three things added before merge

1. docs/history.md: DIV-100. This is an intentional change to default behaviour vs upstream — s >> filename could only split on whitespace, and sync_redirect_file discarded its write error — which is exactly what the DIV registry records. DIV-88/89/90/91 are the precedent: driver-tier bug fixes, no flag, one row each.

2. docs/spec/00-overview.md: the prose. The claim that no chapter owns kuna-console isn't quite right — 00-overview.md owns the console/driver seam and already carries the neighbouring DIV-89 stdout boundary and the DIV-90 failure contract. The grammar and the redirect diagnostic go next to them. make check-spec green in lenient and strict mode. docs/cli.md names the DIV so the user-facing contract is traceable.

3. a_spaced_temp_dir_still_yields_c was unsafe. It derived the truncation target by splitting the scratch dir at its first space and then remove_filed that path unconditionally. That is only this test's own path while every component above it is space-free — and the parent was std::env::temp_dir(), so a developer whose system temp dir contains a space (the very environment this PR is about) moved the split into that name. Demonstrated:

$ touch "$SCRATCH/outer"; TMPDIR="$SCRATCH/outer tmp" cargo test … a_spaced_temp_dir
the C was written to the truncated path …/scratchpad/outer, clobbering whatever was there
test a_spaced_temp_dir_still_yields_c ... FAILED
$ ls "$SCRATCH/outer"
ls: cannot access …: No such file or directory     # the test deleted a file it never created

The parent is now CARGO_TARGET_TMPDIR — free to choose, since the child's temp dir is the TMPDIR the test passes it — the cleanup removes the target only when it is actually there, and an assert states the precondition instead of letting the clobber check pass vacuously. Both probes now pass under a spaced TMPDIR and a plain one, and both still fail on the parent commit.

Gates (rebased onto main @ f407868, which added make test-cli)

Gate	Result
make test	PARITY OK — 675/675
make test-stages	PARITY OK — 574/574
make rust-test	green — 330 targets, 4,925 passed, 0 failed
make check-spec	green, lenient and strict
make test-cli	1/1
kuna catalog --check	OK

One note for the record: the PR body says nothing runs tests/cli/*.json. That changed with #364 — make test-cli is now a gate in CI. No probe is needed here (the loop promotes those; this fix carries real Rust integration tests), but the sentence is stale.

Squashing. Thanks — the write-up on both halves, especially the silent-clobber mechanism, made this quick to verify.