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.
Eli the Bearded <*@eli.users.panix.com> writes:
3. I want to capture output from a curses program and have "cat" workWhat version of "script" are you using?
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.
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.)
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/
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/
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.
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.
Eli the Bearded <*@eli.users.panix.com> wrote:
1. I want to capture stuff and have it saved to disk rapidly, so thatThe man page for script on my system says
output is not lost in the case of a power interruption. I want text
capture for this.
-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'.
I don't recall ever seeing any terminfo capabilities which are for querying the terminal.
Also
rain -d 100 | tee some-file
[*] I'm using a "slowcat" program that adds delays for this. True "cat"I'm going on a tangent but does slowcat handle correctly the animations at http://vt100.net/dec/animation ?
is faster than "script -dp".
https://github.com/Eli-the-Bearded/vt100-slowcat
I really do want to capture "rain" output for that collection.
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 thatThe man page for script on my system says
output is not lost in the case of a power interruption. I want text
capture for this.
-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
Elijah
------
remembers when `eval resize` was a useful addition to .profile
Eli the Bearded <*@eli.users.panix.com> wrote:
Which script is that?Debian Linux. Your script doesn't have the -f option ?
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.htmlI had some trouble finding on the page the relevant part. It's
remembers when `eval resize` was a useful addition to .profileI take it that was before the time usual shells automatically set the
COLUMNS and LINES variables. I have in my shell environment the function
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 77:28:06 |
Calls: | 6,489 |
Files: | 12,096 |
Messages: | 5,276,375 |