modulok at gmail.com
Wed May 29 19:32:19 UTC 2013
I'm personally a fan of a forest-green bike shed myself...
>> It would still just be doing one thing - sleeping.
I agree. Perfect solution fallacy aside, a sleep option with basic time
increments would be useful for real-world purposes. I'm in favor of computing
it as a multiple of seconds as previously outlined. We don't need to contrive
the sleep function for every possible corner case until it's reduced to
something complicated, buggy and unreliable. As long as it doesn't break
existing code, new and useful options are appreciated.
As a programmer, if I say sleep for 1 hour I expect it to sleep for 3600 local
seconds from the time the call is made until it wakes up again without any
absurd gotchas. If the real-world time elapsed is more or less than 3600
seconds due to an internal clock error - fine. That's a different problem
My 2 cents.
On 5/29/13, RW <rwmaillists at googlemail.com> wrote:
> On Wed, 29 May 2013 10:01:53 -0400
> Paul Kraus wrote:
>> Agreed. When I first started dealing with Unix professionally (1995,
>> I started playing with Unix-like OSes almost 10 years earlier) I was
>> taught that each Unix command does one thing and does it well.
> It would still just be doing one thing - sleeping. Support for units
> usually comes under "and does it well". I wouldn't want to have to
> pipe df through awk to get MBs, or complicate "find" with arithmetic.
> Unit support in sleep is a perfectly legitimate thing to ask for, I
> don't think it particularly useful though, and leap-second support is
> close to pointless.
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions