GNU bug report logs - #21760
timeout: Feature Request: --verbose ==> output if timeout was reached

Previous Next

Package: coreutils;

Reported by: Thomas Güttler <guettliml <at> thomas-guettler.de>

Date: Mon, 26 Oct 2015 10:31:02 UTC

Severity: wishlist

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

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21760 in the body.
You can then email your comments to 21760 AT debbugs.gnu.org in the normal way.

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#21760; Package coreutils. (Mon, 26 Oct 2015 10:31:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Güttler <guettliml <at> thomas-guettler.de>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Mon, 26 Oct 2015 10:31:02 GMT) Full text and rfc822 format available.

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

From: Thomas Güttler <guettliml <at> thomas-guettler.de>
To: bug-coreutils <at> gnu.org
Subject: timeout: Feature Request: --verbose ==> output if timeout was reached
Date: Mon, 26 Oct 2015 11:30:36 +0100
About commandline tool "timeout": Start COMMAND, and kill it if still running after DURATION.

A new team mate wasted some time to debug why
a process was killed with signal 15.

I think it would be nice to have an --verbose option, and a some
text which explains why the signal was send.

This is important in environments where the one who reads
the script failures is not the same person who writes the script.

What do you think?

Example:

Old:

  user <at> host:~$ timeout 1s ping localhost
  PING localhost (127.0.0.1) 56(84) bytes of data.
  64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.078 ms

New:

  user <at> host:~$ timeout 1s ping localhost
  PING localhost (127.0.0.1) 56(84) bytes of data.
  64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.078 ms
  ** Process "ping localhost" was killed with signal 16 since the timeout of 1s was reached. **



-- 
Thomas Guettler http://www.thomas-guettler.de/




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Mon, 26 Oct 2015 11:45:02 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Thomas Güttler <guettliml <at> thomas-guettler.de>,
 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Mon, 26 Oct 2015 11:44:10 +0000
tag 21760 wontfix
close 21760
stop

On 26/10/15 10:30, Thomas Güttler wrote:
> About commandline tool "timeout": Start COMMAND, and kill it if still running after DURATION.
> 
> A new team mate wasted some time to debug why
> a process was killed with signal 15.
> 
> I think it would be nice to have an --verbose option, and a some
> text which explains why the signal was send.
> 
> This is important in environments where the one who reads
> the script failures is not the same person who writes the script.
> 
> What do you think?
> 
> Example:
> 
> Old:
> 
>    user <at> host:~$ timeout 1s ping localhost
>    PING localhost (127.0.0.1) 56(84) bytes of data.
>    64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.078 ms
> 
> New:
> 
>    user <at> host:~$ timeout 1s ping localhost
>    PING localhost (127.0.0.1) 56(84) bytes of data.
>    64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.078 ms
>    ** Process "ping localhost" was killed with signal 16 since the timeout of 1s was reached. **

I've not sure there is enough distinct actions within timeout(1) to warrant --verbose?
How about doing this in the script?

  timeout 1s ping localhost
  test $? = 124 && echo { 'ping timed out'; exit 1; }

thanks,
Pádraig.





Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Mon, 26 Oct 2015 14:27:01 GMT) Full text and rfc822 format available.

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

From: Thomas Güttler <guettliml <at> thomas-guettler.de>
To: Pádraig Brady <P <at> draigBrady.com>, 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Mon, 26 Oct 2015 15:26:13 +0100

Am 26.10.2015 um 12:44 schrieb Pádraig Brady:
>
> I've not sure there is enough distinct actions within timeout(1) to warrant --verbose?
> How about doing this in the script?
>
>    timeout 1s ping localhost
>    test $? = 124 && echo { 'ping timed out'; exit 1; }
>



The issue was already closed with "wontfix". This leads me to the
conclusion that your are not interested in my answer.

Was your "How about doing this in the script?" really a question?



-- 
Thomas Guettler http://www.thomas-guettler.de/




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Mon, 26 Oct 2015 15:53:01 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Thomas Güttler <guettliml <at> thomas-guettler.de>,
 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Mon, 26 Oct 2015 15:51:57 +0000
On 26/10/15 14:26, Thomas Güttler wrote:
> 
> 
> Am 26.10.2015 um 12:44 schrieb Pádraig Brady:
>>
>> I've not sure there is enough distinct actions within timeout(1) to warrant --verbose?
>> How about doing this in the script?
>>
>>    timeout 1s ping localhost
>>    test $? = 124 && echo { 'ping timed out'; exit 1; }
>>
> 
> The issue was already closed with "wontfix". This leads me to the
> conclusion that your are not interested in my answer.
> 
> Was your "How about doing this in the script?" really a question?

We can always reopen if necessary.
I closed as wontfix for now as the above is a strong suggestion.
Generally one needs to handle the timeout in various ways,
and printing a diagnostic is just one of those.

thanks,
Pádraig




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Mon, 26 Oct 2015 18:37:02 GMT) Full text and rfc822 format available.

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

From: Thomas Güttler <guettliml <at> thomas-guettler.de>
To: Pádraig Brady <P <at> draigBrady.com>, 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Mon, 26 Oct 2015 19:35:57 +0100
Am 26.10.2015 um 16:51 schrieb Pádraig Brady:
> On 26/10/15 14:26, Thomas Güttler wrote:
>>
>>
>> Am 26.10.2015 um 12:44 schrieb Pádraig Brady:
>>>
>>> I've not sure there is enough distinct actions within timeout(1) to warrant --verbose?
>>> How about doing this in the script?
>>>
>>>     timeout 1s ping localhost
>>>     test $? = 124 && echo { 'ping timed out'; exit 1; }
>>>
>>
>> The issue was already closed with "wontfix". This leads me to the
>> conclusion that your are not interested in my answer.
>>
>> Was your "How about doing this in the script?" really a question?
> 
> We can always reopen if necessary.

Who decides if it necessary or not? What needs to be done
to reopen it?

> I closed as wontfix for now as the above is a strong suggestion.
> Generally one needs to handle the timeout in various ways,
> and printing a diagnostic is just one of those.

yes, you are right. This issue is about printing a
message. If other ways are needed, then your
above solution can be used as a skeleton. But this
should be handled in different issues/bug-reports.

Regards,
  Thomas Güttler

-- 
http://www.thomas-guettler.de/




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Mon, 26 Oct 2015 19:51:01 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Thomas Güttler <guettliml <at> thomas-guettler.de>,
 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Mon, 26 Oct 2015 19:49:54 +0000
On 26/10/15 18:35, Thomas Güttler wrote:
> Am 26.10.2015 um 16:51 schrieb Pádraig Brady:
>> On 26/10/15 14:26, Thomas Güttler wrote:
>>>
>>>
>>> Am 26.10.2015 um 12:44 schrieb Pádraig Brady:
>>>>
>>>> I've not sure there is enough distinct actions within timeout(1) to warrant --verbose?
>>>> How about doing this in the script?
>>>>
>>>>     timeout 1s ping localhost
>>>>     test $? = 124 && echo { 'ping timed out'; exit 1; }

I meant:

 test $? = 124 && { echo 'ping timed out' >&2; exit 1; }

>>> The issue was already closed with "wontfix". This leads me to the
>>> conclusion that your are not interested in my answer.
>>>
>>> Was your "How about doing this in the script?" really a question?
>>
>> We can always reopen if necessary.
> 
> Who decides if it necessary or not? What needs to be done
> to reopen it?

This is an open process.
bug control details are at:
https://debbugs.gnu.org/server-control.html

>> I closed as wontfix for now as the above is a strong suggestion.
>> Generally one needs to handle the timeout in various ways,
>> and printing a diagnostic is just one of those.
> 
> yes, you are right. This issue is about printing a
> message. If other ways are needed, then your
> above solution can be used as a skeleton. But this
> should be handled in different issues/bug-reports.

Personally I don't think we need to distinguish these cases.

cheers,
Pádraig.




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 28 Oct 2015 07:17:01 GMT) Full text and rfc822 format available.

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

From: Thomas Güttler <guettliml <at> thomas-guettler.de>
To: 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Wed, 28 Oct 2015 08:16:13 +0100
Am 26.10.2015 um 20:49 schrieb Pádraig Brady:
> On 26/10/15 18:35, Thomas Güttler wrote:
>> Am 26.10.2015 um 16:51 schrieb Pádraig Brady:
>>> On 26/10/15 14:26, Thomas Güttler wrote:
>>>>
>>>>
>>>> Am 26.10.2015 um 12:44 schrieb Pádraig Brady:
>>>>>
>>>>> I've not sure there is enough distinct actions within timeout(1) to warrant --verbose?
>>>>> How about doing this in the script?
>>>>>
>>>>>      timeout 1s ping localhost
>>>>>      test $? = 124 && echo { 'ping timed out'; exit 1; }
> 
> I meant:
> 
>   test $? = 124 && { echo 'ping timed out' >&2; exit 1; }
> 
>>>> The issue was already closed with "wontfix". This leads me to the
>>>> conclusion that your are not interested in my answer.
>>>>
>>>> Was your "How about doing this in the script?" really a question?
>>>
>>> We can always reopen if necessary.
>>
>> Who decides if it necessary or not? What needs to be done
>> to reopen it?
> 
> This is an open process.
> bug control details are at:
> https://debbugs.gnu.org/server-control.html

OK, now I know which software you use to handle the issues. Thank you.

Since we both have different opinions, what to do next?

Is there a escalation workflow guide line?

Regards,
  Thomas Güttler

-- 
http://www.thomas-guettler.de/




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 28 Oct 2015 10:01:01 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Thomas Güttler <guettliml <at> thomas-guettler.de>,
 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Wed, 28 Oct 2015 10:00:22 +0000
reopen 21760

On 28/10/15 07:16, Thomas Güttler wrote:
> Am 26.10.2015 um 20:49 schrieb Pádraig Brady:
>> On 26/10/15 18:35, Thomas Güttler wrote:
>>> Am 26.10.2015 um 16:51 schrieb Pádraig Brady:
>>>> On 26/10/15 14:26, Thomas Güttler wrote:
>>>>>
>>>>>
>>>>> Am 26.10.2015 um 12:44 schrieb Pádraig Brady:
>>>>>>
>>>>>> I've not sure there is enough distinct actions within timeout(1) to warrant --verbose?
>>>>>> How about doing this in the script?
>>>>>>
>>>>>>      timeout 1s ping localhost
>>>>>>      test $? = 124 && echo { 'ping timed out'; exit 1; }
>>
>> I meant:
>>
>>   test $? = 124 && { echo 'ping timed out' >&2; exit 1; }
>>
>>>>> The issue was already closed with "wontfix". This leads me to the
>>>>> conclusion that your are not interested in my answer.
>>>>>
>>>>> Was your "How about doing this in the script?" really a question?
>>>>
>>>> We can always reopen if necessary.
>>>
>>> Who decides if it necessary or not? What needs to be done
>>> to reopen it?
>>
>> This is an open process.
>> bug control details are at:
>> https://debbugs.gnu.org/server-control.html
> 
> OK, now I know which software you use to handle the issues. Thank you.
> 
> Since we both have different opinions, what to do next?
> 
> Is there a escalation workflow guide line?

Reopened until someone else votes.

thanks,
Pádraig.





Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 28 Oct 2015 14:11:02 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Thomas Güttler <guettliml <at> thomas-guettler.de>,
 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Wed, 28 Oct 2015 15:10:33 +0100
On 10/28/2015 11:00 AM, Pádraig Brady wrote:
> Reopened until someone else votes.

I'm 50:50 regarding the usefulness of --verbose.
Writing "killed PRG after N seconds elapsed" sounds like a useful
message, yet I'm afraid that then other requests may follow soon
which may really bloat the code, e.g.

  $ timeout --verbose 10 sleep 5
  timeout: child process terminated after 5.012 seconds.

As it's easy to have a wrapper for the original request, I'd rather
not add it.

BTW: timeout shares stdout/stderr with its child; therefore,
wouldn't the interleaved output be problematic?

Have a nice day,
Berny






Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 28 Oct 2015 14:52:01 GMT) Full text and rfc822 format available.

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

From: Jim Meyering <jim <at> meyering.net>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 21760 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>,
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Wed, 28 Oct 2015 07:50:50 -0700
On Wed, Oct 28, 2015 at 7:10 AM, Bernhard Voelker
<mail <at> bernhard-voelker.de> wrote:
> On 10/28/2015 11:00 AM, Pádraig Brady wrote:
>>
>> Reopened until someone else votes.
>
> I'm 50:50 regarding the usefulness of --verbose.
> Writing "killed PRG after N seconds elapsed" sounds like a useful
> message, yet I'm afraid that then other requests may follow soon
> which may really bloat the code, e.g.
>
>   $ timeout --verbose 10 sleep 5
>   timeout: child process terminated after 5.012 seconds.
>
> As it's easy to have a wrapper for the original request, I'd rather
> not add it.

This is the usual criterion/conclusion: if it is easy to implement the desired
behavior via some other mechanism, we prefer not to add the option.
If we had not adhered to this policy over the decades, coreutils programs
would be far larger and harder to maintain, now.

Please look at these many rejected requests to get a feel for how tricky
it can be: http://www.gnu.org/software/coreutils/rejected_requests.html




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 28 Oct 2015 20:19:02 GMT) Full text and rfc822 format available.

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

From: Bob Proulx <bob <at> proulx.com>
To: Thomas Güttler <guettliml <at> thomas-guettler.de>,
 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Wed, 28 Oct 2015 14:17:59 -0600
Bernhard Voelker wrote:
> Pádraig Brady wrote:
> >Reopened until someone else votes.
> 
> I'm 50:50 regarding the usefulness of --verbose.
> Writing "killed PRG after N seconds elapsed" sounds like a useful
> message, yet I'm afraid that then other requests may follow soon
> which may really bloat the code, e.g.
> 
>   $ timeout --verbose 10 sleep 5
>   timeout: child process terminated after 5.012 seconds.

I am also 50:50 regarding the verbose message output.

For example I don't like the N seconds, or N.012 more detailed output.
As soon as this is produced there will be other people trying to parse
it.  Having that variable data in the middle of the string to parse
makes it more complicated.  Does it matter?  Better would be just to
say as concise as possible "timeout: terminated child process" and
stop there.

Having more verbosity usually sounds good.  But it often isn't.  In my
experience it tends to make the code much more crufty than it would be
otherwise.  Harder to read the actual code for needing to read around
the verbose output statements.  And then because internal code changes
will often change the verbose output it tends to break people who have
come to rely upon those messages.  Meaning it either freezes the
implementation just as it is because changes would change the visible
output or it risks breaking consumers of it if it changes.  It is not
a small problem.

>>Thomas Güttler wrote:
>>> A new team mate wasted some time to debug why
>>> a process was killed with signal 15.
>>>...
>>> This is important in environments where the one who reads
>>> the script failures is not the same person who writes the script.

IMNHO this is a common bad type of thinking.  The root cause of the
problem was created by a bug in a locally written script.  We haven't
seen that script but most likely it will have additional problems.
This bites someone.  Having been bitten this becomes personal.
Regardless of how unique or general having become personal it now
becomes important to make sure that no one else ever suffers this
problem again.  Ever.  Even if it creates additional problems.

One of the hardest things is to balance the creation of additional
problems with eliminating a previous problem.  The simpler of the two
is usually the best choice.

> As it's easy to have a wrapper for the original request, I'd rather
> not add it.

I will reiterate that I don't feel strongly either way.  As long as
the output message is as simple as possible.

> BTW: timeout shares stdout/stderr with its child; therefore,
> wouldn't the interleaved output be problematic?

A good example of a possible problem due to the law of unintended
consequences.  And if this leads to the request for --output-fd=N to
reroute file descriptors just to work around it then that is much too
much and shouldn't be done.

Bob




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Thu, 29 Oct 2015 00:16:02 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: 21760 <at> debbugs.gnu.org
Cc: Thomas Güttler <guettliml <at> thomas-guettler.de>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout was reached
Date: Thu, 29 Oct 2015 00:15:20 +0000
tag 21760 wontfix
close 21760
stop

Thanks for the additional input Jim, Bernhard and Bob.





Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Mon, 02 Oct 2017 14:05:02 GMT) Full text and rfc822 format available.

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

From: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
To: 21760 <at> debbugs.gnu.org
Subject: timeout: Feature Request: --verbose ==> output if timeout
Date: Mon, 2 Oct 2017 15:04:48 +0100
I have to say that I find this bug thread quite perplexing.

It is completely normal for a GNU/Unix command line utility to print a
message to stderr in error cases.  Almost every program that exits
nonzero prints a message to stderr.

The normal convention in shell scripts (and other contexts where
commands are invoked) is to:
  * use the exit status to decide whether to continue executing
  * rely on the failing command to print a message to the script's
    stderr

The stderr error message from a failing command appears on the user's
terminal in a script run interactively; it appears in emailed logs
from cron; it can appear in logfiles; etc.

When I first discovered that GNU timeout(1) does not print an error
message when the timeout occurs, I was astonished.  IMO that ought to
have been the default behaviour.  Unfortunately that is too late to
fix now but we should at least have a one-letter option to request
behaviour compatible with normal shell programming conventions.


The alternative is that at most times when use of timeout is added to
some program or config file, the programmer/administrator will have to
write a clumsy shell circumlocution to arrange that an appropriate
message is sent to stderr.

These runic shell circumlocutions will proliferate.  They will have
bugs.  The bugs will propagate by cut-and-paste, followed by fixes for
the bugs.  Everyone's commands will become verbose and hard to
understand.

All of this could be prevented by simply providing a way to make
timeout print a message to stderr.


I guess I need to dispose of some the potential problems which have
been advanced as counterarguments, even though to my mind they are
extremely weak.

A key observation I would make is that the arguments against
timeout(1) printing a message are fully general counterarguments
against _any_ program printing _any_ error message.  Surely that shows
that they can't be right.

> For example I don't like the N seconds, or N.012 more detailed
> output.  As soon as this is produced there will be other people
> trying to parse it.

Most of the people who are asking for this feature don't care exactly
what the message is.  It should mention the program which was invoked
and the fact that there was a timeout.  The exact format is
immaterial.

The purpose is not for it to be parsed, but for it to be read by
humans who are trying to debug something.  This is generally true of
error messages.

If anyone complains that they are trying to parse this error message
you can tell them not to be so silly.  There will be many fewer of
those than there will be people inconvenienced by the lack of a
message at all.

Likewise, if someone sends a patch to add more information to the
message, that is not a problem.  You can just accept it, or not, as
you like.

> BTW: timeout shares stdout/stderr with its child; therefore,
> wouldn't the interleaved output be problematic?

No.  The purpose is precisely to have the error report from timeout(1)
to go to the same place as errors from the command are reported.

This is not a problem with any other adverbial command, of which there
are very many nowadays.  See for example xargs, fakeroot, faketime,
authbind, etc. etc.

> A good example of a possible problem due to the law of unintended
> consequences.

How bogglesome.  This "interleaving" is precisely the intended
consequence.  (Actually, what will normally happen is that the message
from timeout will follow all of the program's output.)

> And if this leads to the request for --output-fd=N to
> reroute file descriptors just to work around it then that is much too
> much and shouldn't be done.

Other adverbial commands have not had such requests and in general I
agree that they should be rejected.  If this is a problem then a shell
rune can be used to replumb the fds.

That is a hypothetical timeout -v --output-fd=42 blah blah
can be replaced with
   timeout 3>&2 2>&42 -v sh -ec 'exec 2>&3 3>&- "$@"' x blah blah
(assuming fd 3 is not used for something else in $@).  This is
a fully general technique which can be deployed to implement any
such minority use case.


The main point is that "want it to print an error message if there is
an error" is not a minority use case.

Ian.


-- 
Ian Jackson <ijackson <at> chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 04 Oct 2017 06:38:02 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Ian Jackson <ijackson <at> chiark.greenend.org.uk>, 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Tue, 3 Oct 2017 23:36:57 -0700
On 02/10/17 07:04, Ian Jackson wrote:
> I have to say that I find this bug thread quite perplexing.
> 
> It is completely normal for a GNU/Unix command line utility to print a
> message to stderr in error cases.  Almost every program that exits
> nonzero prints a message to stderr.
> 
> The normal convention in shell scripts (and other contexts where
> commands are invoked) is to:
>   * use the exit status to decide whether to continue executing
>   * rely on the failing command to print a message to the script's
>     stderr
> 
> The stderr error message from a failing command appears on the user's
> terminal in a script run interactively; it appears in emailed logs
> from cron; it can appear in logfiles; etc.
> 
> When I first discovered that GNU timeout(1) does not print an error
> message when the timeout occurs, I was astonished.  IMO that ought to
> have been the default behaviour.  Unfortunately that is too late to
> fix now but we should at least have a one-letter option to request
> behaviour compatible with normal shell programming conventions.
> 
> 
> The alternative is that at most times when use of timeout is added to
> some program or config file, the programmer/administrator will have to
> write a clumsy shell circumlocution to arrange that an appropriate
> message is sent to stderr.
> 
> These runic shell circumlocutions will proliferate.  They will have
> bugs.  The bugs will propagate by cut-and-paste, followed by fixes for
> the bugs.  Everyone's commands will become verbose and hard to
> understand.
> 
> All of this could be prevented by simply providing a way to make
> timeout print a message to stderr.
> 
> 
> I guess I need to dispose of some the potential problems which have
> been advanced as counterarguments, even though to my mind they are
> extremely weak.
> 
> A key observation I would make is that the arguments against
> timeout(1) printing a message are fully general counterarguments
> against _any_ program printing _any_ error message.  Surely that shows
> that they can't be right.
> 
>> For example I don't like the N seconds, or N.012 more detailed
>> output.  As soon as this is produced there will be other people
>> trying to parse it.
> 
> Most of the people who are asking for this feature don't care exactly
> what the message is.  It should mention the program which was invoked
> and the fact that there was a timeout.  The exact format is
> immaterial.
> 
> The purpose is not for it to be parsed, but for it to be read by
> humans who are trying to debug something.  This is generally true of
> error messages.
> 
> If anyone complains that they are trying to parse this error message
> you can tell them not to be so silly.  There will be many fewer of
> those than there will be people inconvenienced by the lack of a
> message at all.
> 
> Likewise, if someone sends a patch to add more information to the
> message, that is not a problem.  You can just accept it, or not, as
> you like.
> 
>> BTW: timeout shares stdout/stderr with its child; therefore,
>> wouldn't the interleaved output be problematic?
> 
> No.  The purpose is precisely to have the error report from timeout(1)
> to go to the same place as errors from the command are reported.
> 
> This is not a problem with any other adverbial command, of which there
> are very many nowadays.  See for example xargs, fakeroot, faketime,
> authbind, etc. etc.
> 
>> A good example of a possible problem due to the law of unintended
>> consequences.
> 
> How bogglesome.  This "interleaving" is precisely the intended
> consequence.  (Actually, what will normally happen is that the message
> from timeout will follow all of the program's output.)
> 
>> And if this leads to the request for --output-fd=N to
>> reroute file descriptors just to work around it then that is much too
>> much and shouldn't be done.
> 
> Other adverbial commands have not had such requests and in general I
> agree that they should be rejected.  If this is a problem then a shell
> rune can be used to replumb the fds.
> 
> That is a hypothetical timeout -v --output-fd=42 blah blah
> can be replaced with
>    timeout 3>&2 2>&42 -v sh -ec 'exec 2>&3 3>&- "$@"' x blah blah
> (assuming fd 3 is not used for something else in $@).  This is
> a fully general technique which can be deployed to implement any
> such minority use case.
> 
> 
> The main point is that "want it to print an error message if there is
> an error" is not a minority use case.

Thanks for detailing your arguments, and +2 for the phrase:
"runic shell circumlocutions will proliferate" :)

A reason we don't output a message by default is that
timeout(1) could be used to run a process which runs
for an indeterminate amount of time like:

  timeout --preserve-status 1d ./simulation

Whether we support `timeout --verbose` is one of those marginal cases.
Using shell works with all versions of timeout, but it's not
trivial due to differing exit status. For example if a SIGKILL was sent
most shells return 137, while ksh returns 265.

I agree with you that the stderr interleaving is probably not a practical issue.

So I'm leaning towards supporting --verbose which would output something like:

  timeout: aborting command 'blah' with signal SIGTERM
  timeout: aborting command 'blah' with signal SIGKILL

cheers,
Pádraig




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 04 Oct 2017 10:21:02 GMT) Full text and rfc822 format available.

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

From: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Wed, 4 Oct 2017 11:20:03 +0100
Pádraig Brady writes ("Re: bug#21760: timeout: Feature Request: --verbose ==> output if timeout"):
> Thanks for detailing your arguments, and +2 for the phrase:
> "runic shell circumlocutions will proliferate" :)

YW :-).

> So I'm leaning towards supporting --verbose which would output something like:
> 
>   timeout: aborting command 'blah' with signal SIGTERM
>   timeout: aborting command 'blah' with signal SIGKILL

