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, 5 insertions, 1 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 7ccb9a91..6c388f20 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -541,7 +541,11 @@ line on an open whose command still runs fails the write. `exec zsh` or a
 continuation prompt never reports an end; cancel the read. A read of `run`
 waits in pardes, so through 9ns it needs 9ns's concurrent requests or it
 holds up the rest of the mount. A record
-longer than a read comes in pieces, so a shell's `read` loop works. `tail -f`
+longer than a read comes in pieces, so a shell's `read` loop works: `exec
+3<>$m/log; echo follow >&3; while read -r line <&3; do ...; done`. bash's
+`read` takes a chunk, keeps one line and seeks back to just past it; a
+followed log, `event` and `pty/data` answer a read at an offset inside
+their last answer from that answer again, so no record is lost. `tail -f`
 never writes `follow`, so it sees nothing new: use the follow open instead. `/screen` returns JSON with
 `cols`, `rows`, `cursor`, a `styles` table, and row-major `cells` of
 `[grapheme, style_index]`. Each open freezes one frame until close. A