Re: BSD sleep

[Jens Schweikhardt]

On Tue, May 28, 2013 at 07:01:40PM -0400, Kenta Suzumoto wrote:
# Hi. Is there no built-in way of making "sleep" sleep in increments 
# of minutes, hours, etc? The GNU "sleep" can be invoked like "sleep 
# 1h" for an hour. The FreeBSD one's manpage leads me to believe we 
# can only use seconds, which is kind of annoying. Is there an 
# undocmented or missing feature here? Seems really trivial to 
# implement.
# 
# ~ $ sleep 1h
# usage: sleep seconds

Perfection is reached when there is nothing left to take away. The GNU
format is already an incompatibility. If I want to sleep longer than 3
digit amount in secs, I do the math. The POSIXly *portable* way to do
this and document it for the mathematically challenged is

sleep $((2*60*60))# 2h
sleep $((7*24*60*60)) # 1w

Regards,

Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD sleep

[Stuart Barkley]

On Tue, 28 May 2013 at 19:01 -, Kenta Suzumoto wrote:

> Hi. Is there no built-in way of making "sleep" sleep in increments
> of minutes, hours, etc? The GNU "sleep" can be invoked like "sleep
> 1h" for an hour. The FreeBSD one's manpage leads me to believe we
> can only use seconds, which is kind of annoying. Is there an
> undocmented or missing feature here? Seems really trivial to
> implement.
>
> ~ $ sleep 1h
> usage: sleep seconds

See also /usr/ports/misc/delay.

Stuart
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD sleep

[Alexander Yerenkow]

I'm just saying that there's pretty space for discussion.
If someone raised this now, why not discuss it now.

> If you sleep one hour, do you sleep one hour from now or one hour from
the system clock which may change in the next hour? If it's the system
clock, you may sleep for ten minutes or ten hours. If you need to sleep for
3600 seconds, that's simple and understandable.

How about rephrase it:

> If you sleep 3600 seconds, do you sleep 3600 seconds from now or 3600
seconds from the system clock which may change in the next hour? If it's
the system clock, you may sleep for ten minutes or ten hours.

How "way of specifying period" changing the fact that "internal minimal
unit of sleep" is not clearly specified in manpage?
Also, there no info on how DST/ ntp time changes affects of running sleeps.


I don't see right now how new flag (which currently if specified makes
`sleep` exit with help), could break something, but I see that this is
could be useful in some cases.
This also raise question what sleep should do if something specified
incorrectly, like sleep 2h30m30m , or 1h1h or else.

And also if any changes would be accepted, this should be specified in
manpage (that one about `m` as month).

About non-portable feature with non-integers, it was just side observation.


-- 
Regards,
Alexander Yerenkow
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD sleep

[Jason Birch]

> Seriously, that explanation about different hours is not enough to prevent
> at least useful option.
> like
> sleep -f 1h
> (-f means force convert, without it you can see good explanation why sleep
> for 1 hour will be not sleep for 1 hour, and etc, and not get sleep at
> all.).
>

Do one thing, and do it well. What you have proposed involves:
 * an additional force flag
 * interpolation of what follows the force flag (does m mean minutes, or
months?)
 * expectations around time, time zones, and what an hours is.

That fails the litmus test on complexity for me personally - it seems like
a lot of complexity for not much gain.



> P.S. There is already non-portable feature in sleep - non-integer, and I'm
> sure that no one thought about some financists from various countries, who
> used to specify long numbers with separator, e.g. 3.600, and this means for
> them one hour and not 3 point 6 seconds.
>

This isn't a good reason for adding another non-portable feature.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD sleep

[Michael Sierchio]

On Tue, May 28, 2013 at 4:45 PM, Joshua Isom  wrote:


> You think it's trivial until you read this:
>
> http://infiniteundo.com/post/**25326999628/falsehoods-**
> programmers-believe-about-time
>
>
Some days have 86400 seconds, some have 86401.  There is a provision for
two leap seconds to be applied at once, but that hasn't ever happened.
 Still, a truly correct clock, set to UTC, might someday read

23:59:59
23:59:60
23:59:61
00:00:00

How many seconds did that hour have?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD sleep

[Alexander Yerenkow]

>what is stopping from interpreting 1h in similar manner to 3600? i.e. from
now

No, this is user-friendly, and thus can't be done :)
But if think a second, sleep is used rarely by average users, mostly by
programmers and other scripts, and they should know better what they are
doing.

Seriously, that explanation about different hours is not enough to prevent
at least useful option.
like
sleep -f 1h
(-f means force convert, without it you can see good explanation why sleep
for 1 hour will be not sleep for 1 hour, and etc, and not get sleep at
all.).

Exact units in which sleeps happens (seconds, ticks, minutes, years) can be
described in manual page, even without accepting m,h - that info would be
useful for one.

P.S. There is already non-portable feature in sleep - non-integer, and I'm
sure that no one thought about some financists from various countries, who
used to specify long numbers with separator, e.g. 3.600, and this means for
them one hour and not 3 point 6 seconds.

-- 
Regards,
Alexander Yerenkow
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD sleep

[Quark]

>You think it's trivial until you read this:
>
>http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>
>If you sleep one hour, do you sleep one hour from now or one hour from 
>the system clock which may change in the next hour?  If it's the system 
>clock, you may sleep for ten minutes or ten hours.  If you need to sleep 
>for 3600 seconds, that's simple and understandable.


what is stopping from interpreting 1h in similar manner to 3600? i.e. from now

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD sleep

[Chris Rees]

On 29 May 2013 07:13, "Matthew Seaman"  wrote:
>
> On 29/05/2013 05:59, Michael Sierchio wrote:
> > On Tue, May 28, 2013 at 4:45 PM, Joshua Isom  wrote:
> >
> >
> >> You think it's trivial until you read this:
> >>
> >> http://infiniteundo.com/post/**25326999628/falsehoods-**
> >> programmers-believe-about-time<
http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>
> >>
> >>
> > Some days have 86400 seconds, some have 86401.  There is a provision for
> > two leap seconds to be applied at once, but that hasn't ever happened.
> >  Still, a truly correct clock, set to UTC, might someday read
> >
> > 23:59:59
> > 23:59:60
> > 23:59:61
> > 00:00:00
> >
> > How many seconds did that hour have?
>
> Right.  The fact that on very rare occasions a minute may not have 60
> seconds in it plus many other corner cases in calculating the current
> wall-clock time is an amusing irrelevance.
>
> First of all, sleep deals in local elapsed time, which is a well defined
> property even if the displayed wall-clock time would be all over the
> place due to DST changes or relativistic effects or whatever.
>
> In this case, I'd be pretty surprised if GNU sleep's algorithm was
> anything more complicated than to convert the stated time into seconds
> and then sleep that number of seconds.  And to do that conversion, it
> wwould just define one minute as 60 seconds, one hour as 60 minutes, one
> day as 24 hours, one week as 7 days, perhaps one month as 30 days, one
> year as 365 days[*].  Sure, it's simplistic and unsophisticated, but as
> an engineering solution it's good enough for the vast majority of
> purposes.

OK, but is this really something the OS should handle?  I'm sure sleep
`expr 3600 \* 2` will suffice and is perfectly readable, including being
more portable.

Why should we keep putting these weird "extensions" in?  At some point it
just becomes fiddling, and yet another source of error when porting

Chris
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD sleep

[Matthew Seaman]

On 29/05/2013 05:59, Michael Sierchio wrote:
> On Tue, May 28, 2013 at 4:45 PM, Joshua Isom  wrote:
> 
> 
>> You think it's trivial until you read this:
>>
>> http://infiniteundo.com/post/**25326999628/falsehoods-**
>> programmers-believe-about-time
>>
>>
> Some days have 86400 seconds, some have 86401.  There is a provision for
> two leap seconds to be applied at once, but that hasn't ever happened.
>  Still, a truly correct clock, set to UTC, might someday read
> 
> 23:59:59
> 23:59:60
> 23:59:61
> 00:00:00
> 
> How many seconds did that hour have?

Right.  The fact that on very rare occasions a minute may not have 60
seconds in it plus many other corner cases in calculating the current
wall-clock time is an amusing irrelevance.

First of all, sleep deals in local elapsed time, which is a well defined
property even if the displayed wall-clock time would be all over the
place due to DST changes or relativistic effects or whatever.

In this case, I'd be pretty surprised if GNU sleep's algorithm was
anything more complicated than to convert the stated time into seconds
and then sleep that number of seconds.  And to do that conversion, it
wwould just define one minute as 60 seconds, one hour as 60 minutes, one
day as 24 hours, one week as 7 days, perhaps one month as 30 days, one
year as 365 days[*].  Sure, it's simplistic and unsophisticated, but as
an engineering solution it's good enough for the vast majority of
purposes.

Cheers,

Matthew

[*] I haven't checked on GNU sleep, but (for example) this is exactly
what dnssec-keygen(8) does.

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey




signature.asc
Description: OpenPGP digital signature

BSD sleep

[Kenta Suzumoto]

Hi. Is there no built-in way of making "sleep" sleep in increments 
of minutes, hours, etc? The GNU "sleep" can be invoked like "sleep 
1h" for an hour. The FreeBSD one's manpage leads me to believe we 
can only use seconds, which is kind of annoying. Is there an 
undocmented or missing feature here? Seems really trivial to 
implement.

~ $ sleep 1h
usage: sleep seconds

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD sleep

[Joshua Isom]

On 5/28/2013 6:01 PM, Kenta Suzumoto wrote:

Hi. Is there no built-in way of making "sleep" sleep in increments
of minutes, hours, etc? The GNU "sleep" can be invoked like "sleep
1h" for an hour. The FreeBSD one's manpage leads me to believe we
can only use seconds, which is kind of annoying. Is there an
undocmented or missing feature here? Seems really trivial to
implement.

~ $ sleep 1h
usage: sleep seconds



You think it's trivial until you read this:

http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

If you sleep one hour, do you sleep one hour from now or one hour from 
the system clock which may change in the next hour?  If it's the system 
clock, you may sleep for ten minutes or ten hours.  If you need to sleep 
for 3600 seconds, that's simple and understandable.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"