Stuart, Sorry. I should have clarified. It does not re-enter the commands. If [-r] is used, then extra timing information is recorded into the typescript file, which can later be used by [-p] to replay the session [ like a video ] on the terminal. The patch to which I was referring enables proper curses playback; therefore, one can now watch an editing session on vi being replayed at a later time. While "cat typescript | less" suffices in many cases, proper timing information is necessary for the playback of curses sessions.
I was not requesting a feature which re-runs the commands; although util-linux seems to have a program called "scriptlive" which does exactly that. Thank you. Soumendra On 8/2/20, Stuart Henderson <[email protected]> wrote: > What does the replay feature actually do? Does it re-enter the commands > or just display the console output (like "cat typescript", but slower)? > > > On 2020/08/01 22:23, Soumendra Ganguly wrote: >> Theo, >> Thank you for the feedback. I can understand why some of that >> functionality might be unnecessary if one only needs a hard copy of >> the terminal session. That is why [-r], [-p] are not applied by >> default. >> >> My patch for NetBSD script(1) has been accepted now. I will submit a >> PR to OpenBSD soon. >> >> Thank you. >> Soumendra >> >> On 8/1/20, Theo de Raadt <[email protected]> wrote: >> > Soumendra Ganguly <[email protected]> wrote: >> > >> >> Hello, OpenBSD! >> >> I am using script(1) to complement a program that I am writing. >> >> However, the current OpenBSD version of script(1) is very old [ based >> >> on NetBSD script(1) version 1.3 ]. >> > >> > First off, it is not old. We don't automatically grab changes from >> > completely distinct. It has been completely seperate code for over 20 >> > years. Once in a while, an idea will show up, and get copied. >> > >> >> It does not have the [-r] and [-p] >> >> options that the current NetBSD version [ 1.21 ] does. FreeBSD's >> >> script(1) also has this functionality; util-linux provides similar >> >> functionality in the form of script(1)+scriptreplay(1). >> > >> > I am horrified by what I see; I could never see myself needing that >> > type of functionality, since it is so fragile. >> > >> > A replay of a sequence of previously issued commands will work fine for >> > very small steps, but when used for increasingly large missions it >> > quickly turns into a shitshow. >> > >> > The sequences captured will not generally contain error condition >> > checking along the way. Therefore, input will be continue to be >> > injected even if a ecommand in the replay-case behaves different. >> > >> > This is effectively the same as software which is written without >> > checking >> > error returns at every step, we encourage all re-useable software to be >> > written with error checks at every step, why add a subsystem which goes >> > against the grain? >> > >> > I think we should discourage new systems which behave like that. >> > >> >> Please consider merging the current NetBSD version into OpenBSD. >> > >> > Sorry, that is not how the development process in this project works. >> > >> >
