You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the program can read commands to be recorded, then it will be easy to automate regression testing during CI job (and local development). Example of simple end-user test where commands are read from stdin, line-by-line:
i don't want to complicate this program to add those features, and i don't think it's a really good idea to allow a "recording" software to execute commands, security wise.
i still don't know what is causing the issue that the program is failing to record second time, i am looking into it.
I share your point of view on features. But this kind of automatic test could help figuring out source of problems - if test passes on all CI, but not on user device, then there is probably something with user-specific configuration.
I've found that all known (to me) terminal recorders allows to specify command to be executed inside recorded session:
asciinema rec -e 'echo "test_string"' test_rec.cast (source)
Commands are specified by flag, because input from stdin can never end (for example yes | grep "n").
From my understanding of security there is no difference between writing recorder -c command and recorder then command.
When I run
termrec
second time, new shell exits immediately and it is impossible to record any commands:If the program can read commands to be recorded, then it will be easy to automate regression testing during CI job (and local development). Example of simple end-user test where commands are read from stdin, line-by-line:
The text was updated successfully, but these errors were encountered: