Util-Linux Archive on lore.kernel.org
 help / color / Atom feed
* script(1) plans
@ 2019-03-18 12:53 Karel Zak
  2019-03-18 21:10 ` Martin Steigerwald
  2019-03-19  7:30 ` Fabian.Kirsch
  0 siblings, 2 replies; 4+ messages in thread
From: Karel Zak @ 2019-03-18 12:53 UTC (permalink / raw)
  To: util-linux; +Cc: Rick van Rein, Asbjørn Sloth Tønnesen


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: script(1) plans
  2019-03-18 12:53 script(1) plans Karel Zak
@ 2019-03-18 21:10 ` Martin Steigerwald
  2019-03-19  7:30 ` Fabian.Kirsch
  1 sibling, 0 replies; 4+ messages in thread
From: Martin Steigerwald @ 2019-03-18 21:10 UTC (permalink / raw)
  To: Karel Zak; +Cc: util-linux, Rick van Rein, Asbjørn Sloth Tønnesen

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: script(1) plans
  2019-03-18 12:53 script(1) plans Karel Zak
  2019-03-18 21:10 ` Martin Steigerwald
@ 2019-03-19  7:30 ` Fabian.Kirsch
  2019-03-19  7:53   ` Rick van Rein
  1 sibling, 1 reply; 4+ messages in thread
From: Fabian.Kirsch @ 2019-03-19  7:30 UTC (permalink / raw)
  To: kzak, util-linux; +Cc: asbjorn, rick


> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: script(1) plans
  2019-03-19  7:30 ` Fabian.Kirsch
@ 2019-03-19  7:53   ` Rick van Rein
  0 siblings, 0 replies; 4+ messages in thread
From: Rick van Rein @ 2019-03-19  7:53 UTC (permalink / raw)
  To: Fabian.Kirsch; +Cc: kzak, util-linux, asbjorn

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-18 12:53 script(1) plans Karel Zak
2019-03-18 21:10 ` Martin Steigerwald
2019-03-19  7:30 ` Fabian.Kirsch
2019-03-19  7:53   ` Rick van Rein

Util-Linux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/util-linux/0 util-linux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 util-linux util-linux/ https://lore.kernel.org/util-linux \
		util-linux@vger.kernel.org util-linux@archiver.kernel.org
	public-inbox-index util-linux


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.util-linux


AGPL code for this site: git clone https://public-inbox.org/ public-inbox