You might want to check what your shell does, as this relies on auto-completion doing the same thing if you replay the same keystrokes, even if that happens faster. Specifically, try to intercept the output of the last pipe into a

less -U and look if that seems to be what you were typing. If you want, you can replay the special chars by pressing Ctrl+<whatever symbol is followed by the caret>. Try to not use a fancy auto-completion like fish or fzf provides you with, as they tend to not be the same when doing a replay.

This should not be hard, I used bash succesfully. I hope you did not forget to run it on the same filesystem state, as far as auto-complete behavior during the asciicast is concerned.

Also, this could be improved by delaying the replay as long as specified by the asciicast. But I couldn't quickly figure out how to get that done without further dependencies, so I won't provide that (now).

This script filters for input keys from the asciicast with the

  select("i" == .[1]?)

and then extracts only the string itself with

  .[2]

. I'd like to understand what is going wrong, but this style of debugging isn't working. I won't debug it on your system unless you find a way to make that sufficiently productive for me. And I really hope you created the file with --stdin, but judging from ls barfing on a non-existent file/directory, I assume the shell it spawned just did not result in ls being called with the same name, due to auto-complete changing it's behavior.