emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-bug-tracker] bug#7877: closed (sleep takes undocumented hex args)


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#7877: closed (sleep takes undocumented hex args)
Date: Fri, 21 Jan 2011 19:22:02 +0000

Your message dated Fri, 21 Jan 2011 20:28:56 +0100
with message-id <address@hidden>
and subject line Re: bug#7877: sleep takes undocumented hex args
has caused the GNU bug report #7877,
regarding sleep takes undocumented hex args
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
7877: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7877
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: sleep takes undocumented hex args Date: Fri, 21 Jan 2011 07:31:18 +0800
The documentation doesn't say that one can also use hex args:
$ time /bin/sleep 0x10
real    0m16.007s
However not octal args:
$ time /bin/sleep 010
real    0m10.003s
Maybe say how too.



--- End Message ---
--- Begin Message --- Subject: Re: bug#7877: sleep takes undocumented hex args Date: Fri, 21 Jan 2011 20:28:56 +0100
Paul Eggert wrote:
> On 01/21/2011 01:24 AM, Jim Meyering wrote:
>> My first reflex was to make sleep reject args like 0x... and inf.
>
> My reflex was just the opposite: why reject a notation
> that might be useful?

I see that at least freebsd's /bin/sleep and the one from sunos 5.11
work just like the one from coreutils (without my proposed change)
in accepting e.g., 0x1 and inf.

netbsd's accepts 0x1 but not inf.
openbsd's accepts neither.

> Several other programs (printf, seq, sort, tail, plus many
> other GNU programs) also use strtod or strtold.  If 'sleep' is
> changed to reject hexadecimal and infinity, shouldn't they
> be changed too, for consistency?
>
> I expect it's better to leave these programs alone.  Not only
> is this simpler, and a tiny bit cheaper at runtime, it's slightly
> less likely to break existing usage.
>
> Anyway, whatever we do, we should document it better.  To start the ball
> rolling on that, I pushed the following change, which documents the
> existing behavior.  We can change this if we change the behavior.

The above, plus your added documentation are good enough
reasons to leave sleep as-is.

Thanks.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]