Yes, please, that would do nicely.

Regards,
Ian.




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 04 Oct 2017 10:21:02 GMT) Full text and rfc822 format available.

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

From: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
To: Pádraig Brady <P <at> draigBrady.com>, 21760 <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Wed, 4 Oct 2017 11:20:47 +0100
Ian Jackson writes ("Re: bug#21760: timeout: Feature Request: --verbose ==> output if timeout"):
> Pádraig Brady writes ("Re: bug#21760: timeout: Feature Request: --verbose ==> output if timeout"):
> >   timeout: aborting command 'blah' with signal SIGTERM
> >   timeout: aborting command 'blah' with signal SIGKILL
> 
> Yes, please, that would do nicely.

I guess we can have -v for this, as well as --verbose ?

Ian.




Reply sent to Pádraig Brady <P <at> draigBrady.com>:
You have taken responsibility. (Thu, 23 Nov 2017 22:36:02 GMT) Full text and rfc822 format available.

Notification sent to Thomas Güttler <guettliml <at> thomas-guettler.de>:
bug acknowledged by developer. (Thu, 23 Nov 2017 22:36:02 GMT) Full text and rfc822 format available.

Message #55 received at 21760-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Ian Jackson <ijackson <at> chiark.greenend.org.uk>, 21760-done <at> debbugs.gnu.org
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Thu, 23 Nov 2017 14:35:44 -0800
[Message part 1 (text/plain, inline)]
On 03/10/17 23:36, Pádraig Brady wrote:
> On 02/10/17 07:04, Ian Jackson wrote:
>> I have to say that I find this bug thread quite perplexing.
>>
>> It is completely normal for a GNU/Unix command line utility to print a
>> message to stderr in error cases.  Almost every program that exits
>> nonzero prints a message to stderr.
>>
>> The normal convention in shell scripts (and other contexts where
>> commands are invoked) is to:
>>   * use the exit status to decide whether to continue executing
>>   * rely on the failing command to print a message to the script's
>>     stderr
>>
>> The stderr error message from a failing command appears on the user's
>> terminal in a script run interactively; it appears in emailed logs
>> from cron; it can appear in logfiles; etc.
>>
>> When I first discovered that GNU timeout(1) does not print an error
>> message when the timeout occurs, I was astonished.  IMO that ought to
>> have been the default behaviour.  Unfortunately that is too late to
>> fix now but we should at least have a one-letter option to request
>> behaviour compatible with normal shell programming conventions.
>>
>>
>> The alternative is that at most times when use of timeout is added to
>> some program or config file, the programmer/administrator will have to
>> write a clumsy shell circumlocution to arrange that an appropriate
>> message is sent to stderr.
>>
>> These runic shell circumlocutions will proliferate.  They will have
>> bugs.  The bugs will propagate by cut-and-paste, followed by fixes for
>> the bugs.  Everyone's commands will become verbose and hard to
>> understand.
>>
>> All of this could be prevented by simply providing a way to make
>> timeout print a message to stderr.
>>
>>
>> I guess I need to dispose of some the potential problems which have
>> been advanced as counterarguments, even though to my mind they are
>> extremely weak.
>>
>> A key observation I would make is that the arguments against
>> timeout(1) printing a message are fully general counterarguments
>> against _any_ program printing _any_ error message.  Surely that shows
>> that they can't be right.
>>
>>> For example I don't like the N seconds, or N.012 more detailed
>>> output.  As soon as this is produced there will be other people
>>> trying to parse it.
>>
>> Most of the people who are asking for this feature don't care exactly
>> what the message is.  It should mention the program which was invoked
>> and the fact that there was a timeout.  The exact format is
>> immaterial.
>>
>> The purpose is not for it to be parsed, but for it to be read by
>> humans who are trying to debug something.  This is generally true of
>> error messages.
>>
>> If anyone complains that they are trying to parse this error message
>> you can tell them not to be so silly.  There will be many fewer of
>> those than there will be people inconvenienced by the lack of a
>> message at all.
>>
>> Likewise, if someone sends a patch to add more information to the
>> message, that is not a problem.  You can just accept it, or not, as
>> you like.
>>
>>> BTW: timeout shares stdout/stderr with its child; therefore,
>>> wouldn't the interleaved output be problematic?
>>
>> No.  The purpose is precisely to have the error report from timeout(1)
>> to go to the same place as errors from the command are reported.
>>
>> This is not a problem with any other adverbial command, of which there
>> are very many nowadays.  See for example xargs, fakeroot, faketime,
>> authbind, etc. etc.
>>
>>> A good example of a possible problem due to the law of unintended
>>> consequences.
>>
>> How bogglesome.  This "interleaving" is precisely the intended
>> consequence.  (Actually, what will normally happen is that the message
>> from timeout will follow all of the program's output.)
>>
>>> And if this leads to the request for --output-fd=N to
>>> reroute file descriptors just to work around it then that is much too
>>> much and shouldn't be done.
>>
>> Other adverbial commands have not had such requests and in general I
>> agree that they should be rejected.  If this is a problem then a shell
>> rune can be used to replumb the fds.
>>
>> That is a hypothetical timeout -v --output-fd=42 blah blah
>> can be replaced with
>>    timeout 3>&2 2>&42 -v sh -ec 'exec 2>&3 3>&- "$@"' x blah blah
>> (assuming fd 3 is not used for something else in $@).  This is
>> a fully general technique which can be deployed to implement any
>> such minority use case.
>>
>>
>> The main point is that "want it to print an error message if there is
>> an error" is not a minority use case.
> 
> Thanks for detailing your arguments, and +2 for the phrase:
> "runic shell circumlocutions will proliferate" :)
> 
> A reason we don't output a message by default is that
> timeout(1) could be used to run a process which runs
> for an indeterminate amount of time like:
> 
>   timeout --preserve-status 1d ./simulation
> 
> Whether we support `timeout --verbose` is one of those marginal cases.
> Using shell works with all versions of timeout, but it's not
> trivial due to differing exit status. For example if a SIGKILL was sent
> most shells return 137, while ksh returns 265.
> 
> I agree with you that the stderr interleaving is probably not a practical issue.
> 
> So I'm leaning towards supporting --verbose which would output something like:
> 
>   timeout: aborting command 'blah' with signal SIGTERM
>   timeout: aborting command 'blah' with signal SIGKILL

