Hacker News Reader

Comment by wildduck | Hacker News Reader

Don't know if I want to a script that records my terminal session and upload the recording to an external server. Is there a way to keep the recording local?

View on HN

asciinema is open-source and the file format is publicly documented (asciicast)[1]. You can run `asciinema rec filename.json` to save the file locally and self-host it with asciinema-player[2]. Alternatively, there's also asciicast2gif[3] that converts asciicast json to GIF image.

[1]: https://github.com/asciinema/asciinema/blob/master/doc/ascii...

[2]: https://github.com/asciinema/asciinema-player

[3]: https://github.com/asciinema/asciicast2gif

About a year ago, I hacked on an internal project that was exploring command-line interactions as code. Think of it like an animated CLI documentation factory. I believed and continue to believe, that short CLI animations give context to CLI usage and allow pause/copy/paste (game changer for watchers) if not in svg/gif which helps with consumability. Problem in my mind has always been keeping them up to date at scale (or their educational value diminishes). The project had a git repo that housed a collection of files following a light-weight syntax. Some complementary tooling "understood" this syntax and could create asciinema recordings while controlling pacing and execution. We then evolved this workflow into a FaaS triggered via PR and a github bot. Would like to potentially open-source the whole thing if I find some time to go through our internal approvals.

NET: Folks could add to the corpus following the modular syntax and issue a PR. About 3-5 minutes later, comments on the PR stream would have an animated svg/gif generated and added by the bot for review. If you liked how it looked, you accepted the PR. This corpus could then grow and be updated with minimal effort. A version of the client was modded to support self-signed certs and block accidental public upload. We ported asciinema to a helm chart that could run multiple versions on a k8s cluster per ingress path to complete the story. The whole apparatus existed entirely behind the firewall.

Please open source this if you can!

You might be able to create something similar by combining expect with asciinema, like

  $ expect_command='
  log_user 0
  spawn bash
  interact timeout 1 return
  send "ps aux | rg asciinema\n"
  interact timeout 3 return
  exit
  '
  $ asciinema rec somefile -c 'expect -c '\'"$expect_command"\'

using interact timeout as a sort of checkpoint to show output, though if you want to send single quotes you'll have to make sure they get escaped in the inner command (or just have the script in a file for expect to read)

Has anyone experiences with asciicast2gif?

On the surface this looks just like what's needed to make this work for me: I like the recording tools, but don't want to be forced to embed a player from a third party service.

Looks like asciinema2gif relies on PhantomJs which brings withit an entire browser and is also no longer maintained. This looks very bloaty for a tool that should convert terminal input to a gif file.

Is it working relieably and reasonably fast?

I've written an incomplete ad-hoc renderer in Go: https://github.com/akavel/asciinema2gif — it worked in one case where I needed it personally, but it's missing support for a lot of escape sequences, so it most probably Won't Work For You As Is. But you're free (as in AGPL) and welcome to play with it if you like!

I've only tried it few times via their official docker image; it's reasonably fast (a minute of asciicast took about a minute to convert), but PhantomJS/ImageMagick do put some load on the CPU while it's generating/combining frames. I never had any problems when I need to make a GIF, but the conversion process does indeed seems very wasteful.

Whether it is FOSS doesn't really contribute anything to solve the problem GP mentions though. The default behavior is to nudge the user to upload. One must assume this is the part of the design which allows potential monetization one day. Obviously the author may not be keen to point out this giant gap in the security of their design (it is in fact the main feature).

Users might not even think about the security risks this could create. From an enterprise security perspective this is indistinguishable from any (malicious) data-exfiltration tool. It should come with a giant warning and better defaults imo.

> One must assume this is the part of the design which allows potential monetization one day.

Oh, heaven's no! Someone might at some point try to make money from a thing they made?! From their own labor?! How awful!

Seriously: it's a stupendous tool and great service, provided free of charge and totally open source. Must we complain about the fact that they try to nudge you towards their tracking-free website, so you can see the tiny "Sponsored by Brightbox" rectangle in the footer, so that the project might yield some tiny financial return (though almost certainly not anywhere close to development costs)?

It seems to me that they've done absolutely everything right except possibly live up to the standard that apparently all open source tools should be developed by starving ascetic monks. Come on.

> The default behavior is to nudge the user to upload.

It's not that bad, if you do not provide a filename, by default it asks for confirmation before uploading. It's still easy to upload by accident[1] though, which I know is no-go in some environment.

[1]: https://github.com/asciinema/asciinema/issues/316

A while ago I played around, and create a small tool that can do that: https://github.com/elisescu/goscript

It's a single binary (as cross platform as golang gets), which records a terminal session into a single html file which you can open for playback in the browser.

Any feedback is very much welcome :)

Check out ttyrec.

Yes, you can use screen cap software, and then convert it to ASCII or gifs.

Reply on news.ycombinator.com