Wow - happens rare but I really can't understand your answer. I never would have guessed jq to have any use for presentation. Can you give a short example how to apply your script.

Uh, just feed it the resulting file from

  asciinema rec --stdin

and it will execute whatever was in there. If some programs were reading more than they actually wanted, it would have trouble, because they would likely get fed further commands/input, which would no longer go to the shell/later program.

Regarding the script, it's just using jq because asciinema uses a JSON-based format, of which some data needs to be extracted. It should be self-evident from looking at what jq is doing and what an interactive shell does different from a non-interactive one (hint: it's related to autocompletion), as well as a sample file created by the above command. If you still don't understand, tell, and I'll try to explain better.

And sorry for the delay, I wasn't expecting a timely response that asks me for something.

Thanks for the reply. Doesn't happen every day someone answers your sorrows with a two liner. I don't really see at what points it is checking for my pressed keys. I just was able to try your snippet. Unfortunately I do not get it to work - I just end up with lines like `ls: no such file or directory`.

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.

I appreciate your guidance. I don't expect you to debug it.

But it seems to me we were using the term "live" differently. I think I understand now that the code you provide runs the recording on the current machine - similar to a macro. The live mode I was referring from pias takes the recording - but times the keystrokes to what you type during the presentation - so one doesn't need to check. Makes also a nice trick for showing off as one can do fun stuff like type with your feet. Ah I see - they call this "manual typing", and have a "Live Replay" - just as you suggested. So it was me being inprecise - sorry.

You were right the errors I was experiencing had to do with the shell. I use fish - forcing everything to use bash made previous errors disappear. However in my test recording the it got stuck in vim - suppose escape didn't work.

Escape should work, you'd wanna check the keys around that tho. It might be a timing issue. The requirement to not use fish in that mode is just due to fish exhibiting hidden non-constant state. I did think about how to do that timing, but I could not figure out how to do it. It should be a very short python script or so tho, just replace the 'jq ksjdfkasjdfk |' with a script that reads the newline-delimited JSON and waits until the next timestamp, sends that data to the shell, and parses the next JSON. You'd just have to get a system time at the beginning, and not just sleep for the offset between the timestamps in the JSON, as you'd be slower by as much as the inaccuracy from the system sleep call and the processing you have to do to extract the data from the JSON. But otherwise this should yield a timing predictable enough for such a live replay. The escape char seems to be kinda weird indeed. I'm not sure where that issue is tho.