Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15377 > unrolled thread

[repost] "precision" of $SECONDS

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [repost] "precision" of $SECONDS Stephane Chazelas <stephane.chazelas@gmail.com> - 2019-09-16 19:29 +0100

#15377 — [repost] "precision" of $SECONDS

That's a a re-post of a bug report I raised a few years ago and
comes back now and then in various Q&A sites I participate in.

The discussions kind of trailed off last time.
https://www.mail-archive.com/bug-bash@gnu.org/msg17783.html

2016-02-24 15:16:41 +0000, Stephane Chazelas:
> $ time bash -c 'while ((SECONDS < 1)); do :; done'
> bash -c 'while ((SECONDS < 1)); do :; done'  0.39s user 0.00s system 99% cpu 0.387 total
> 
> That can take in between 0 and 1 seconds. Or in other words,
> $SECONDS becomes 1 in between 0 and 1 second after the shell was
> started.
> 
> The reason seems to be because the shell records the value
> returned by time() upon start-up and $SECONDS expands to
> time()-that_saved_time. So, if bash is started at 10:00:00.999,
> then $SECONDS will become 1 only a milisecond after startup
> while if it's started at 10:00:01.000, $SECONDS will become 1 a
> full second later.
> 
> IMO, it would be better if gettimeofday() or equivalent was used
> instead of time() so that $SECONDS be incremented exactly one
> second after start-up like ksh93 does.
> 
> mksh and zsh behave like bash (I'll raise the issue there as
> well).
> 
> With zsh (like in ksh93), one can do "typeset -F SECONDS" to
> make $SECONDS floating point, which can be used as a work around
> of the "issue".
[...]

Note that since then the corresponding bugs in mksh and zsh have
been fixed.

-- 
Stephane

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web