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. Robin -- 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
