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?
@stefanbringuier
You might be interested in cinelog.
I just published it today after working some days in my spare time on it making the search, markers and webplayer work together in a fine way.
It is implemented using eBPF technology to capture all pty sessions on your computer and archiving them in asciicast v2 format with optional zstd compression. It doesnβt need modification to shell rc files and can be configured to run as a systemd service.
Hereβs the directory structure of the recordings: