zsh-workers
 help / color / mirror / code / Atom feed
* 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).