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

[Bob Proulx]

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