From 01bf4ed09423b3c7e01598ff3a844cc3c12c3ff2 Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Tue, 29 Sep 2026 18:07:08 -0300 Subject: A name written whole with no newline is checked with its write, as the docs now say, not at the close Round 24's no-newline rule (uwzuqzxp) already covers name, a lines file; the 9P monkey's close_runs_only_line_files repros were from a binary before it. This pins it with a test and corrects docs/fs.md, which still said such a name waited for the close. Co-Authored-By: Claude Opus 5.5 --- docs/fs.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'docs/fs.md') diff --git a/docs/fs.md b/docs/fs.md index af64fded..760693e5 100644 --- a/docs/fs.md +++ b/docs/fs.md @@ -574,8 +574,9 @@ directory. A name alone is no edit: the pane's `dirty` stays what its text made (a renamed clean file is still 0, and nothing asks about it at Exit, Restore or Del, which ask only about text edited), and `Save` writes it under the new name all the same. An open's writes are one name: held -until its newline, or its close when it has none, then applied once, however -the writes cut it; nothing else is trimmed. Two lines are refused, EINVAL, +until its newline, applied once however the writes cut it; a write with +no newline that is whole in its Twrite is the name then, so a bad one fails +that write, not the close. Nothing else is trimmed. Two lines are refused, EINVAL, in one write or as a second line on the same open (bash's `printf 'a\nb\n' > name` writes a line at a time: the first names it). A blank inside a name is taken (`two words.zig`); refused, EINVAL, in acme's words (xfid.c:650) and why, -- cgit v1.3