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: > > TIMEOUT_VALUE=3m > TIMEOUT_SECONDS=180
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 TIMEOUT_VALUE=1 thanks, Pádraig.
