Todd C. Miller wrote:
> Other implementations of "time -p" (both builtin and standalone)
> only display two digits after the radix point. I'm a little concerned
> about breaking scripts that consume out the output of "time -p".
I share that concern.
Other implementations of "time -p" (both builtin and standalone)
only display two digits after the radix point. I'm a little concerned
about breaking scripts that consume out the output of "time -p".
Changing the precission of the non-portable output format is fine.
- todd
On Tue, Jun 13, 2023 at 10:59:53PM -0500, Scott Cheloha wrote:
> This patch bumps the precision of durations printed by csh(1), ksh(1),
> and time(1) from centiseconds to milliseconds. The csh(1) and ksh(1)
> builtins "time" and "times" are affected.
>
> My thinking is:
>
> - All practical
On Wed, Jun 14, 2023 at 10:34:20AM -0400, Josiah Frentsos wrote:
> On Tue, Jun 13, 2023 at 10:59:53PM -0500, Scott Cheloha wrote:
> > Index: usr.bin/time/time.c
> > ===
> > RCS file: /cvs/src/usr.bin/time/time.c,v
> > retrieving
On Tue, Jun 13, 2023 at 10:59:53PM -0500, Scott Cheloha wrote:
> Index: usr.bin/time/time.c
> ===
> RCS file: /cvs/src/usr.bin/time/time.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 time.c
> --- usr.bin/time/time.c 21 Aug
This patch bumps the precision of durations printed by csh(1), ksh(1),
and time(1) from centiseconds to milliseconds. The csh(1) and ksh(1)
builtins "time" and "times" are affected.
My thinking is:
- All practical OpenBSD platforms have a timecounter with at least
millisecond precision.
-
