script(1) plans

script(1) plans

[Karel Zak]

Hi all,

I'd like to improve script(1) to be more flexible and support more
streams. The current version allow to log only output, but I'd like to
add possibility to log input, signals and more details about the
session.

The idea is to introduce a new timing file format; and use it in case
a new features are requested by user on script(1) command line. The
new format will be still based on text and easy to convert to the old
version.

* New options:

 --log-out <file>	    log output to <file>
 --log-in <file>        log input to <file>
 --log-io <file>        log both input and output to <file>
 --log-timing <file>    timing file (alias to --timing[=<file>])
 --no-signal            don't log signals

The all --log-* options enables the new format, otherwise old format is used.

 script --timing[=<file>] <file>              := old timing file format

 script --log-timing <file> --log-out <file>  := new format

Note that the current --timing uses optional argument and the default
is log timing information to the stderr. This crazy feature will be
deprecated and unsupported for the new --log-timing <file>.


* Another new feature is --json (mutually exclusive to --log-timing), in this
case log data and timing information will be merged together:

 {
    "version":"2.33.1",
    "term":"xterm",
	
    "log": [
      { "type":"in",  "delta":1.930626, "data":"ls" },
      { "type":"out", "delta":0.123356, "data":"some crazy data" },
      { "type":"sig", "delta":0.500000, "name":"SIGWINCH", "columns":50, "lines":20 },
      ...
    ]
 }


* logs redirection (pipe) to another commands:

 --log-out-cmd <cmd>
 --log-in-cmd <cmd>
 --log-io-cmd <cmd>

The redirection will be possible to use with --json too.


* The new (multi-stream) timing file format:

    <type> <timestamp> [<offset> | <signal> ...]

     # comment
     H NAME=<value>
     H ...
     O 0.001296 256
     S 0.001297 SIGWINCH: columns=50, lines=20
     I 0.000010 10

 H : header (VERSION=, TERM=, STARTTIME=, EXITCODE=, COLUMNS=, LINES=, COMMAND= ...)
 O : output
 I : input
 S : signal

 Conversion to the old version:

	awk '/^O / { print $2" "$3 }'

		
* scriptreplay(1) will be extended to autodetect and support the new format and
  print summary about the session, new options:

  --summary       print details from headers (like TERM=, ...)
  --play-input    print input only
  --play-output   (default)
  

* new command scriptlive(1)

 - create a new session (slave/master pty) with shell/command to repeat previously
   recorded session on a real shell/command.

 - for example you can record session (with --log-in) on one machine, repeat 
   later on another machine(s)


The target release will be probably v2.35 and I'm going to start work
on it ASAP (probably this or next week).

Comments & objections?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: script(1) plans

[Martin Steigerwald]

Hi Karel.

Karel Zak - 18.03.19, 13:53: 
> I'd like to improve script(1) to be more flexible and support more
> streams. The current version allow to log only output, but I'd like to
> add possibility to log input, signals and more details about the
> session.
> 
> The idea is to introduce a new timing file format; and use it in case
> a new features are requested by user on script(1) command line. The
> new format will be still based on text and easy to convert to the old
> version.
[…]
> The target release will be probably v2.35 and I'm going to start work
> on it ASAP (probably this or next week).
> 
> Comments & objections?

Epic. I am no expert regarding what would be good for "script" command, 
but I love the ideas you share here. They extend the possibilities of 
what can be done with the command quite a bit.

Seems finally time to include the script command somewhere in my Linux 
training slides. Like "watch", which I often show to participants I 
still have no slide for it. About time, I'd say.

THanks,
-- 
Martin

Re: script(1) plans

[Fabian.Kirsch]

> I'd like to improve script(1) to be more flexible and support more

Hi,

IMHO strace(1) needs an additional output format which is designed for
further processing instead of eye-balls.
And then script(1) could become one of the filters which cook raw
strace-logs into the format which fits its purpose.

Otherwise script(1) starts walking through the design space towards
strace(1), without factoring out the common part.

Greetings
  Fabian

Re: script(1) plans

[Rick van Rein]

Hi Fabian,

> IMHO strace(1) needs an additional output format which is designed for
> further processing instead of eye-balls.

To that end, I've proposed an output option as a stream, by sending it as stdin to a command.  I am still struggling with some crashes that I haven't been able to resolve yet (mostly lack of time).  Is that the direction you are thinking in?

-Rick