[GH-ISSUE #619] Support for automation? #935

New issue

Closed

opened 2026-03-15 11:03:53 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 11:03:53 +03:00

Owner

Originally created by @tmpfs on GitHub (Feb 14, 2024).
Original GitHub issue: https://github.com/asciinema/asciinema/issues/619

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.

Originally created by @tmpfs on GitHub (Feb 14, 2024). Original GitHub issue: https://github.com/asciinema/asciinema/issues/619 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](https://github.com/tmpfs/anticipate/) based on [rexpect](https://docs.rs/rexpect/latest/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](https://github.com/tmpfs/anticipate/blob/main/core/Cargo.toml#L8-L16) and probably a few of them are already in the dependency tree. Wonder what you think.

kerem closed this issue

2026-03-15 11:03:58 +03:00

kerem commented

2026-03-15 11:04:04 +03:00

Author

Owner

@ku1ik commented on GitHub (Feb 15, 2024):

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.

@ku1ik commented on GitHub (Feb 15, 2024): 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.

kerem commented

2026-03-15 11:04:09 +03:00

Author

Owner

@tmpfs commented on GitHub (Feb 16, 2024):

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.

@tmpfs commented on GitHub (Feb 16, 2024): 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](https://docs.rs/interprocess/latest/interprocess/os/windows/named_pipe/). And I would be able to avoid this kind of [messy argument wrangling](https://github.com/tmpfs/anticipate/blob/main/core/src/interpreter.rs#L107-L134) 👍 FYI, I found a bug with the webassembly player but I will put it in a separate issue.

kerem commented

2026-03-15 11:04:14 +03:00

Author

Owner

@ku1ik commented on GitHub (Feb 16, 2024):

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 👍

@ku1ik commented on GitHub (Feb 16, 2024): 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 :+1: