I just came across asciinema and really like it for capturing my command line workflows.
One idea that I am exploring is using it as a daily logger for my terminal sessions. Basically, every time I start a terminal, I want to have asciinema rec ~/recordings/Start-${date}_Session-${id}.cast start and record everything that goes on in my terminal. A few concerns might be:
I’m not sure how big these files will get.
Is playback an issue for such long cast files?
If the process isn’t killed properly, it might log indefinitely.
My real interest is not so much in playing back the recordings but in using the .cast files for creating a vector database that I can then query and use an LLM to extract useful workflows that happen over long periods of time. For example, if I’m troubleshooting and interacting over a 6-hour period and eventually get something to work, it would be nice to use an LLM+Vector database to ask, “Can you find the workflow for XYZ that worked and show the shell script for it?”
Thanks for sharing your approach. I thought about using .history for capturing terminal commands, but the issue is I want to capture standard input/output interactions within programs like Emacs, Python interpreter, etc. Asciinema records the entire terminal session, including all IO interactions, making it more comprehensive.
You’re not the first one auto-recording all sessions with asciinema, so I recently implemented support for recording to a directory, with auto-generated filename (from a template). See the details in the release notes for 3.0 RC3.
There are several variables you can use in the filename template, {pid}, {hostname}, {user}, in addition to the strftime-like (% prefixed) time formatting.
I hope this makes it even easier for you to log all your terminals Curious to hear any feedback on that! This is the initial implementation of the feature, and I’m open for tweaking the default template, adding more useful variables etc.
It really depends Mostly on how much output those sessions produce, and whether you use “fullscreen apps” such as vim. There’s no universal estimate I’m afraid.
Playback in terminal, with asciinema play, has no issues, you can play recordings of any length. Playback with the web asciinema player will work as long as the loaded and parsed recording fits in memory. If you self-host the player the memory usage in the browser is the only concern. As for uploading to asciinema.org, there’s 8 MB filesize limit currently.
Not sure if I get this one. Which process wouldn’t be killed properly?
People have been doing similar thing, with a bash config like this (haven’t tested, treat as pseudo-code):
if [[ -z $ASCIINEMA_REC ]]; then
asciinema rec ~/recordings/${date}-$$.cast
fi
With the new templating it could be as simple as:
if [[ -z $ASCIINEMA_REC ]]; then
asciinema rec ~/recordings/
fi
I’m thinking of allowing the use of environment variables in the template string, and evaluating them by asciinema. I think a familiar ${SOME_VAR} syntax is a good choice. This could be useful especially when the filename template is set in a config file, and therefore not evaluated by the shell itself (in which asciinema rec is started).
If we used ${SOME_VAR} syntax for env vars, maybe it’d be good idea to rethink the built-in var syntax ({pid}, {hostname}, …), as those two would be too similar (only a $ difference) and prone to mistakes?
I wasn’t clear, but I’m thinking of edge cases such as if you use tmux or nohup and even if you close a terminal window would you still be logging with asciinema? But maybe this doesn’t even make sense since nohup for example is tied to a process, .
In somewhat related aspect, any ideas on a smooth way to gzip the recordings once asciinema recording is stopped?
Curious to hear any feedback on that! This is the initial implementation of the feature, and I’m open for tweaking the default template, adding more useful variables etc.
.