Asciinema: Record and share your terminal sessions, the simple way
asciinema.org
asciinema.org
Instead installing keylogger, I can use `script` command that comes with linux/unix. .
If you miss filename, recording goes to some server.
Discussion: https://news.ycombinator.com/item?id=33357956
agg - asciinema gif generator https://github.com/asciinema/agg
svg-term-cli https://github.com/marionebl/svg-term-cli
If you can't agree on how to pronounce asciinema there is little chance you would pronounce "ass" "nuh" "neh" and "muh" the same way.
In addition, I personally can’t write IPA and be sure it’s correct, and I would expect that most people also can’t read it.
And also, I love this thing; upvote every time. For sharing terminal stuffs its loads better than copying the relevant bits and/or outputs from `screen` (do folk still use that?).
Now you've done it. There's no going back for me now.
Jury is still out but it's been an interesting experiment.
The bane of my existence are documentations that work with asciinema instead of showing me short and concise code blocks.
These playbacks will allow to see how each invocation played out.
Unconventional, but going for it.
Certainly not as efficient as just outputting the STDOUT into a line-delimited format, but not inordinately larger.
Logging would be too much (need some logging endpoint/log shipper etc) but the other upside is that I can see exactly how it plays out and when and what gets stuck. The actual console output of the command as it progresses.
Think terraform.
https://github.com/moyix/termgrep
I stuck this in my .profile to record any session started under tmux and avoid recursive recording. It compresses the logs with zstd when you exit.
# Check if not already recording and inside tmux
if [ -z "${ASCIINEMA_REC+x}" ] && [ ! -z "$TMUX" ]; then
export ASCIINEMA_LOGFILE=/fastdata/asciinema_personal/termlog_$(date +%Y-%m-%d_%H.%M.%S.%N).log
asciinema rec -q --stdin "$ASCIINEMA_LOGFILE"
zstd -T0 --rm "$ASCIINEMA_LOGFILE"
exit
fi
$ du -csh /fastdata/asciinema_personal/\*.zst | tail -1
1.3G total1. mouse pointer capture, so you can point to things of interest in the video;
2. scroll-back actions and position of scroll bar are recorded; and other GUI elements and actions like switching between terminal tabs;
3. audio! so you can talk about what you are showing;
4. a standard video format viewable in many media players, easily shared or hosted as a simple file, or uploaded to video sites.
No character copy and paste, though; you have to supply people with supplementary files or documentation if that is important.
Window recording is easy. Typically, the recording program lets you pick a window and some options like whether to capture audio. You hit a start button and get a countdown 4, 3, 2, 1 ... which gives you a chance to switch to that window and get settled and ready. When done, you click on some gadget to stop.
Recording a TTY doesn't all have to be "live action". You can play some canned content in the session. For that, the good old "script" and "scriptreplay" utilities are useful.
TTY screen recordings compress very well (with a proper codec, not GIF!) because many of the pixels don't change between frames, and the resolution isn't HD. The window is usually only a small fraction of 1920x1024.
I'm looking at a 7 minute video I made in 2022; it takes 29 Mb. It's not small, but for this day and age, that's not large. It's likely smaller than a download required to host all the Asciinema stuff to be able to play a file, and can be streamed just by planting the file on a server somewhere. It's small enough I can casually plonk that into a Slack chat or what have you. For sending as an e-mail attachment, I might think twice.
It has an audio track without which you wouldn't understand all that is going on. Like I'm hitting such and such a key to bring about such and such an effect or mode, which shows up in such and such a way that I'm indicating with the mouse pointer.
that default "press <enter> to upload" is a bit dangerous", I feel I am one return away from sharing sensitive data as a mistake.
asciinema: recording finished asciinema: press <enter> to upload to asciinema.org, <ctrl-c> to save locally asciinema: asciicast saved to /tmp/tmpbrxx1lzf-ascii.cast
I would prefer the reverse: press <ctrl-c> to upload
well, I see you just need to specify a rec file to avoid this, so it's fine.
but .. it looks like you can delete it only if you previously added your credentials https://discourse.asciinema.org/t/how-can-i-delete-a-recordi... is it?
> asciinema rec demo.cast
„ then the recording is saved to a local file in asciicast 271 format.“
By charm.sh
VHS lets you make scripts and record those, which is great for having your CI build a script that shows how the current version of your cli tool looks exactly.
>Certain interactive commands, such as vi(1), create garbage in the typescript file. script works best with commands that do not manipulate the screen, the results are meant to emulate a hardcopy terminal.
ASCIInema is for the case where you want to show things like edits on a screen oriented editor in a useful way. Basically anything that moves the cursor around.
Without it this is just about as useful as Google Charts.
> Web app for hosting asciicasts
> https://github.com/asciinema/asciinema-server
and
> Web player for terminal session recordings
> https://github.com/asciinema/asciinema-player
Edit: From what I can see, the player has option to point to the cast file directly.
I find that to be the most useful player.
There's not supposed to be anything sexy about terminal apps, stop trying to dress them up.
Animated tutorial-like ‶videos″ of CLI that are much smaller than gifs/mp4s.
I can't share them because they're not openn-source, but I made quite a few of those for consumption by other teams within my company, and they were always very much appreciated.
You may find it silly, but the wow effect is very efficient to onboard people.
> # See how easy it is to record a termina
(I missed the l at the end because I copied this on my phone with the bad handlebars for selection, but I'm preserving the mistake for authenticity.)
If you're a verbal learner (reader), that's fine. This additional method covers the visual learners, while the auditory and kinesthetic learners we circle back on with smaller workshops.
There's probably a better way to do this, but I don't know what it is.
It produces a file containing just what got sent to the terminal, no timing information. -T lets it output timing info but as a separate file.
(Also in this vein, the ttyrec format is a binary format that interleaves timing and terminal output. It’s very similar in function to the asciicast v2 format, but much more compact by dint of being binary rather than JSON, and asciicast v2 has a few extra features like being able to declare the duration in the header, record environment variables, record the colour palette, and add markers. I wish asciinema had built on the ttyrec format at least for its canonical format (like WASM has the binary and text formats), and asciicast v1 was bad in a few ways, but from asciicast v2 it’s much more reasonable, and maybe when I eventually get round to doing terminal recordings again I’ll use asciinema this time instead of termrec + my own <tty-player> element, as seen on https://chrismorgan.info/blog/make-and-git-diff-test-harness....)
To be honest, the main use of the script was helping engineers use tmux even if they had never had to before (y'know, mouse clicky, familiar window management keyboard shortcuts etc, automating the process of requesting access to a tmux session, receiving those notifications, and granting access). But I definitely improved a number of runbooks or found the "aha, that's how we broke it!" by watching those replays, in particular the timing of events in different terminal sessions.
An extremely useful feature in scriptreplay is the "remove all the long pauses" option.
Sometimes it's nice to be able to go back and see recordings of boot logs, where timing is useful, and navigating bios screens or other similar user interfaces.
If it needs documenting it's nice to record it as you're doing it, and writing the documentation as you're rewatching the recording so you can copy paste the important moments.
It's not so nice to rely on only a recording as documentation.
Joking aside this seems like a pretty useful idea.
The idea that you could provide pre-canned training where you can stop in the middle, rewind and poke about or experiment is compelling. Combine that with a safe sandbox that you can blow away at any point and you've got a winner.
Crucially though I think they need a really good security story before I think I'd use or recommend it myself though.
You can also roll your own tool, the format is reasonably well documented and simple.
> If the filename argument is omitted then (after asking for confirmation) the resulting asciicast is uploaded to asciinema-server (by default to asciinema.org), where it can be watched and shared.
If the filename argument is given then the resulting recording (called asciicast) is saved to a local file. It can later be replayed with asciinema play <filename> and/or uploaded to asciinema server with asciinema upload <filename>.
You can also optionally upload it to the service - if you want to.
> When you run asciinema rec in your terminal the recording starts, capturing all output that is being printed to your terminal while you’re issuing the shell commands. When the recording finishes (by hitting Ctrl-D or typing exit) then the captured output is uploaded to asciinema.org website and prepared for playback on the web.