• what's better than script(1)?

    From Eli the Bearded@21:1/5 to All on Tue Oct 19 20:30:16 2021
    I use the script(1) program a lot to capture output from things I do. I've
    got three situations where I find script lacking. Generally each of
    these are separate uses, and I don't need one tool that can do them all.

    1. I want to capture stuff and have it saved to disk rapidly, so that
    output is not lost in the case of a power interruption. I want text
    capture for this.

    2. I want to capture stuff and have human readable time stamps, at least
    on a line per line basis. If I use "script -r" I can get a capture that
    is a binary file with binary time stamps (offset from start of
    script, and on a character per character basis). I'll also note that
    even using that, I find "script -p" never seems to work right. I have
    a capture that is 17 wall clock seconds from start to finish. It
    takes 71 seconds to play back as "script -p" or under 0.05 seconds
    with "script -dp". Neither is close to a realtime playback.

    3. I want to capture output from a curses program and have "cat" work
    to reproduce the same output. As an example, consider the BSD games
    program "rain". Capture and immediate playback[*] has corrupt output.
    It is the same terminal at the same size, so that's ruled out. I
    suspect that there are some curses interactive bits (where the
    terminal is queried and responds) that are breaking things. The
    only fix here might be a terminal definition (terminfo/termcap)
    that excludes interactive bits.

    Any suggestions?

    [*] I'm using a "slowcat" program that adds delays for this. True "cat"
    is faster than "script -dp".
    https://github.com/Eli-the-Bearded/vt100-slowcat
    I really do want to capture "rain" output for that collection.

    Elijah
    ------
    hasn't done serious terminal tweaking since using the tvi925 in college

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Eli the Bearded on Tue Oct 19 15:11:32 2021
    Eli the Bearded <*@eli.users.panix.com> writes:
    I use the script(1) program a lot to capture output from things I do. I've got three situations where I find script lacking. Generally each of
    these are separate uses, and I don't need one tool that can do them all.

    1. I want to capture stuff and have it saved to disk rapidly, so that
    output is not lost in the case of a power interruption. I want text
    capture for this.

    2. I want to capture stuff and have human readable time stamps, at least
    on a line per line basis. If I use "script -r" I can get a capture that
    is a binary file with binary time stamps (offset from start of
    script, and on a character per character basis). I'll also note that
    even using that, I find "script -p" never seems to work right. I have
    a capture that is 17 wall clock seconds from start to finish. It
    takes 71 seconds to play back as "script -p" or under 0.05 seconds
    with "script -dp". Neither is close to a realtime playback.

    3. I want to capture output from a curses program and have "cat" work
    to reproduce the same output. As an example, consider the BSD games
    program "rain". Capture and immediate playback[*] has corrupt output.
    It is the same terminal at the same size, so that's ruled out. I
    suspect that there are some curses interactive bits (where the
    terminal is queried and responds) that are breaking things. The
    only fix here might be a terminal definition (terminfo/termcap)
    that excludes interactive bits.

    Any suggestions?

    [*] I'm using a "slowcat" program that adds delays for this. True "cat"
    is faster than "script -dp".
    https://github.com/Eli-the-Bearded/vt100-slowcat
    I really do want to capture "rain" output for that collection.

    What version of "script" are you using? The version on my system
    (Ubuntu, "script" provided by bsdutils) doesn't have the options you
    mention. That version has a "-t[file]" or "--timing=[file]" option:

    Output timing data to standard error, or to file when given. This
    data contains two fields, separated by a space. The first field
    indicates how much time elapsed since the previous output. The
    second field indicates how many char‐ acters were output this time.
    This information can be used to replay typescripts with realistic
    typing and output delays.

    There's a separate "scriptreplay" command. (I haven't tried it.)

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli the Bearded@21:1/5 to Keith.S.Thompson+u@gmail.com on Wed Oct 20 01:49:23 2021
    In comp.unix.shell, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Eli the Bearded <*@eli.users.panix.com> writes:
    3. I want to capture output from a curses program and have "cat" work
    to reproduce the same output. As an example, consider the BSD games
    program "rain". Capture and immediate playback[*] has corrupt output.
    It is the same terminal at the same size, so that's ruled out. I
    suspect that there are some curses interactive bits (where the
    terminal is queried and responds) that are breaking things. The
    only fix here might be a terminal definition (terminfo/termcap)
    that excludes interactive bits.
    What version of "script" are you using?

    That was with NetBSD's system default. It does not print a version
    string. The man page shows a date from 2009, but "NetBSD 9.2" which
    is much newer than 2009.

    The version on my system
    (Ubuntu, "script" provided by bsdutils) doesn't have the options you
    mention. That version has a "-t[file]" or "--timing=[file]" option:

    Hmm. That does look like a _slightly_ more useful timing method.

    Output timing data to standard error, or to file when given. This
    data contains two fields, separated by a space. The first field
    indicates how much time elapsed since the previous output. The
    second field indicates how many char‐ acters were output this time.
    This information can be used to replay typescripts with realistic
    typing and output delays.

    There's a separate "scriptreplay" command. (I haven't tried it.)

    I just tried "script -t" / "scriptreplay" with rain, and it's still a
    mess. scriptreplay seems to do an even worse job with vi sessions
    than the NetBSD "script -r" / "script -p".

    Elijah
    ------
    could perl-up something to get line-by-line numbers from the -tfile

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russell Marks@21:1/5 to Eli the Bearded on Wed Oct 20 11:29:30 2021
    Eli the Bearded <*@eli.users.panix.com> wrote:

    I use the script(1) program a lot to capture output from things I do. I've got three situations where I find script lacking. Generally each of
    these are separate uses, and I don't need one tool that can do them all.

    1. I want to capture stuff and have it saved to disk rapidly, so that
    output is not lost in the case of a power interruption. I want text
    capture for this.

    2. I want to capture stuff and have human readable time stamps, at least
    on a line per line basis. If I use "script -r" I can get a capture that
    is a binary file with binary time stamps (offset from start of
    script, and on a character per character basis). I'll also note that
    even using that, I find "script -p" never seems to work right. I have
    a capture that is 17 wall clock seconds from start to finish. It
    takes 71 seconds to play back as "script -p" or under 0.05 seconds
    with "script -dp". Neither is close to a realtime playback.

    3. I want to capture output from a curses program and have "cat" work
    to reproduce the same output. As an example, consider the BSD games
    program "rain". Capture and immediate playback[*] has corrupt output.
    It is the same terminal at the same size, so that's ruled out. I
    suspect that there are some curses interactive bits (where the
    terminal is queried and responds) that are breaking things. The
    only fix here might be a terminal definition (terminfo/termcap)
    that excludes interactive bits.

    Any suggestions?

    For the third case (and in some ways the second), I think ttyrec for
    recording and maybe ipbt for playback might be suitable. The Debian
    package for ttyrec includes several patches, so it might be preferable
    to use that version (or just apply their patches manually).

    I do vaguely remember having some issues with colour when I last ran
    ipbt, which I don't think I ever looked into. But I think other
    players for the ttyrec format exist anyway.

    Some links:

    http://0xcc.net/ttyrec/
    http://deb.debian.org/debian/pool/main/t/ttyrec/ttyrec_1.0.8.orig.tar.gz
    http://deb.debian.org/debian/pool/main/t/ttyrec/ttyrec_1.0.8-5.1.debian.tar.xz
    https://www.chiark.greenend.org.uk/~sgtatham/ipbt/

    -Rus.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to zgedneil@spam^H^H^H^Hgmail.com on Wed Oct 20 12:43:56 2021
    In article <u4TbJ.1306989$fAMf.1303353@usenetxs.com>,
    Russell Marks <zgedneil@spam^H^H^H^Hgmail.com> wrote:
    ...
    For the third case (and in some ways the second), I think ttyrec for >recording and maybe ipbt for playback might be suitable. The Debian
    package for ttyrec includes several patches, so it might be preferable
    to use that version (or just apply their patches manually).

    Yes, I was just about to recommend ttyrec, but you beat me to it.

    I do vaguely remember having some issues with colour when I last ran
    ipbt, which I don't think I ever looked into. But I think other
    players for the ttyrec format exist anyway.

    Some links:

    http://0xcc.net/ttyrec/
    http://deb.debian.org/debian/pool/main/t/ttyrec/ttyrec_1.0.8.orig.tar.gz
    http://deb.debian.org/debian/pool/main/t/ttyrec/ttyrec_1.0.8-5.1.debian.tar.xz
    https://www.chiark.greenend.org.uk/~sgtatham/ipbt/

    Interestingly, ttyrec is in my Debian repository, but ipbt isn't. So,
    thanks for the link for that one. I'm reading it now.

    --
    You know politics has really been turned upside down when you have someone in the
    government with a last name of Cheney (Liz, Senator from Wyoming) who is the voice of
    reason.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Russell Marks on Wed Oct 20 10:43:14 2021
    Russell Marks <zgedneil@spam^H^H^H^Hgmail.com> writes:
    [...]
    For the third case (and in some ways the second), I think ttyrec for recording and maybe ipbt for playback might be suitable. The Debian
    package for ttyrec includes several patches, so it might be preferable
    to use that version (or just apply their patches manually).

    I do vaguely remember having some issues with colour when I last ran
    ipbt, which I don't think I ever looked into. But I think other
    players for the ttyrec format exist anyway.

    Some links:

    http://0xcc.net/ttyrec/
    http://deb.debian.org/debian/pool/main/t/ttyrec/ttyrec_1.0.8.orig.tar.gz
    http://deb.debian.org/debian/pool/main/t/ttyrec/ttyrec_1.0.8-5.1.debian.tar.xz
    https://www.chiark.greenend.org.uk/~sgtatham/ipbt/

    On Ubuntu (and probably Debian and other Debian-derived distributions),
    the "ttyrec" package provides the ttyrec and ttyplay commands, and
    "ttyplay" command), and the "its-playback-time" package provides the
    ipbt command.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Spiros Bousbouras@21:1/5 to Eli the Bearded on Wed Oct 20 17:55:35 2021
    On Tue, 19 Oct 2021 20:30:16 -0000 (UTC)
    Eli the Bearded <*@eli.users.panix.com> wrote:
    I use the script(1) program a lot to capture output from things I do. I've got three situations where I find script lacking. Generally each of
    these are separate uses, and I don't need one tool that can do them all.

    1. I want to capture stuff and have it saved to disk rapidly, so that
    output is not lost in the case of a power interruption. I want text
    capture for this.

    The man page for script on my system says

    -f Flush output after each write. This is nice for
    telecooperation: One person does `mkfifo foo; script -f foo'
    and another can supervise real-time what is being done using
    `cat foo'.

    [...]

    3. I want to capture output from a curses program and have "cat" work
    to reproduce the same output. As an example, consider the BSD games
    program "rain". Capture and immediate playback[*] has corrupt output.
    It is the same terminal at the same size, so that's ruled out. I
    suspect that there are some curses interactive bits (where the
    terminal is queried and responds) that are breaking things. The
    only fix here might be a terminal definition (terminfo/termcap)
    that excludes interactive bits.

    I don't recall ever seeing any terminfo capabilities which are for querying the terminal. Some terminal emulators provide some escape sequences of their own. In any case , it seems to me that your quickest option is to examine the source code of rain (which should be very short) and see if there's anything which would cause it not to play nice with your slowcat .

    Also

    rain -d 100 | tee some-file

    works for me to the extent that I see the usual rain output on the terminal and some-file gets some escape sequences. Have you tried your slowcat with such a set-up ?

    Any suggestions?

    [*] I'm using a "slowcat" program that adds delays for this. True "cat"
    is faster than "script -dp".
    https://github.com/Eli-the-Bearded/vt100-slowcat
    I really do want to capture "rain" output for that collection.

    I'm going on a tangent but does slowcat handle correctly the animations at http://vt100.net/dec/animation ?

    --
    vlaho.ninja/prog

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli the Bearded@21:1/5 to spibou@gmail.com on Wed Oct 20 18:45:11 2021
    In comp.unix.shell, Spiros Bousbouras <spibou@gmail.com> wrote:
    Eli the Bearded <*@eli.users.panix.com> wrote:
    1. I want to capture stuff and have it saved to disk rapidly, so that
    output is not lost in the case of a power interruption. I want text
    capture for this.
    The man page for script on my system says

    -f Flush output after each write. This is nice for
    telecooperation: One person does `mkfifo foo; script -f foo'
    and another can supervise real-time what is being done using
    `cat foo'.

    mkfifo! Hahaha, the old tricks. But last time I did that I used the
    "mknod foo p" method.

    Which script is that?

    I don't recall ever seeing any terminfo capabilities which are for querying the terminal.

    The most commonly used ones are the u[6789] sequenences.

    man resize
    ...

    • then resize asks the terminal for its size in characters.
    Depending on whether the "-s option is given, resize uses a
    different escape sequence to ask for this information.

    The resize command sends an cursor position request to go to 999,999
    then a cursor enquiry (u6) to get the response from the terminal (u8).
    Reading that response, it knows how big the terminal screen is.

    https://dickey.his.com/ncurses/terminfo.src.html

    Also

    rain -d 100 | tee some-file


    Hmmm. That didn't do it, but it gave me an idea.

    rain -d 100 < /dev/null | tee some-file

    That is not 100%, but is 99%. It still has an occaisonal glitch, but
    it is mostly working.

    [*] I'm using a "slowcat" program that adds delays for this. True "cat"
    is faster than "script -dp".
    https://github.com/Eli-the-Bearded/vt100-slowcat
    I really do want to capture "rain" output for that collection.
    I'm going on a tangent but does slowcat handle correctly the animations at http://vt100.net/dec/animation ?

    Yes. That's exactly the sort of thing it does. And it includes more
    videos than that site has.

    Elijah
    ------
    remembers when `eval resize` was a useful addition to .profile

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Spiros Bousbouras@21:1/5 to Eli the Bearded on Thu Oct 21 15:17:42 2021
    On Wed, 20 Oct 2021 18:45:11 -0000 (UTC)
    Eli the Bearded <*@eli.users.panix.com> wrote:
    In comp.unix.shell, Spiros Bousbouras <spibou@gmail.com> wrote:
    Eli the Bearded <*@eli.users.panix.com> wrote:
    1. I want to capture stuff and have it saved to disk rapidly, so that
    output is not lost in the case of a power interruption. I want text
    capture for this.
    The man page for script on my system says

    -f Flush output after each write. This is nice for
    telecooperation: One person does `mkfifo foo; script -f foo'
    and another can supervise real-time what is being done using
    `cat foo'.

    mkfifo! Hahaha, the old tricks. But last time I did that I used the
    "mknod foo p" method.

    Which script is that?

    Debian Linux. Your script doesn't have the -f option ?

    I don't recall ever seeing any terminfo capabilities which are for querying
    the terminal.

    The most commonly used ones are the u[6789] sequenences.

    man resize
    ...

    • then resize asks the terminal for its size in characters.
    Depending on whether the "-s option is given, resize uses a
    different escape sequence to ask for this information.

    The resize command sends an cursor position request to go to 999,999
    then a cursor enquiry (u6) to get the response from the terminal (u8). Reading that response, it knows how big the terminal screen is.

    https://dickey.his.com/ncurses/terminfo.src.html

    I had some trouble finding on the page the relevant part. It's

    # INTERPRETATION OF USER CAPABILITIES
    #
    # The System V Release 4 and XPG4 terminfo format defines ten string
    # capabilities for use by applications, <u0>...<u9>. In this file, we use
    # certain of these capabilities to describe functions which are not covered
    # by terminfo. The mapping is as follows:
    #
    # u9 terminal enquire string (equiv. to ANSI/ECMA-48 DA)
    # u8 terminal answerback description
    # u7 cursor position request (equiv. to VT100/ANSI/ECMA-48 DSR 6)
    # u6 cursor position report (equiv. to ANSI/ECMA-48 CPR)

    .Note that it actually says that the specific interpretations are not part
    of terminfo. man 5 terminfo gives

    user0 u0 u0 User string #0
    user1 u1 u1 User string #1
    user2 u2 u2 User string #2
    user3 u3 u3 User string #3
    user4 u4 u4 User string #4
    user5 u5 u5 User string #5
    user6 u6 u6 User string #6
    user7 u7 u7 User string #7
    user8 u8 u8 User string #8
    user9 u9 u9 User string #9

    I didn't read the dickey.his.com page carefully enough to see what he
    means by "In this file, we use" .I'm guessing it's some kind of notational extension specific to the page/file and not part of "standard" terminfo notation.

    [...]

    Elijah
    ------
    remembers when `eval resize` was a useful addition to .profile

    I take it that was before the time usual shells automatically set the
    COLUMNS and LINES variables. I have in my shell environment the function

    dims () { printf 'Lines : %d Columns : %d\n' `tput lines` `tput cols` ; }

    That's another method which works.

    --
    The delight of working in a medium so tractable - pure thought-stuff - which nevertheless exists, moves, and works in a way that word-objects do not.
    "The mythical man-month" by Frederick Brooks

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli the Bearded@21:1/5 to spibou@gmail.com on Thu Oct 21 17:21:13 2021
    In comp.unix.shell, Spiros Bousbouras <spibou@gmail.com> wrote:
    Eli the Bearded <*@eli.users.panix.com> wrote:
    Which script is that?
    Debian Linux. Your script doesn't have the -f option ?

    Actually it does. I don't know how I missed that before.

    -f Flush output after each write. This is useful for watching
    the script output in real time.

    then a cursor enquiry (u6) to get the response from the terminal (u8). Reading that response, it knows how big the terminal screen is. https://dickey.his.com/ncurses/terminfo.src.html
    I had some trouble finding on the page the relevant part. It's

    Search for u6 and u8 ?

    remembers when `eval resize` was a useful addition to .profile
    I take it that was before the time usual shells automatically set the
    COLUMNS and LINES variables. I have in my shell environment the function

    I can recall SIGWINCH being a new signal.

    Elijah
    ------
    resize is an X11 tool (at least these days)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Jackson@21:1/5 to Eli the Bearded on Thu Oct 21 19:22:42 2021
    On 2021-10-19, Eli the Bearded <*@eli.users.panix.com> wrote:
    2. I want to capture stuff and have human readable time stamps, at least
    on a line per line basis. If I use "script -r" I can get a capture that
    is a binary file with binary time stamps (offset from start of
    script, and on a character per character basis). I'll also note that
    even using that, I find "script -p" never seems to work right. I have
    a capture that is 17 wall clock seconds from start to finish. It
    takes 71 seconds to play back as "script -p" or under 0.05 seconds
    with "script -dp". Neither is close to a realtime playback.

    Not for the faint-of-heart, but if you are an old kermit hand then ...

    I've used ckermit when I wanted timestamped lines. I use kermit over
    serial lines mainly when connecting to linux based SBCs with serial
    console the timestamps are often useful when fine tuning booting. You
    can use ssh within kermit, so occasionally when I need to timestamp log
    output, I ssh to localhost and do stuff there.

    A long time ago I used to script kermit connections so it wasn't _too_ difficult getting back into it.

    Not sure it's want you want though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)