* sleep $floatval
@ 2013-08-31 23:47 Phil Pennock
2013-09-01 7:45 ` Bart Schaefer
2013-09-01 17:29 ` Peter Stephenson
0 siblings, 2 replies; 7+ messages in thread
From: Phil Pennock @ 2013-08-31 23:47 UTC (permalink / raw)
To: zsh-workers
% float SleepDuration=0.3
% date; sleep $SleepDuration; date
Sat Aug 31 16:39:33 PDT 2013
Sat Aug 31 16:39:36 PDT 2013
%
So the float shows as 3.000000000e-01 which becomes a string, before
being passed to the built-in sleep, which then does not parse that
format as 0.3, nor show an error, but instead sleeps for 3 seconds
without an error.
I thought that sleep was a shell builtin, but apparently I thought
wrong. Using "float -F SleepDuration" fixes it.
What do folks think about sleep being a builtin, which can take
arbitrary formats and avoid forking an extra process, just to delay?
Looking for a rough idea of whether people think the current behaviour
is problematic enough to make it worth adding another builtin. And
should it be sleep or zsleep, if so?
-Phil
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: sleep $floatval
2013-08-31 23:47 sleep $floatval Phil Pennock
@ 2013-09-01 7:45 ` Bart Schaefer
2013-09-01 8:16 ` Phil Pennock
2013-09-01 17:29 ` Peter Stephenson
1 sibling, 1 reply; 7+ messages in thread
From: Bart Schaefer @ 2013-09-01 7:45 UTC (permalink / raw)
To: zsh-workers
On Aug 31, 4:47pm, Phil Pennock wrote:
>
> So the float shows as 3.000000000e-01 which becomes a string, before
> being passed to the built-in sleep, which then does not parse that
> format as 0.3, nor show an error, but instead sleeps for 3 seconds
> without an error.
If $SleepDuration can be < 1, don't you want
usleep $((SleepDuration * 1.0e+6))
instead?
> What do folks think about sleep being a builtin, which can take
> arbitrary formats and avoid forking an extra process, just to delay?
I don't have any particular objection.
Incidentally, the manual actually recommends
zselect -t $((SleepDurationInSeconds * 100))
> Looking for a rough idea of whether people think the current behaviour
> is problematic enough to make it worth adding another builtin. And
> should it be sleep or zsleep, if so?
The current behavior isn't problematic enough to have caused POSIX, bash,
et al., to redefine sleep as a builtin, and it's not a problem I've ever
encountered myself, but ...
It could be added as one or more subcommands of zsystem (the only one
currently is "flock"), e.g. "zsystem sleep $n", which allows you to do
"if zsystem supports sleep; then ... fi". Otherwise I'd say zsleep is
the best name for it, particularly if it magically converts floats into
fractional second sleeps.
If zsleep, then it could be a new module or be added to zsh/datetime.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: sleep $floatval
2013-09-01 7:45 ` Bart Schaefer
@ 2013-09-01 8:16 ` Phil Pennock
0 siblings, 0 replies; 7+ messages in thread
From: Phil Pennock @ 2013-09-01 8:16 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
On 2013-09-01 at 00:45 -0700, Bart Schaefer wrote:
> If $SleepDuration can be < 1, don't you want
>
> usleep $((SleepDuration * 1.0e+6))
I don't have a usleep(1) command. I do have a BSD sleep(1) command
which takes fractional seconds, both on FreeBSD and MacOS, and the
Ubuntu systems I see have a sleep(1) which does the same, and appears to
be from GNU coreutils.
It appears that the GNU coreutils variant correctly parses
"3.000000000e-01" and sleeps for 0.3 seconds, instead of 3 seconds.
> The current behavior isn't problematic enough to have caused POSIX, bash,
> et al., to redefine sleep as a builtin, and it's not a problem I've ever
> encountered myself, but ...
I think POSIX still doesn't specify any support for non-integral
sleep(1) durations, right?
> If zsleep, then it could be a new module or be added to zsh/datetime.
Am reconsidering in light of this being purely a BSD sleep(1) bug. Hrm.
Thanks,
-Phil
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: sleep $floatval
2013-08-31 23:47 sleep $floatval Phil Pennock
2013-09-01 7:45 ` Bart Schaefer
@ 2013-09-01 17:29 ` Peter Stephenson
2013-09-02 2:33 ` Phil Pennock
1 sibling, 1 reply; 7+ messages in thread
From: Peter Stephenson @ 2013-09-01 17:29 UTC (permalink / raw)
To: zsh-workers
On Sat, 31 Aug 2013 16:47:33 -0700
Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> What do folks think about sleep being a builtin, which can take
> arbitrary formats and avoid forking an extra process, just to delay?
You can use "zselect -t <hundredths>" to delay a number of 100ths of a second.
(I think I added it before floating point was widely used in the shell.)
It would also be easy to add a sleep subcommand to zsystem.
--
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: sleep $floatval
2013-09-01 17:29 ` Peter Stephenson
@ 2013-09-02 2:33 ` Phil Pennock
2013-09-02 18:09 ` Bart Schaefer
0 siblings, 1 reply; 7+ messages in thread
From: Phil Pennock @ 2013-09-02 2:33 UTC (permalink / raw)
To: zsh-workers
On 2013-09-01 at 18:29 +0100, Peter Stephenson wrote:
> On Sat, 31 Aug 2013 16:47:33 -0700
> Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> > What do folks think about sleep being a builtin, which can take
> > arbitrary formats and avoid forking an extra process, just to delay?
>
> You can use "zselect -t <hundredths>" to delay a number of 100ths of a second.
> (I think I added it before floating point was widely used in the shell.)
>
> It would also be easy to add a sleep subcommand to zsystem.
Crazy, idle, thought, to which a scream of horror might be the correct
response ...
Say I do add a zsleep command; if the sleep returns EINTR, then before
going back to sleep for the remainder of the duration, the command could
report on reaped jobs immediately, so that instead of being pre-prompt,
job termination could be reported immediately during the length of the
sleep. (At which point, zsleep might as well take an option giving it a
function list variable to be be walked, any time it is woken up, to let
arbitrary handlers be invoked, before resuming sleep, and possibly with
a way to abort and avoid going back to sleep).
Does this make people go:
1. "Hrm, interesting, that suggests some use-cases that might be neat"
2. "AARGH BY THE OLD ONES HELL NO!"
?
Thanks,
-Phil
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: sleep $floatval
2013-09-02 2:33 ` Phil Pennock
@ 2013-09-02 18:09 ` Bart Schaefer
2013-09-03 3:05 ` Phil Pennock
0 siblings, 1 reply; 7+ messages in thread
From: Bart Schaefer @ 2013-09-02 18:09 UTC (permalink / raw)
To: zsh-workers
On Sep 1, 7:33pm, Phil Pennock wrote:
}
} Say I do add a zsleep command; if the sleep returns EINTR, then before
Hmm, sleep is a library call, not a system call, and isn't documented as
setting errno to anything useful, so you must be planning on implementing
the delay some other way?
} going back to sleep for the remainder of the duration, the command could
} report on reaped jobs immediately, so that instead of being pre-prompt,
} job termination could be reported immediately during the length of the
} sleep.
That might be better expressed explicitly (even if implemented the same
way underneath) by providing a variant of "wait" that has a timeout,
rather than by having a variant of "sleep" that does it implicitly.
} (At which point, zsleep might as well take an option giving it a
} function list variable to be be walked, any time it is woken up, to let
} arbitrary handlers be invoked, before resuming sleep, and possibly with
} a way to abort and avoid going back to sleep).
What happens if a handler invokes zsleep again with a different list of
functions? Also, how do you plan to keep track of whether the original
sleep time has expired while the handlers were executing?
Other problems of having a builtin sleep include defining the interaction
with signal handlers, particularly the ALRM handler.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: sleep $floatval
2013-09-02 18:09 ` Bart Schaefer
@ 2013-09-03 3:05 ` Phil Pennock
0 siblings, 0 replies; 7+ messages in thread
From: Phil Pennock @ 2013-09-03 3:05 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
On 2013-09-02 at 11:09 -0700, Bart Schaefer wrote:
> Hmm, sleep is a library call, not a system call, and isn't documented as
> setting errno to anything useful, so you must be planning on implementing
> the delay some other way?
nanosleep being less portable than select, I was tending towards the
second. (I wish I were clever enough to have come up with that pun
deliberately).
> What happens if a handler invokes zsleep again with a different list of
> functions? Also, how do you plan to keep track of whether the original
> sleep time has expired while the handlers were executing?
Track desired end time, get current time before re-entering, only
request long enough for the remaining delta.
> Other problems of having a builtin sleep include defining the interaction
> with signal handlers, particularly the ALRM handler.
Another good reason to just use select(2) instead of sleep(3). :)
-Phil
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-09-03 3:05 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-31 23:47 sleep $floatval Phil Pennock
2013-09-01 7:45 ` Bart Schaefer
2013-09-01 8:16 ` Phil Pennock
2013-09-01 17:29 ` Peter Stephenson
2013-09-02 2:33 ` Phil Pennock
2013-09-02 18:09 ` Bart Schaefer
2013-09-03 3:05 ` Phil Pennock
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).