A followed log, event or pty/data answers a read inside its last answer from it again, so bash's read loses nothing

bash's read on a seekable fd takes a chunk, keeps one line and lseeks back to just past it; a stream had already moved on, so the rest of the chunk was lost and a while-read loop over the log dropped records. Each stream open keeps its last answer and the offset it was read at, and a read strictly inside it is answered from it; a read at the same offset, as a client that ignores offsets makes, still gets the next record.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 2 insertions, 1 deletions

diff --git a/.agents/skills/pardes-9p/SKILL.md b/.agents/skills/pardes-9p/SKILL.md
index 756a9785..8abd9fc4 100644
--- a/.agents/skills/pardes-9p/SKILL.md
+++ b/.agents/skills/pardes-9p/SKILL.md
@@ -60,7 +60,8 @@ $m/pane/<n>/pty/run   write one line, read `exit N` + its output, or `busy` / `e
 $m/log        recent events, then EOF: new|del|rename|save <serial> <name>, msg <serial|-> <text>,
               run <serial> <line>, exit <serial> <N|?>, send <from> <to> <repl-id>,
               dump|restore <path>, err <serial|-> <file>: <why>
-              (exec 3<>$m/log; echo follow >&3; cat <&3  waits for new ones; tail -f does not)
+              (exec 3<>$m/log; echo follow >&3; cat <&3  waits for new ones; tail -f does not;
+              while read -r line <&3; do ...; done loses nothing)
 $m/screen     the rendered screen as JSON, frozen per open
 $m/listeners  this session's dial addresses
 $m/focus      the serial of the pane with the keyboard (empty while a column/workspace tag has it);