what's better than script(1)?

[Eli the Bearded]

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

[Keith Thompson]

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.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Eli the Bearded]

In comp.unix.shell, Keith Thompson <Keith.S.T...@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

[Russell Marks]

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.

[Kenny McCormack]

In article <u4TbJ.1306989$fAMf.1...@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.

[Keith Thompson]

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.

[Spiros Bousbouras]

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

[Eli the Bearded]

In comp.unix.shell, Spiros Bousbouras <spi...@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

[Spiros Bousbouras]

On Wed, 20 Oct 2021 18:45:11 -0000 (UTC)

Eli the Bearded <*@eli.users.panix.com> wrote:
> In comp.unix.shell, Spiros Bousbouras <spi...@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

[Eli the Bearded]

In comp.unix.shell, Spiros Bousbouras <spi...@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)

[Jim Jackson]

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.