On Mon, Jul 13, 2009 at 07:29:46AM -0500, Robin Holt wrote:
> On Mon, Jul 13, 2009 at 02:07:24PM +0200, Karel Zak wrote:
> > On Mon, Jul 13, 2009 at 06:11:32AM -0500, Robin Holt wrote:
> > > > > readable format, it is fairly efficient. Again, addressing changes to
> > > > > how the replay data is captured seems like an issue separate from this.
> > > >
> > > > This is not separate issue, we already have all necessary timing
> > > > information (well, now in separate file) -- it seems like nonsense to
> > > > duplicate this stuff and introduce a new timing data.
> > >
> > > The timing information is completely different in purpose. In one,
> > > we are trying to recreate the feel of the session. In the other, we
> > > are trying to determine how long has elapsed.
> >
> > And? The important is to store all necessary information to the
> > typescript the, so you can later generate arbitrary output.
> >
> > I believe that we can use scriptreplay(1) for "feel of the session"
> > and also for "determine how long has elapsed" from one typescript
> > file. The scriptreplay(1) behaviour should be controlled by command
> > line options.
> >
> > > the replay information to add the timestamps after the fact to the log,
> > > but how would you propose adding it to the display on stdout?
> >
> >
> > script --show-timing <-- prints to stdout (like your --ts-output)
> > --save-timing <-- store generic timing data to the typescript file
> >
> > scriptreplay --show-timing <-- like your --ts-output
> >
> >
> > > > For example from your point of view is important to track delay
> > > > between lines, but for someone else could be interesting to track
> > > > delay between prompts ($PS1), ... etc.
> > >
> > > Then, at that time, allow them to add the ability to change the
> > > demarcation from my simple search for '\n' to regexp match, but that is
> > > their issue then and not my issue now.
> >
> > You want to store the final timing output string to the typescript
> > file. I want to store a generic timing data to typescript file and
> > generate the output by --show-timing. That's all.
>
> Except we nearly always use this tool to watch the console during
> a boot. Some of these larger boots take hours. Being able to look at
> the slowdowns during that boot while additional data is being gathered
> has proven to be valuable.
script --show-timing
will generate the output during the session. You can watch the same
output by
scriptreplay --show-timing
later. IMHO this solution is 100% compatible with your patch.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
