Replies: 3 comments 7 replies
-
|
Adding a progress bar to the scriptreplay would be challenging because it would affect the output. We would need to keep the progress bar in the same place, but allow the rest of the output to continue moving with line breaks. Note that typescript may contain output in terminal raw mode, no line breaks (ncurses etc.). One potential solution could be an on-demand progress bar. By pressing a specific key or pausing the output, the typescript printing would stop, and the progress bar would appear. Releasing the key would erase the progress bar and return the original data to the line, allowing the typescript to continue playing. |
Beta Was this translation helpful? Give feedback.
-
|
What about an option in scriptreplay that showed always a progress bar (and an option that never shows a progress bar, even when paused)? |
Beta Was this translation helpful? Give feedback.
-
|
The problem is that you need to reduce the terminal size for the session; within the section, the size will be $LINES-1. I'm not sure if it would be a big problem. |
Beta Was this translation helpful? Give feedback.
-
|
A terminal command has the ability to set its own terminal size (with an option)? Or, at least, to check the size of it (with an option) and fail if it's different, or just if it's smaller (but what if the user had changed the size while recording?). I have been trying recordings and replays and I think that the replay command should automatically clear the screen at first, wrap the lines when the recording width is exceeded (for wider screens to not show trash) and use only the first N (recording height) rows (for taller screens to not show trash). This way, a big enough screen would be able to replay any recording properly, I think, given that the timig file includes the number of columns and rows. |
Beta Was this translation helpful? Give feedback.
-
|
Also, I suggested an option to not adding a progress bar row but instead painting the progress bar in the las line's background color, this wouldn't alter the replay size. |
Beta Was this translation helpful? Give feedback.
-
|
Note also #2999 |
Beta Was this translation helpful? Give feedback.
-
|
I think seeking backward can be useful if the user misses something in the script replay (I'm thinking about me at least) (don't know if I should comment this here or in the closed issue). |
Beta Was this translation helpful? Give feedback.
-
|
Ad server: I can imagine an improvement that would allow for the use of a URI in the This would establish a connection and write the session content to the connection instead of a local file. The process would look something like this: To implement this, the The advantage of this approach is that it eliminates the need for any network-related code in the script itself, making it compatible with any type of connection (not just SSH). The ideal implementation should also use script-compatible binary on the remote side. would be internally where the |
Beta Was this translation helpful? Give feedback.
-
|
Would it be possible for the server side to write the timing info? Cause the client-side timing might not be trustworthy. Or there would be too much lag for the server-side timing data to be usable for a replay? Maybe two timing files, the client side and the server side? And what about the client-side authentication? An option to authenticate with a username+password? For SSH, there would have to be at least an option to specify the id file. There should be something in the timing file that identifies the user that made the connection (minimum IP, host name and username/public key/certificate). What about TLS? HTTPS might be the alternative to SSH? And the format of the data passed to the server: binary? (8 bytes for timing; letter i or o; rest of bytes for input/output) CSV? (1.12;f;) JSON? ({"d": 1.12, "input": f}) |
Beta Was this translation helpful? Give feedback.
-
|
For the server, I think about it as we have done in git; all is done by ssh-client (key/password). |
Beta Was this translation helpful? Give feedback.
-
Hi! I teach Linux commands and shell scripting and I'm thinking about auditing my students' terminals at shell scripting exams (just in case I suspect someone copied) with the
script/scriptreplaycommands. It is possible for me to do that (and I will probably try it in the next shell exam), but I'm thinking about two enhancements to thescriptthing:scriptplayer, likescriptreplay, but with a time bar at the bottom, a time elapsed/total time tag at the end of the bar and support for advancing, jumping to some time code (MM[:SS]), etc.Anyway, feedback about these ideas would be welcome (even if somebody has a better alternative to the
scriptauditing). Someday, if I have enough time and nobody else is interested in these, I may contribute this project with the player or the latter command myself (in case the maintainers want them).Beta Was this translation helpful? Give feedback.
All reactions