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 <dera...@openbsd.org> wrote: > > Soumendra Ganguly <soumen...@tamu.edu> 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. > > >
