# Rust rewrite of the asciinema CLI

**URL:** <https://discourse.asciinema.org/t/rust-rewrite-of-the-asciinema-cli/777>\
**Category:** Announcements\
**Tags:** rust, cli\
**Created:** [December 20, 2023, 2:29pm UTC](https://discourse.asciinema.org/t/rust-rewrite-of-the-asciinema-cli/777 "2023-12-20T14:29:01Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![ku1ik](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.asciinema.org/ku1ik/32/171_2.png) [@ku1ik](https://discourse.asciinema.org/u/ku1ik)\
**Post date:** [December 20, 2023, 2:29pm UTC](https://discourse.asciinema.org/t/rust-rewrite-of-the-asciinema-cli/777/1 "2023-12-20T14:29:01Z")

</div>

Yes, it’s happening 🙂

I’ve contemplated the rewrite of asciinema CLI for several years, but I didn’t have as many good reasons (and time) to justify it in the past. Python served us well for the last 12 years, however, there’s plenty of good reasons to do the Rust rewrite now.

Among other things, the rewrite will (in random order):

- minimize runtime dependencies thanks to static binary produced by the Rust compiler - e.g. no more need for having Python interpreter installed on a recorded server or in a container
- allow easy integration of [avt](https://github.com/asciinema/avt) (which is written in Rust) to implement things like conversion to pure text (`asciinema convert demo.cast demo.txt`), also give asciinema insight into what is actually happening in a terminal during a recording session, potentially enabling many cool features
- allow easy integration of [tst](https://github.com/asciinema/tst) (which is written in Rust) to implement terminal live streaming (`asciinema stream`)
- allow easy integration of [agg](https://docs.asciinema.org/manual/agg/) (which is written in Rust), potentially as `asciinema convert demo.cast demo.gif`, so one doesn’t need to install a separate tool to generate a GIF
- enable code sharing (where it makes sense) between the CLI and the [web player](https://docs.asciinema.org/manual/player/), as the player already uses Rust/WASM
- make startup faster - nice to have when automatically recording (“logging”) all shells/terminal tabs to a directory
- make me happy as I enjoy working with Rust much more than with Python these days 🙂

Current Python codebase is small (~2800 LOC) so it’s not really a big endeavour.

I started working on the rewrite in the [`develop` branch](https://github.com/asciinema/asciinema/tree/develop). This will become asciinema CLI 3.0 (I’ll post about the greater plan for 3.0 soon). The original Python implementation (2.x) stays in the [`main` branch](https://github.com/asciinema/asciinema/tree/main) for now, and will be kept in an archive branch (`v2`) for the foreseeable future (~forever).

So far I have the `asciinema rec`, `asciinema upload` and `asciinema auth` commands implemented. They seem to work fine, although I tested on Linux only so far.

If you’d like to help testing it check the building instructions here: [Testing the new Rust version of the asciinema CLI](https://discourse.asciinema.org/t/testing-the-new-rust-version-of-the-asciinema-cli/778)

UPDATE: [The plan for the asciinema CLI 3.0](https://discourse.asciinema.org/t/the-plan-for-the-asciinema-cli-3-0/790)

---

<div class="post-metadata">

**Author:** ![wez](https://avatars.discourse-cdn.com/v4/letter/w/edb3f5/32.png) [@wez](https://discourse.asciinema.org/u/wez)\
**Post date:** [January 22, 2024, 3:21pm UTC](https://discourse.asciinema.org/t/rust-rewrite-of-the-asciinema-cli/777/2 "2024-01-22T15:21:08Z")

</div>

FWIW, when it comes to cross platform (including Windows!) support, you may want to consider using the [portable\_pty - Rust](https://docs.rs/portable-pty/latest/portable_pty/) crate which I use in my own stripped down version of the recorder/player that I ship in wezterm: [wezterm/wezterm/src/asciicast.rs at main · wez/wezterm · GitHub](https://github.com/wez/wezterm/blob/main/wezterm/src/asciicast.rs)

---

<div class="post-metadata">

**Author:** ![ku1ik](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.asciinema.org/ku1ik/32/171_2.png) [@ku1ik](https://discourse.asciinema.org/u/ku1ik)\
**Post date:** [January 23, 2024, 8:57am UTC](https://discourse.asciinema.org/t/rust-rewrite-of-the-asciinema-cli/777/3 "2024-01-23T08:57:29Z")

</div>

Thanks Wez.

I looked into portable\_pty, among others, when approaching implementation of PTY handling, but decided to implement it using the nix crate, which is more low level but gives me more control. Ended up with [asciinema/src/pty.rs at develop · asciinema/asciinema · GitHub](https://github.com/asciinema/asciinema/blob/develop/src/pty.rs) , which appears to work well on both Linux and macOS (yet to test it on FreeBSD).

asciinema has never supported Windows natively, and I’m not planning to change that. The previous Python impl worked fine under WSL (from what I’ve heard). We’ll see how the new one fares there.

Out of curiosity, what does portable\_pty use on Windows? Is it ConPTY, or something else? If ConPTY, how is its compatibility with control sequences and behaviors commonly seen on UNIX-like systems?

---

<div class="post-metadata">

**Author:** ![wez](https://avatars.discourse-cdn.com/v4/letter/w/edb3f5/32.png) [@wez](https://discourse.asciinema.org/u/wez)\
**Post date:** [January 23, 2024, 1:52pm UTC](https://discourse.asciinema.org/t/rust-rewrite-of-the-asciinema-cli/777/4 "2024-01-23T13:52:37Z")

</div>

it uses conpty on Windows. I think you won’t really care about the differences in escape sequences used there; it’s actually pretty compatible with commonly used xterm features. I don’t have any windows specific quirks in my asciicast record/replay implementation.

One interesting observation is that conpty will synthesize some initial OSC sequences to set the title to the process name when first spawning a command.

---

<div class="post-metadata">

**Author:** ![ku1ik](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.asciinema.org/ku1ik/32/171_2.png) [@ku1ik](https://discourse.asciinema.org/u/ku1ik)\
**Post date:** [January 24, 2024, 2:22pm UTC](https://discourse.asciinema.org/t/rust-rewrite-of-the-asciinema-cli/777/5 "2024-01-24T14:22:13Z")

</div>

Good to know, thanks. Will keep that in mind if I’ll reconsider Windows support 🙂

---

<div class="post-metadata">

**Author:** ![ofek](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.asciinema.org/ofek/32/506_2.png) [@ofek](https://discourse.asciinema.org/u/ofek)\
**Post date:** [February 8, 2024, 1:39am UTC](https://discourse.asciinema.org/t/rust-rewrite-of-the-asciinema-cli/777/6 "2024-02-08T01:39:18Z")

</div>

As a long time Windows user it would be very nice to have your software work for us! I understand that you view emulation as an adequate workaround but that doesn’t consider software that only works on Windows. In such cases we simply have no option to record elsewhere.

---

<div class="post-metadata">

**Author:** ![ku1ik](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.asciinema.org/ku1ik/32/171_2.png) [@ku1ik](https://discourse.asciinema.org/u/ku1ik)\
**Post date:** [February 8, 2024, 9:09pm UTC](https://discourse.asciinema.org/t/rust-rewrite-of-the-asciinema-cli/777/7 "2024-02-08T21:09:14Z")

</div>

I’m sure Windows support would be welcomed by many, and I’m willing to reconsider my position, although _after_ 3.0 is released. Then we can look into how to approach this topic 👍