GNU bug report logs - #77535
timeout treats very short durations as `0`

Previous Next

Package: coreutils;

Reported by: Nicolas Boichat <nicolas <at> boichat.ch>

Date: Fri, 4 Apr 2025 16:13:02 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


Message #25 received at 77535 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Philip Rowlands <phr+coreutils <at> dimebar.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>, 77535 <at> debbugs.gnu.org
Cc: nicolas <at> boichat.ch
Subject: Re: bug#77535: timeout treats very short durations as `0`
Date: Sat, 5 Apr 2025 19:45:23 +0100
On 05/04/2025 19:02, Philip Rowlands wrote:
> I was interested to see that the code makes uses of strtod, and how this interacts with the minute / hour / day suffix.
> 
> $ strace -e trace=clock_nanosleep sleep 3
> clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=3, tv_nsec=0},
> 
> $ strace -e trace=clock_nanosleep sleep 0xas
> clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=10, tv_nsec=0},
> 
> $ strace -e trace=clock_nanosleep sleep 0xam
> clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=600, tv_nsec=0},
> 
> $ strace -e trace=clock_nanosleep sleep 0xad
> clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=173, tv_nsec=0},
> 
> Here 0xad is interpreted as 173 seconds, not 10 days.
> 
> It's a corner case, but should sleep(1) support or tolerate hex input, and if so, how should it handle the "d" suffix? FWIW I'd just vote to return an error for hex intervals.

Good point :)
Given FreeBSD and ksh sleep implementations also behave like GNU,
we should probably just document the edge case that
(day) suffixes are best avoided with hex inputs.

  ~$ ksh
  $ type sleep
  sleep is a shell builtin
  $ time sleep 0x10d
  real	4m29.00s

cheers,
Pádraig




This bug report was last modified 42 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.