[HN Gopher] Asciinema: Record and share your terminal sessions, ...
       ___________________________________________________________________
        
       Asciinema: Record and share your terminal sessions, the simple way
        
       Author : alexzeitler
       Score  : 208 points
       Date   : 2023-11-03 20:53 UTC (1 days ago)
        
 (HTM) web link (asciinema.org)
 (TXT) w3m dump (asciinema.org)
        
       | EligibleDecoy wrote:
       | 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
        
       | candiddevmike wrote:
       | 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.
        
         | shakow wrote:
         | > 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.
        
           | candiddevmike wrote:
           | CLI tutorials that you can't copy and paste from sound
           | terrible, but to each their own I guess.
        
             | lolinder wrote:
             | I just copied this from the demo on TFA:
             | 
             | > # 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.)
        
             | bitvoid wrote:
             | But you can copy and paste from the recording. That's one
             | of the main features presented on the linked homepage. I
             | can even copy and paste on mobile.
        
             | bdcravens wrote:
             | 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"
        
           | yjftsjthsd-h wrote:
           | 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.
        
             | shakow wrote:
             | You're right; I meant TUIs, not CLIs.
        
         | achillean wrote:
         | 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.
        
         | fostware wrote:
         | 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.
        
         | miki123211 wrote:
         | I have used this in the past to capture what escape sequences a
         | tool receives and emits when debugging TTY issues.
         | 
         | There's probably a better way to do this, but I don't know what
         | it is.
        
           | chrismorgan wrote:
           | 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....)
        
         | evmar wrote:
         | For apps that show incremental progress it can be useful for a
         | demo. Here's my build system going:
         | 
         | https://asciinema.org/a/592924
        
         | soraminazuki wrote:
         | How would you demo, say Vim plugins, with copy and paste?
        
         | raffraffraff wrote:
         | 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.
        
           | stavros wrote:
           | FYI, Tailscale does this natively now.
        
         | feitingen wrote:
         | 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.
        
       | knubie wrote:
       | The name of this site drives me crazy. How is it supposed to be
       | pronounced? Ass-cinema? Asky-nema?
        
         | tfsh wrote:
         | From the home page "as-kee-nuh-muh". I've always just
         | pronounced it "ASCII cinema" and hadn't realised it was spelt
         | differently.
        
           | deaddodo wrote:
           | I've always pronounced it "ASCII enema", today we both
           | learned.
        
           | layer8 wrote:
           | The "nuh" is weird, as "cinema" is rather pronounced see-
           | _neh_ -muh.
        
             | prmoustache wrote:
             | Do you guys realize that you should explain how you
             | pronounce those words in the international phonetic
             | alphabet?
             | 
             | 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.
        
               | layer8 wrote:
               | 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.
        
               | stavros wrote:
               | I agree that it should be neh-muh, but I can also see how
               | nuh-muh is very similar.
        
               | losvedir wrote:
               | As a native Californian speaker of English it is indeed
               | SIH-nuh-muh for me. The majority of unstressed vowels
               | become a schwa "uh".
        
         | fiddlerwoaroof wrote:
         | I mentally say it, A-see-nem-uh, but I doubt this is the
         | canonical way
        
           | djbusby wrote:
           | And I've been doing ass-key-nee-ma
           | 
           | 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?).
        
         | jumpkick wrote:
         | ascii enema
        
           | zarzavat wrote:
           | My brain insists on reading it like this and I have long
           | given up trying to change it.
        
         | arcanemachiner wrote:
         | > Ass-cinema
         | 
         | Now you've done it. There's no going back for me now.
        
         | lloydatkinson wrote:
         | I always simply say "ascii enema".
        
       | linsomniac wrote:
       | There was a Changelog podcast last month with the author that I
       | enjoyed listening to: https://changelog.com/podcast/561
        
         | mxuribe wrote:
         | 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.
        
       | tambourine_man wrote:
       | I remember trying to record more complex commands, like btop or
       | similar, and it failed to render properly. Is it better these
       | days?
        
       | ChrisArchitect wrote:
       | From (2013) maybe? Anything new recently?
        
         | ChrisArchitect wrote:
         | 1 of 3 "what's new" blog posts 2 months ago, no interest:
         | 
         | https://news.ycombinator.com/item?id=37336255
        
         | tlavoie wrote:
         | 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
        
       | asicsp wrote:
       | See also: https://github.com/charmbracelet/vhs - Write terminal
       | GIFs as code for integration testing and demoing your CLI tools
       | 
       | Discussion: https://news.ycombinator.com/item?id=33357956
        
         | ZeroGravitas wrote:
         | Worth noting you can convert asciinema to gifs (or svgs):
         | 
         | agg - asciinema gif generator https://github.com/asciinema/agg
         | 
         | svg-term-cli https://github.com/marionebl/svg-term-cli
        
       | kazinator wrote:
       | 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.
        
         | janosdebugs wrote:
         | Window recordings are MUCH larger as they record pixel data
         | while Asciinena records bytes on the terminal output.
        
           | kazinator wrote:
           | 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.
        
       | wg0 wrote:
       | 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.
       | 
       | Unconventional, but going for it.
        
         | janosdebugs wrote:
         | 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.
        
           | deaddodo wrote:
           | 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.
        
           | wg0 wrote:
           | 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.
           | 
           | Think terraform.
        
       | alex_suzuki wrote:
       | 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.?
        
         | alex_suzuki wrote:
         | Never mind... From the FAQ:
         | 
         | > asciinema rec demo.cast
         | 
         | ,, then the recording is saved to a local file in asciicast 271
         | format."
        
         | thih9 wrote:
         | Any reason to suppose that? Any CLI tool (sending keystrokes or
         | not) that interacts with an api could do that too.
        
         | devsda wrote:
         | 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.
        
       | Lio wrote:
       | Keylogging as a service. ;)
       | 
       | 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.
        
         | sevg wrote:
         | 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).
        
           | w4yai wrote:
           | From the demo, it seems like the recording is uploaded on
           | their website by default. It is a bit concerning.
        
             | janosdebugs wrote:
             | It is not. You have to explicitly use the upload command to
             | share a recording.
             | 
             | You can also roll your own tool, the format is reasonably
             | well documented and simple.
        
             | ano-ther wrote:
             | From the docs - it gives you control:
             | 
             | > 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>.
        
         | the_duke wrote:
         | 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.
        
           | nabla9 wrote:
           | From https://asciinema.org/docs/how-it-works
           | 
           | > 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.
        
       | notum wrote:
       | I was looking for an example that does not have "asciinema.org"
       | in it. There is no way to self-host the player?
       | 
       | Without it this is just about as useful as Google Charts.
        
         | mkotowski wrote:
         | There is:
         | 
         | > 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.
        
           | notum wrote:
           | You've just made it awesome. Thank you!
        
         | feitingen wrote:
         | There is also the terminal app to play back the recording in
         | the terminal.
         | 
         | I find that to be the most useful player.
        
       | atoav wrote:
       | Every medium can be misused.
       | 
       | The bane of my existence are documentations that work with
       | asciinema instead of showing me short and concise code blocks.
        
       | pferde wrote:
       | 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?
        
         | upofadown wrote:
         | From the script man page:
         | 
         | >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.
        
       | nabla9 wrote:
       | > 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. .
        
         | phanimahesh wrote:
         | There's a local only mode. Uploads to asciinema.org are
         | optional.
        
           | nabla9 wrote:
           | Crazy dark pattern for a command line utility.
           | 
           | If you miss filename, recording goes to some server.
        
             | layer8 wrote:
             | Yep, recording and upload should really be two separate
             | commands by default.
        
             | wlamartin wrote:
             | When recording finishes you are given the option to upload
             | or save to local file.
        
           | layer8 wrote:
           | 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.
           | 
           | [0] https://asciinema.org/docs/how-it-works
        
       | d4rkp4ttern wrote:
       | 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.
       | 
       | https://github.com/sassman/t-rec-rs
        
       | wlamartin wrote:
       | 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.
        
       | denysvitali wrote:
       | An alternative: https://github.com/charmbracelet/vhs
       | 
       | By charm.sh
        
         | stavros wrote:
         | 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.
        
       | moyix wrote:
       | 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:
       | 
       | 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
       | 
       | Two weeks of logs (with fairly heavy usage) are about 1GB:
       | $ du -csh /fastdata/asciinema_personal/\*.zst | tail -1
       | 1.3G    total
        
       | leosanchez wrote:
       | Lot of cli programs use this tool to showcase their abilities. I
       | am truly grateful for it.
        
       | ku1ik wrote:
       | Hi, creator of asciinema here. Ask me anything!
        
       ___________________________________________________________________
       (page generated 2023-11-04 23:01 UTC)