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 altogether. My 2 cents. -Modulok- On 5/29/13, RW <rwmailli...@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscr...@freebsd.org" > _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