Handled in the attached.
Marking this as done.

cheers,
Pádraig

[timeout--verbose.patch (text/x-patch, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Thu, 23 Nov 2017 23:39:02 GMT) Full text and rfc822 format available.

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

From: Jim Meyering <jim <at> meyering.net>
To: 21760 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>, 
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Cc: 21760-done <at> debbugs.gnu.org, Ian Jackson <ijackson <at> chiark.greenend.org.uk>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Thu, 23 Nov 2017 15:38:17 -0800
On Thu, Nov 23, 2017 at 2:35 PM, Pádraig Brady <P <at> draigbrady.com> wrote:
...
>> So I'm leaning towards supporting --verbose which would output something like:
>>
>>   timeout: aborting command 'blah' with signal SIGTERM
>>   timeout: aborting command 'blah' with signal SIGKILL

+          error (0, 0, _("aborting command %s with signal %s"),
+                 quote (command), signame);

I like it, though maybe print "sending signal %s to command %s" ?
Sometimes (as above), the first attempt doesn't affect the process,
much less send SIGABRT, which one might infer from the use of "abort".

Also wording related, "the signal sent upon timeout" appears both in
code and in doc. I'd s/the/any/, since there can be more than one.




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Thu, 23 Nov 2017 23:39:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Fri, 24 Nov 2017 01:49:02 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>, 21760 <at> debbugs.gnu.org,
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Cc: 21760-done <at> debbugs.gnu.org, Ian Jackson <ijackson <at> chiark.greenend.org.uk>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Thu, 23 Nov 2017 17:48:18 -0800
On 23/11/17 15:38, Jim Meyering wrote:
> On Thu, Nov 23, 2017 at 2:35 PM, Pádraig Brady <P <at> draigbrady.com> wrote:
> ...
>>> So I'm leaning towards supporting --verbose which would output something like:
>>>
>>>   timeout: aborting command 'blah' with signal SIGTERM
>>>   timeout: aborting command 'blah' with signal SIGKILL
> 
> +          error (0, 0, _("aborting command %s with signal %s"),
> +                 quote (command), signame);
> 
> I like it, though maybe print "sending signal %s to command %s" ?
> Sometimes (as above), the first attempt doesn't affect the process,
> much less send SIGABRT, which one might infer from the use of "abort".
> 
> Also wording related, "the signal sent upon timeout" appears both in
> code and in doc. I'd s/the/any/, since there can be more than one.
> 

Pushed with those improvements.

thanks for the review,
Pádraig




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Fri, 24 Nov 2017 01:49:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Mon, 27 Nov 2017 15:19:02 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Jim Meyering <jim <at> meyering.net>, 21760 <at> debbugs.gnu.org,
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Cc: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Mon, 27 Nov 2017 16:18:34 +0100
[Message part 1 (text/plain, inline)]
[sending again, because the first try came back with some unclear
error message, and the message didn't show up on the ML so far.]

On 11/24/2017 02:48 AM, Pádraig Brady wrote:
> Pushed with those improvements.

Sorry, this comes a bit late.

That change only added support for the long option, so the attached
makes timeout also recognize the short -v option as advertized in
usage+texi.

BTW: what do you think about a new syntax-check rule to verify that
all options in usage are actually supported?
Some of the option checks for some utilities might become complicated,
but maybe still worth ...

Thanks & have a nice day,
Berny

[0001-timeout-also-support-short-v-option.patch (text/x-patch, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Mon, 27 Nov 2017 18:22:01 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Jim Meyering <jim <at> meyering.net>, 21760 <at> debbugs.gnu.org,
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Cc: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Mon, 27 Nov 2017 10:21:11 -0800
On 27/11/17 07:18, Bernhard Voelker wrote:
> [sending again, because the first try came back with some unclear
> error message, and the message didn't show up on the ML so far.]
> 
> On 11/24/2017 02:48 AM, Pádraig Brady wrote:
>> Pushed with those improvements.
> 
> Sorry, this comes a bit late.
> 
> That change only added support for the long option, so the attached
> makes timeout also recognize the short -v option as advertized in
> usage+texi.

Blush. Please apply.

> BTW: what do you think about a new syntax-check rule to verify that
> all options in usage are actually supported?
> Some of the option checks for some utilities might become complicated,
> but maybe still worth ...

I've caught this particular issue myself in a couple of patches from others,
so I'll write a syntax check later today hopefully.

thanks!
Pádraig




Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Tue, 28 Nov 2017 00:07:02 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Jim Meyering <jim <at> meyering.net>, 21760 <at> debbugs.gnu.org,
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Cc: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Tue, 28 Nov 2017 01:06:18 +0100
[Message part 1 (text/plain, inline)]
On 11/27/2017 07:21 PM, Pádraig Brady wrote:
> Blush. Please apply.

Thanks, pushed.

>> BTW: what do you think about a new syntax-check rule to verify that
>> all options in usage are actually supported?
>> Some of the option checks for some utilities might become complicated,
>> but maybe still worth ...
> 
> I've caught this particular issue myself in a couple of patches from others,
> so I'll write a syntax check later today hopefully.

I've also played a bit ... and it turned out to become a regular
test instead of a syntax-check rule.
It's a draft, and I only tested here on openSUSE:Tumbleweed,
but at least it seems to be a good start.  Maybe it should be
marked as expensive.

Have a nice day,
Berny
[0001-tests-verify-usage-vs.-getopt-DRAFT.patch (text/x-patch, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Tue, 28 Nov 2017 10:04:02 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Jim Meyering <jim <at> meyering.net>, 21760 <at> debbugs.gnu.org,
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Cc: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Tue, 28 Nov 2017 02:03:27 -0800
[Message part 1 (text/plain, inline)]
On 27/11/17 16:06, Bernhard Voelker wrote:
> On 11/27/2017 07:21 PM, Pádraig Brady wrote:
>> Blush. Please apply.
> 
> Thanks, pushed.
> 
>>> BTW: what do you think about a new syntax-check rule to verify that
>>> all options in usage are actually supported?
>>> Some of the option checks for some utilities might become complicated,
>>> but maybe still worth ...
>>
>> I've caught this particular issue myself in a couple of patches from others,
>> so I'll write a syntax check later today hopefully.
> 
> I've also played a bit ... and it turned out to become a regular
> test instead of a syntax-check rule.
> It's a draft, and I only tested here on openSUSE:Tumbleweed,
> but at least it seems to be a good start.  Maybe it should be
> marked as expensive.

Cool stuff. This correlates a lot of things.
It's not that expensive really.
Takes about 9s on my oldish laptop.

This would be the first real use of awk
(I notice one other test using gawk which I'll change to using something else).
Attached is a diff to change to using sed.
Also it simplifies the subsequent sed calls to avoid the separate cases.

thanks!
Pádraig
[getopt-sed.diff (text/x-patch, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Tue, 28 Nov 2017 22:49:02 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Jim Meyering <jim <at> meyering.net>, 21760 <at> debbugs.gnu.org,
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Cc: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Tue, 28 Nov 2017 23:48:00 +0100
[Message part 1 (text/plain, inline)]
On 11/28/2017 11:03 AM, Pádraig Brady wrote:
> Attached is a diff to change to using sed.

Thanks, I merged your changes.

Please note that this new check only works with the patch applied
discussed at:
  http://lists.gnu.org/archive/html/coreutils/2017-11/msg00037.html

Thanks & have a nice day,
Berny
[0001-readlink-remove-superfluous-comma-from-usage-output.patch (text/x-patch, attachment)]
[0002-tests-verify-usage-vs.-getopt.patch (text/x-patch, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 29 Nov 2017 05:44:04 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Jim Meyering <jim <at> meyering.net>, 21760 <at> debbugs.gnu.org,
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Cc: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Tue, 28 Nov 2017 21:43:07 -0800
On 28/11/17 14:48, Bernhard Voelker wrote:
> On 11/28/2017 11:03 AM, Pádraig Brady wrote:
>> Attached is a diff to change to using sed.
> 
> Thanks, I merged your changes.
> 
> Please note that this new check only works with the patch applied
> discussed at:
>    http://lists.gnu.org/archive/html/coreutils/2017-11/msg00037.html
> 

+1

thanks again,
Pádraig





Information forwarded to bug-coreutils <at> gnu.org:
bug#21760; Package coreutils. (Wed, 29 Nov 2017 13:20:02 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Jim Meyering <jim <at> meyering.net>, 21760 <at> debbugs.gnu.org,
 Thomas Güttler <guettliml <at> thomas-guettler.de>
Cc: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
Subject: Re: bug#21760: timeout: Feature Request: --verbose ==> output if
 timeout
Date: Wed, 29 Nov 2017 14:19:15 +0100
On 11/29/2017 06:43 AM, Pádraig Brady wrote:
> +1

Thanks, pushed at:
https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=052cce9e3e92

Have a nice day,
Berny




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 28 Dec 2017 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 6 years and 93 days ago.

Previous Next


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