GNU bug report logs - #9102
"timeout 0 FOO" should timeout right away

Previous Next

To reply to this bug, email your comments to 9102 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-coreutils <at> gnu.org
Subject: "timeout 0 FOO" should timeout right away
Date: Sat, 16 Jul 2011 12:34:02 -0700

"sleep 0" sleeps for zero seconds, and "timeout 0 FOO"
should timeout in zero seconds as well.  Currently,
it doesn't; it times out in an infinite number of seconds.
I see why, from the internals (alarm (0) is a special
call intended to cancel alarms).  However, 'timeout' shouldn't
be exposing those internals to users; it should behave like
'sleep' does, as that's more consistent.

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

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: eggert <at> cs.ucla.edu (Paul Eggert)
Cc: 9102 <at> debbugs.gnu.org
Subject: Re: bug#9102: "timeout 0 FOO" should timeout right away
Date: Sat, 16 Jul 2011 17:08:44 -0500 (GMT+5)

Paul Eggert writes:
> 
> "sleep 0" sleeps for zero seconds, and "timeout 0 FOO"
> should timeout in zero seconds as well.  Currently,
> it doesn't; it times out in an infinite number of seconds.
> I see why, from the internals (alarm (0) is a special
> call intended to cancel alarms).  However, 'timeout' shouldn't
> be exposing those internals to users; it should behave like
> 'sleep' does, as that's more consistent.
> 

What's the difference between running a command with a 0 second timeout
and not running the command at all? It could be killed before it even gets
scheduled.

-- 
Alan Curry

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Curry <pacman-cu <at> kosh.dhis.org>
Cc: 9102 <at> debbugs.gnu.org
Subject: Re: bug#9102: "timeout 0 FOO" should timeout right away
Date: Sat, 16 Jul 2011 15:27:55 -0700

On 07/16/11 15:08, Alan Curry wrote:
> What's the difference between running a command with a 0 second timeout
> and not running the command at all? It could be killed before it even gets
> scheduled.

Yes, exactly.  "timeout 0 FOO" should be the limit case for

timeout 1 FOO
timeout 0.1 FOO
timeout 0.01 FOO
timeout 0.001 FOO

That is, its behavior shouldn't diverge markedly from that of
"timeout 1e-300 FOO".

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9102 <at> debbugs.gnu.org
Subject: Re: bug#9102: "timeout 0 FOO" should timeout right away
Date: Sun, 17 Jul 2011 13:31:27 +0100

On 16/07/11 20:34, Paul Eggert wrote:
> "sleep 0" sleeps for zero seconds, and "timeout 0 FOO"
> should timeout in zero seconds as well.  Currently,
> it doesn't; it times out in an infinite number of seconds.
> I see why, from the internals (alarm (0) is a special
> call intended to cancel alarms).  However, 'timeout' shouldn't
> be exposing those internals to users; it should behave like
> 'sleep' does, as that's more consistent.

Well my reasoning for having "0" mean don't timeout,
was to have an easy way in scripts to specify no timeout, like:

timeout=0 # none
[ "$platform" = "buggy" ] && timeout=10
timeout $timeout command

I'm unsure whether to make this change.
If we do I guess `timeout` should immediately exit(124).
This change in behavior would need a mention in NEWS anyway.

cheers,
Pádraig.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 9102 <at> debbugs.gnu.org
Subject: Re: bug#9102: "timeout 0 FOO" should timeout right away
Date: Sun, 17 Jul 2011 12:08:14 -0700

On 07/17/11 05:31, Pádraig Brady wrote:
> Well my reasoning for having "0" mean don't timeout,
> was to have an easy way in scripts to specify no timeout

That's a good thing to have, but it could be specified in
a different way.  One possibility is the '1' (digit 1) option,
e.g.,  "timeout -1 FOO".  Or if that's too clever, we could
use some other letter for the option.

> If we do I guess `timeout` should immediately exit(124).
> This change in behavior would need a mention in NEWS anyway.

Yes, that'd make sense.

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

From: James Youngman <jay <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigbrady.com>, 9102 <at> debbugs.gnu.org
Subject: Re: bug#9102: "timeout 0 FOO" should timeout right away
Date: Tue, 19 Jul 2011 23:00:09 +0100

