[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ian Jackson
Subject: bug#21760: 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

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

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

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 Jackson <address@hidden>   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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]