On 10/29/2012 11:10 AM, Pádraig Brady wrote:
On 10/29/2012 10:07 AM, Jim Meyering wrote:
These days, I prefer more expressive option names. As long as a short
prefix is unique, length doesn't really matter. Here, --p is enough.
However, --preserve-status seems ok, too. There is precedent for
On 10/29/2012 10:07 AM, Jim Meyering wrote:
These days, I prefer more expressive option names. As long as a short
prefix is unique, length doesn't really matter. Here, --p is enough.
However, --preserve-status seems ok, too. There is precedent for
using "status" to mean "exit status" with md5s
Pádraig Brady wrote:
> On 10/29/2012 08:44 AM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>> ...
>>> Subject: [PATCH] timeout: add --exit-status to always propagate the
>>> command's
>>> exit status
>>>
>>> It's useful for commands that support running for an indeterminite
>>> amount of time,
On 10/29/2012 08:44 AM, Jim Meyering wrote:
Pádraig Brady wrote:
...
Subject: [PATCH] timeout: add --exit-status to always propagate the command's
exit status
It's useful for commands that support running for an indeterminite
amount of time, to not return a specific timeout exit status (124),
Pádraig Brady wrote:
...
> Subject: [PATCH] timeout: add --exit-status to always propagate the command's
> exit status
>
> It's useful for commands that support running for an indeterminite
> amount of time, to not return a specific timeout exit status (124),
> and instead let the command handle t
On Mon Oct 29, 2012 12:43:27AM +, Pádraig Brady wrote:
> On 10/22/2012 01:27 PM, Thomas Krennwallner wrote:
> >On Mon Oct 22, 2012 10:20:14AM +0100, Pádraig Brady wrote:
> >>On 10/21/2012 09:36 PM, Thomas Krennwallner wrote:
> >[...]
> >>>I'm thus very interested into seeing timeout --exit-stat
On 10/22/2012 01:27 PM, Thomas Krennwallner wrote:
On Mon Oct 22, 2012 10:20:14AM +0100, Pádraig Brady wrote:
On 10/21/2012 09:36 PM, Thomas Krennwallner wrote:
[...]
I'm thus very interested into seeing timeout --exit-status.
Ok cool.
It's tempting to support this without an option.
I.E. f
On Mon Oct 22, 2012 10:20:14AM +0100, Pádraig Brady wrote:
> On 10/21/2012 09:36 PM, Thomas Krennwallner wrote:
[...]
> >I'm thus very interested into seeing timeout --exit-status.
>
> Ok cool.
>
> It's tempting to support this without an option.
> I.E. for all commands that exit without WIFSIGNA
On 10/21/2012 09:36 PM, Thomas Krennwallner wrote:
Dear Jim, dear Pádraig,
preserving the command's exit code is useful for, e.g., running solver
competitions, where competition participants have an upper bound on the
runtime for finding solutions to very hard problems.
Imagine you want to run
Dear Jim, dear Pádraig,
preserving the command's exit code is useful for, e.g., running solver
competitions, where competition participants have an upper bound on the
runtime for finding solutions to very hard problems.
Imagine you want to run a command which is outputting (periodically or
on-req
tags 6308 moreinfo
thanks
Pádraig Brady wrote:
> On 30/05/10 01:15, Ángel González wrote:
>> I wanted to keep the original exit status of the command run by
>> timeout(3), even after sending a timeout signal.
>> Thus I added a --exit-status parameter to it. Here it is in case you
>> find that usef
On 30/05/10 01:15, Ángel González wrote:
> I wanted to keep the original exit status of the command run by
> timeout(3), even after sending a timeout signal.
> Thus I added a --exit-status parameter to it. Here it is in case you
> find that useful, too.
Thanks very much for the patch.
At first tho
I wanted to keep the original exit status of the command run by
timeout(3), even after sending a timeout signal.
Thus I added a --exit-status parameter to it. Here it is in case you
find that useful, too.
diff --git a/src/timeout.c b/src/timeout.c
index e2234c3..29f5bec 100644
--- a/src/timeout.c
13 matches
Mail list logo