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