Comment by debba
6 months ago
Hi HN,
I built rewindtty, a small tool in C that lets you record a terminal session and later replay it, using a simple JSON log format that includes:
- timestamp - command (user input) - output (stdout) - stderr
It works like this:
- rewindtty record session.json # Runs a shell, records the session - rewindtty replay session.json # Replays it step by step
Under the hood:
- Uses fork() to manage the pseudo-terminal - Captures stdout/stderr with timestamps - Stores everything in structured JSON for easy analysis, replay or transformation
Why I made this: I wanted a minimal tool to track terminal interactions — for debugging, documentation, and reproducibility — without relying on heavier tools or external formats.
It’s still early, but the core works and I’d love feedback or suggestions.
You have scratched a long persistent itch. Good work!
And I love that you used c. Nothing against rust, or (ahem) “go”, but it’s good to see you doing something in c!
Yeah, it’s just a side project for now, but I’m hoping to make it more solid over time. As for C, I wanted to challenge myself and step away from what I usually do — try something a bit different.
How does it deal with escape sequences? Does it just record them verbatim?
It records escape sequences verbatim during capture, then handles them intelligently during replay.
Recording phase: All terminal output including ANSI escape codes, color sequences, and cursor movements are captured exactly as they appear - no processing or stripping occurs.
Replay phase: - Decodes various escape formats (\u001b, \033, \x1b) back to actual escape characters - Filters out problematic terminal query sequences that could cause artifacts - Preserves visual escape sequences (colors, cursor positioning) for faithful reproduction
So yes, escape sequences are recorded verbatim, but the replayer ntelligently processes them to recreate the original terminal experience while avoiding terminal corruption.
That sounds like a good strategy! I've dabbled in writing task runner, and relaying logs with preserved colors and formatting without messing up the terminal and interleaving messages from different tasks is a huge hurdle.
I wish there was a standard for telling processes "keep the colored and formatted output, but assume it will be read line by line"... It's possible to just let processes write into pty's and then parse the output, but then you pretty much have to implement an entire nested terminal emulator :-(