asciinema / asciinema

Terminal session recorder ๐Ÿ“น

Home Page:https://asciinema.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for automation?

tmpfs opened this issue ยท comments

commented

Hey @ku1ik,

Thanks for the tool, it's really cool. I needed to do some automation for CLI demos and wrote a little tool called anticipate based on rexpect which seems to work fine.

It runs asciinema in a pty and sends instructions to the pty based on an input script file.

I was wondering if you had any desire to roll this in to the main executable as a sub-command?

I can imagine quite a few people would benefit from this.

I have tried to keep the code lean, so there are not too many dependencies and probably a few of them are already in the dependency tree.

Wonder what you think.

Hey!

Have you seen https://github.com/k9withabone/autocast ? It seems to be quite similar to what you got there. Also, check https://docs.asciinema.org/integrations/ for a list of other integrations.

I don't plan to roll scripted cast generation in to the CLI, as of now, but never say never :)

What I was thinking about though is providing a scripting API for rec command in the form of a UNIX socket (or sth similar), which can be used to control the session programatically. Something that would let you read output and write input to the session in real-time. Like Docker's control socket, but for asciinema rec. This would let you create a tool like anticipate (or mentioned autocast) by simply spawning asciinema rec --control-socket /path/to/socket demo.cast, then controlling it via the socket. This is a rough idea for now, but I think there's potential there.

commented

Thanks for the links @ku1ik, autocast looks cool and I wish I had seen it earlier however I am not a big fan of the YAML config and think the leaner shell script syntax anticipate uses is friendlier. In particular I appreciate the link because I found expectrl which has a much nicer API than rexpect so I switched over ๐Ÿ˜

I understand that you don't want to add this functionality as a subcommand, I think it would be useful not to have to hunt down and evaluate other tools but hey it's your baby! Later, once I am happy with it I will add anticipate to the list of integrations.

I like the idea of scripting recordings over a socket, it would help performance a little not to have to launch asciinema for every script I want to record, not sure it would have a major impact but certainly be a little faster for tools like anticipate. Only problem is that on windows would have to use named pipes - maybe something like this. And I would be able to avoid this kind of messy argument wrangling ๐Ÿ‘

FYI, I found a bug with the webassembly player but I will put it in a separate issue.

Windows is currently not supported anyway so that's not a concern for me (and even if/when it would be supported this is non-essential feature that could just be not available on there).

My idea for a socket isn't about having a long-running "server-like" asciinema process that you would re-use. Rather, it's about launching asciinema rec like it's always been, for a single session, just with the additional means of control and inspection available via such a socket. So you'd still need launch it per recording and deal with args.

Anyway, this is just an early idea, need to give it more thought :)

Feel free to send a PR for integrations page in the docs repo when ready ๐Ÿ‘