script(1) improvement

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

script(1) improvement

Soumendra Ganguly
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 ]. 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). Please
consider merging the current NetBSD version into OpenBSD.

Note: There is a small bug that the FreeBSD and NetBSD versions have,
but I have submitted PRs for them; therefore, we can wait till NetBSD
patches their version! NetBSD PR:
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=55529.

Thank you.
Soumendra Ganguly

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Theo de Raadt-2
Soumendra Ganguly <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
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 <[hidden email]> wrote:

> Soumendra Ganguly <[hidden email]> 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Stuart Henderson
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 <[hidden email]> wrote:
> > Soumendra Ganguly <[hidden email]> 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.
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
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 <[hidden email]> 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 <[hidden email]> wrote:
>> > Soumendra Ganguly <[hidden email]> 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.
>> >
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
Theo,
      The replay feature does not make script(1) re-enter the
commands. It simply replays them on the terminal as if it were a video
[ like "cat typescript" but slower ]. It is particularly useful if
someone wants to replay [ not re-run ] a curses session [ such as a
game or an editing session on vi ].

I ended up writing my own program that has all the features that I
wanted. However, there are a few small changes that I propose for
usr.bin/script/script.c. I have not set up my VM to be able to use
sendbug(1). I sent my patch in a separate email with the following as
subject.

"[PATCH] script(1): Change openpty arguments if stdin is not a tty +
other small changes"

Thank you.

On 8/2/20, Soumendra Ganguly <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> > Soumendra Ganguly <[hidden email]> 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.
>>> >
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Theo de Raadt-2
Soumendra Ganguly <[hidden email]> wrote:

> Theo,
>       The replay feature does not make script(1) re-enter the
> commands. It simply replays them on the terminal as if it were a video
> [ like "cat typescript" but slower ]. It is particularly useful if
> someone wants to replay [ not re-run ] a curses session [ such as a
> game or an editing session on vi ].
>
> I ended up writing my own program that has all the features that I
> wanted. However, there are a few small changes that I propose for
> usr.bin/script/script.c. I have not set up my VM to be able to use
> sendbug(1). I sent my patch in a separate email with the following as
> subject.

well, that's not the purpose of script, to have a special mode, creating
special files, which only it can can handle

the name for when things like that get added is "scope creep".