On Mon, Jul 28, 2008 at 05:40:00AM -0700, Micah Cowan wrote:
> - From a Correctness POV, the right way to deal with this is to fix
> script.c, not scriptreplay.c. The simple act of moving the newtime
> calculation to below the read, rather than before it (and, perhaps,
> calculating oldtime using gettimeofday, so we don't introduce a spurious
> ~half-second delay) will have things working better than they ever did,
> and result in a much more straightforward way to process the timing file
> (i.e., the way scriptreplay does it now).
>
> - From a Pragmatism POV, though, there's the fact that, if we simply
> kludge scriptreplay.c to behave as the original did, then the timing
> files from all versions of script, new and old, will work with the
> current scriptreplay. If we fix script.c instead, then everyone has to
> be careful not to mix versions of script.
The original purpose of the scriptreplay.c was to implement
*backwardly compatible* replacement of scriptreplay.pl. From my point
of view the out-of-sync problem is *regression* and should be fixed
(also in 2.14.1).
I think we have to support old (already generated) typescripts.
I don't like the typescript "format". It's mess without a header and
information about a version, ... so, I like the idea to implement a
new better format (with timing?), but we have to support the old
format too. I propose:
1/ fix scriptreplay.c (just for backward compatibility)
(optionally) 2/ create a new format
Please, evolution, not revolution.
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
