Re: [Patch] script: Implement --ts-output and --ts-script options. -v2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 10, 2009 at 09:50:23AM +0200, Karel Zak wrote:
> On Thu, Jul 09, 2009 at 11:42:38PM -0500, Robin Holt wrote:
> > 
> > This patch introduces two new options (actually three).
> 
>  Why we need this feature? Do you have any example?

We often use this modified script when timing the boot of a new machine
and want to compare the boot times.  You can, at a glance, see how long
each line of output took and how long total from the begining of boot
you are currently sitting.  Additionally, when you are typing commands,
etc, in you have very little extra output (essentially the same as your
prompt only on every line of output).

> 
> > --ts-output	Add a formatted timestamp to stdout for each new line
> > 		of output.  The timestamp is composed of two floating
> > 		point values, the first is seconds since the script
> > 		was started.  The second is seconds since the previous
> > 		line of output.
> > 
> > --ts-script	Puts the same values as above in the typescript file
> > 		instead of stdout.
> 
>  Is it really good idea to introduce long options when the rest of
>  the options are short?

What, fundamentally, is the problem with using long options?  This seems
to be the trend.  I personally love them as they give me a clear idea
of the intent of the option.

>  Do we really need --ts-script? I think the timing file (script -t)
>  already includes all necessary information and everything what you
>  need is to modify scriptreplay(1) to re-count and print timing
>  information per line.

It is extremely convenient to have the timing information included in
the typescript file.  My largest complaint with Jack's tweaked script
is I am forced to have the timing on stdout and the typescript file.
This seemed like the easiest way to allow the user to decide where they
wanted the output.

> 
>  So my suggestion is to introduce a new option -l | --line-time for
>  script(1) and scriptreplay(1) and don't store any extra timing
>  information to the typescript file.

But having the timing in the typescript file is the core need being
addressed with this patch.  I want to preserve the file with the timing
file for months or years.  This gives me the opportunity to compare
the boot time of a SLES-9 system with a SLES-11 system of similar size
without having to reinstall SLES-9.

What is the advantage of seperating the timing information from the
output?  If I am trying to compare two boots, I would have to first run
the command twice to create the four files, and then run scriptreplay
twice to merge the two files back into the two files I have here.
That seems like a waste of time.

> > I updated the translations to the best of my ability.
> 
>  Please, don't include generated stuff to your patches. Don't care
>  about po/* at all, these files are updated before release.

That would usually be true, but when you modify the _("...") string, you
have modified the msgid="..." field in the .po file and unless you modify
the msgstr=".." field, the internationalized version will not be correct.
I am doing more than simply adjusting line numbers.


Try to use the new options and compare it to the -t option.  Imagine using
using it for what I describe versus as you suggest here.  Then give me an
honest assesment of its value.  Speaking as somebody who is constantly
frustrated that Jack's style of script functionality isn't supported in
all distros, I think you will agree.

Thanks,
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

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux