> 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.
Instead installing keylogger, I can use `script` command that comes with linux/unix. .
There’s confirmation prompt before uploading, where you can decide to upload or save locally. This part of the docs (and the demo on the frontpage) need updating as they give wrong idea in the intentions here. I’ll make sure this is clear. Thanks.
This should be prominently mentioned on the “How it works” page [0], or even better, also on the main page, because it isn’t clear at all that local recording or upload to a custom server is supported. If not for the above comment, I would have dismissed the tool as unsuitable after browsing the site a bit.
Thanks. This behavior dates back to 2011, and while there 2 separate commands you can use today (asciinema rec <filename> + asciinema upload <filename>) the demo on the homepage and the docs may be giving wrong impression. This will be definitely improved in the upcoming 3.0.
There’s no bad intention here, and there’s upload confirmation prompt in versions prior to 2.4, while in 2.4+ you make explicit choice (save, upload, discard). In upcoming 3.0 we will probably decouple upload from record command completely.
We use this sometimes at work to show getting tests and other mundane things and I have to admit, when we first started we all learned a few new tools and new aliases to add. It’s amazing how much you can learn from the small things that aren’t the main thing you’re looking at
Yeah, i was aware of asciinema previous to this (long ago), but then heard a nice refresher the other day from the Linux Downtime podcast (https://linuxdowntime.com/linux-downtime-episode-83/)...so maybe the author is making their rounds to gain a little (well-deserved) promo? Either way, i find asciinema to be a very cool application.
Well, what should be clear is that “nuh” implies the same vowel as “muh”, which I don’t think is the case for how “cinema” is normally pronounced. And I presume that it’s clear that “neh” is not pronounced the same as “nuh”. My point was not to indicate a precise pronunciation, just that I don’t see how “nuh-muh” would be right.
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?).
I tried asciinema and I forgot which others, but I eventually used t-rec because it’s able to easily compress to a small size file that I can upload to GitHub (see demo on here https://GitHub.com/Langroid/Langroid) and it also creates mp4 filed that I can upload to loom etc.
From what I can see this captures screenshots? A nice feature of asciinema is that you can select text from the recordings during playback or programmatically extract it from the log files.
Recently, I've been toying with including asciinema in automated tests. Spinning up a TUI or richer CLI experience, sending it keystrokes, asserting on the output, all wrapped up in asciinema so that if it fails I can see what went wrong via the playback.
Jury is still out but it's been an interesting experiment.
I'm planning to use it as logging solution. A cron command that needs to run every hour. It's whole execution will be recorded into a directory. Will be retained for a week worth of recording sessions.
These playbacks will allow to see how each invocation played out.
Be aware that the format is fairly inefficient, if your cron jobs write a lot, the files may become large. You may be better off investing into some good logging instead.
I wouldn't say it's particularly inefficient...just taking a look at the format spec, if you were just taking straight output it would be a json blob with a header containing metadata and just a bunch of raw "o" events with line by line raw data.
Certainly not as efficient as just outputting the STDOUT into a line-delimited format, but not inordinately larger.
True. logroate/fileroate kind of thing has to be in place with a cut off for 7 days or less.
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.
I recently started using this for recording all my terminal sessions (without upload). It's pretty neat to be able to go back and replay any session I had. I also threw together a small tool to grep through the output, although it's currently pretty slow:
Window recording is actually a very simple way also, and lets you have:
1. 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.
Asciinema records are small, but not in a format that is handled with commonly installed software; people rely on an external website for hosting the playback.
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.
really great, but (I am sure somebody wrote it already)
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.
According to the website, it sends the keystrokes to an API endpoint in the internet. While nice, I‘d be concerned about the security implications of using this tool. I mean it could also „accidentally“ be sending env variables etc.?
I think it only records the terminal output(along with other metadata like timing) and not what you type(input). If you enter a password in a prompt that does not echo/display it back, it shouldn't be recorded.
This is not an alternative to asciinema. VHS is great, but they have different uses. Asciinema records you and plays it back, which is great for screencasts.
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.
Maybe I'm missing something, but we've been able to do this for decades, with script/scriptreplay, programs from standard util-linux package. What does this ascii enema thing add?
>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.
Probably the Changelog podcast episode mentioned by another poster. Not only did it cover the story of the software, but also the various things that make it cool. (e.g. lightweight, can still copy/paste text from it, scalable with fonts just like videos aren't and so on.)
https://changelog.com/podcast/561
I must be an old curmudgeon, but I see no value in this over just copying and pasting the terminal output. The idea of waiting for this thing to display text instead of just scrolling through it drives me nuts, especially with product demos. It's like when pages steal your scrollbar, only for terminal sessions.
There's not supposed to be anything sexy about terminal apps, stop trying to dress them up.
Show a demo of the CLI without the end-user having to install anything. A recording gives a sense of the expected latency/ performance of the commands and is easier to digest for many than a wall of commands. Plus it uses minimal bandwidth so it's more efficient than a video, though you don't get audio. Imo it doesn't replace tutorials as much as it is a low friction way for people to get a feel for things.
About 15 years ago, as part of our incident management process I wrote a wrapper around tmux + script that let SREs and other engineers share terminal sessions during incidents or complex / long-running operations. A feature I built in was the ability to easily record the whole session so we could capture "actual" actions (and not just the ones we could remember). Sure, you can type "history", but in a postmortem it's extremely useful to be able to play back 4 different terminals simultaneously and watch what each person did in real-time. We had a number of "sev2" incidents that we turned into "sev1" incidents while following runbooks.
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.
> but I see no value in this over just copying and pasting the terminal output
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.
For true CLIs I don't see much practical benefit. A little bit in seeing live input and output, which can implicitly show things like "this supports tab completion" or "this step takes a minute to run", but that's weighted against being harder to skim and harder to handle (I can inline terminal output in a README with zero extra tools, effort, or dependencies). That said, I could see it being really useful for TUIs.
I assume this must be a drive-by comment without actually going to the website, because in the middle of the page, in an h1 tag, is the feature: "Copy & paste"
Internally we use them as additional context for L1 or L2 upskilling to show what's happening in the background, without having to provide access to client machines.
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.
It's nice for recording sessions when connecting to other systems via serial or ipmi sol.
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.
I believe `script` should be present on roughly all Linux systems. (On Arch Linux, /usr/bin/script is part of the util-linux package, which is a dependency of such illustrious packages as base and systemd.)
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....)
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.
Regarding security, I'm not sure there's more to be worried about than the usual. It's basically like a screenshot or screen recording tool that saves to a local file, except instead of an image or video it's a text file (and consequently even more inspectable).
> 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>.
I think you might be a bit confused, this is just a terminal recorder that you start manually in a shell. It produces a local file, which you can also convert into a video.
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.
Instead installing keylogger, I can use `script` command that comes with linux/unix. .