2011/7/17 Paul Eggert <eggert <at> cs.ucla.edu>:
> On 07/17/11 05:31, Pádraig Brady wrote:
>> Well my reasoning for having "0" mean don't timeout,
>> was to have an easy way in scripts to specify no timeout
>
> That's a good thing to have, but it could be specified in
> a different way.  One possibility is the '1' (digit 1) option,
> e.g.,  "timeout -1 FOO".  Or if that's too clever, we could
> use some other letter for the option.

I'm not sure that's worked out so well for tail.   But if we are
looking for an argument indicating we don't want a timeout, the
argument "never" is quite clear.

James.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: James Youngman <jay <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 9102 <at> debbugs.gnu.org
Subject: Re: bug#9102: "timeout 0 FOO" should timeout right away
Date: Tue, 19 Jul 2011 23:17:59 +0100

On 19/07/11 23:00, James Youngman wrote:
> 2011/7/17 Paul Eggert <eggert <at> cs.ucla.edu>:
>> On 07/17/11 05:31, Pádraig Brady wrote:
>>> Well my reasoning for having "0" mean don't timeout,
>>> was to have an easy way in scripts to specify no timeout
>>
>> That's a good thing to have, but it could be specified in
>> a different way.  One possibility is the '1' (digit 1) option,
>> e.g.,  "timeout -1 FOO".  Or if that's too clever, we could
>> use some other letter for the option.
> 
> I'm not sure that's worked out so well for tail.   But if we are
> looking for an argument indicating we don't want a timeout, the
> argument "never" is quite clear.

I don't follow (pardon the pun).
This will "sleep(0)" between polls which takes 10% of my cpu here:

  tail ---disable -s0 -F nosuch

cheers,
Pádraig.

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

From: James Youngman <jay <at> gnu.org>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 9102 <at> debbugs.gnu.org
Subject: Re: bug#9102: "timeout 0 FOO" should timeout right away
Date: Tue, 19 Jul 2011 23:41:17 +0100

2011/7/19 Pádraig Brady <P <at> draigbrady.com>:
> On 19/07/11 23:00, James Youngman wrote:
>> 2011/7/17 Paul Eggert <eggert <at> cs.ucla.edu>:
>>> On 07/17/11 05:31, Pádraig Brady wrote:
>>>> Well my reasoning for having "0" mean don't timeout,
>>>> was to have an easy way in scripts to specify no timeout
>>>
>>> That's a good thing to have, but it could be specified in
>>> a different way.  One possibility is the '1' (digit 1) option,
>>> e.g.,  "timeout -1 FOO".  Or if that's too clever, we could
>>> use some other letter for the option.
>>
>> I'm not sure that's worked out so well for tail.   But if we are
>> looking for an argument indicating we don't want a timeout, the
>> argument "never" is quite clear.
>
> I don't follow (pardon the pun).
> This will "sleep(0)" between polls which takes 10% of my cpu here:
>
>  tail ---disable -s0 -F nosuch

Sorry about the lack of clarity.  I was referring to the mess over
"tail -n 30", "tail -30", "tail +30" etc. and more specifically was
trying to indicate that I didn't think "timeout -0" would be a useful
direction, for that reason.  I'd suggest that Paul's shell snippet
could usefully be:

timeout=never
[ "$platform" = "buggy" ] && timeout=10
timeout $timeout command

James.


-- 
This email is intended solely for the use of its addressee, sender,
and any readers of a mailing list archive in which it happens to
appear.   If you have received this email in error, please say or type
three times, "I believe in the utility of email disclaimers," and then
reply to the author correcting any spellings (and, optionally, any
incorrect spellings), accompanying these with humorous jests about the
author's parentage.   If you are not the addressee, you are
nevertheless permitted to both copy and forward this email since
without such permissions email systems are unable to transmit email to
anybody, intended recipient or not.  To those still reading by this
point, the author would like to apologise for being unable to maintain
a consistent level of humour throughout this disclaimer.  Contents may
settle during transit.  Do not feed the animals.

Previous Next

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