[Top][All Lists]

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

Re: feature enhancement for 'timeout'

From: Pádraig Brady
Subject: Re: feature enhancement for 'timeout'
Date: Wed, 26 Feb 2014 01:11:51 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 02/25/2014 09:51 PM, Thomas Sattler wrote:
> Am 25.02.2014 18:04, schrieb Pádraig Brady:
>> On 02/25/2014 04:57 PM, Thomas Sattler wrote:
>>> Am 25.02.2014 17:30, schrieb Pádraig Brady:
>>>> On 02/25/2014 04:10 PM, Thomas Sattler wrote:
>>>>> How about exporting the DURATION to the command's environment?
>>>> So you mean for timeout(1) to inspect the env and honor a DURATION there?
>>> No, I thought of timeout(1) informing its child process about the
>>> duration. So the command could know about the timeout. (Just for
>>> the unusual case where it could want to know and care about it.)
>>> I'm aware that most commands run via timeout(1) will not make use
>>> of this. On the other hand letting timeout(1) put the duration
>>> into its client process' environment shouldn't hurt either.
>> I'm getting it hard to think of a use case where the managed command
>> could make use of prior knowledge of the timeout.
> You're right, the managed command won't make use of the knowledge of
> its maximum lifetime. But that wasn't the idea.
> I thought of a process that can make use of its environment to build
> strings, for example filenames, and then would be able to include
> the specified duration as a part of a filename.
> I would love to see two keys in the child process' environment: The
> unmodified string as it was given to timeout(1) and the computed
> seconds. Something like this:

I think this is too specialized to add to timeout(1).
Note timeout(1) will propagate env through to the managed command,
so you can set variables as you like:

$ TIMEOUT_VALUE=1 timeout 1 env | grep TIMEOUT


reply via email to

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