On Fri, Jul 10, 2009 at 09:43:57PM +0200, Karel Zak wrote:
> On Fri, Jul 10, 2009 at 06:25:36AM -0500, Robin Holt wrote:
> > On Fri, Jul 10, 2009 at 09:50:23AM +0200, Karel Zak wrote:
> > > > --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.
>
> Ah, I have nothing against long options. The correct implementation
> is to have short and/or long variants for *all* options.
I could do that. That seems like unrelated effort and could be handled
later. If we are going to those lengths, I would probably run it through
Lindent and do some other cleanups. Again, seperate work.
> > > 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
>
> OK, I agree that it makes sense to store all information to the
> typescript file (but the old format has to be supported too).
The old format was the timing information to stderr which you needed to
capture to a file. Adding an option for specifying the replay timing
file instead of just stderr might be nice, but I think we need to keep
stderr as the expected location for a -t without this new option.
Having the replay timing information in a separate file keeps you from
having to somehow escape the demarkation characters. For computer
readable format, it is fairly efficient. Again, addressing changes to
how the replay data is captured seems like an issue separate from this.
This timing information is for a different purpose, specifically to track
how many seconds each line of output took relative to either start of script or
the previous end of line.
> We can extend the current typescript format, but it would be nice to
> provide the same quality of timing information that we have currently
> in the separate timing file -- it means time-per-bytes rather than
> time-per-line.
>
> The scriptreplay(1) should be also updated to understand the new
> format.
It does. At each point where we have put the formatted timestamp
into the script file, I have added 29 bytes to the byte count for that
printouts timing. The result is a scriptreplay which works as well as
before this change.
> > > 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.
>
> Sure, see "po: merge changes" commits in the repository. The po/*
> files are updated before release and translated by translationproject.org.
But the translation project hasn't even updated some of the languages to
the command arguments. I am not sure how many msgid translations with
fuzz are garbage, but this one would certainly be bad as changing the
language would make options appear to come and go from the usage printout.
If you don't want them, it is easy enough for me to resubmit with them
removed. If you are asking me to work with the tranlsation project to
get all these updated in each language, I think I will punt and let the
users with LANG set to something else rely upon the man page. The downside
would be doing:
With LANG=en_US, script --help:
usage: script [-a] [-c <command>] [-f] [-q] [-t] [--ts-output] [--ts-script] [-T] [file]
With LANG=zh_CN, script --help:
usage: script [-a] [-f] [-q] [-t] [file]
NOTE: This is not a new problem we are creating, Look at the po/pt_BR.po
and you will see the -t option is already missing from that usage output.
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
