GNU bug report logs - #42187
coreutils man page

Previous Next

Package: coreutils;

Reported by: Jonny Grant <jg <at> jguk.org>

Date: Sat, 4 Jul 2020 14:30:02 UTC

Severity: normal

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

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

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to bug-coreutils <at> gnu.org:
bug#42187; Package coreutils. (Sat, 04 Jul 2020 14:30:02 GMT) Full text and rfc822 format available.
Acknowledgement sent to Jonny Grant <jg <at> jguk.org>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Sat, 04 Jul 2020 14:30:02 GMT) Full text and rfc822 format available.

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

From: Jonny Grant <jg <at> jguk.org>
To: bug-coreutils <at> gnu.org
Subject: coreutils man page
Date: Sat, 4 Jul 2020 15:29:42 +0100

Hello
Just looking at this man page. I appreciate not the latest version. GNU coreutils 8.32    

https://man7.org/linux/man-pages/man1/timeout.1.html

Could it be clarified that a timeout DURATION of 0 also specifically inhibits the   -k, --kill-after=DURATION  ?
it's implied as "this long after the initial signal was sent", so I'm suggesting to make it clearer.

ie
$ time timeout -k 2 0 sleep 3

real	0m3.005s
user	0m0.004s
sys	0m0.000s



Maybe it could be updated:

-k, --kill-after=DURATION

also send a KILL signal if COMMAND is still running
this long after the initial signal was sent. This
never occurs if the initial signal was inhibited by a
duration of 0


Cheers, Jonny
This bug report was last modified 3 years and 295 days ago.

Previous Next

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