feature: time builtin and file descriptor
Hello, Would it make sense to add to 'time' builtin a way to measure how long a file descriptor is been kept open? Something like this. -- snip #!/bin/bash exec 42>&0 time --file-descriptor 42 sleep 10 exec 42>&- -- snip $ ./above_script.sh real0m10.012s user0m0.000s sys 0m0.000s This idea came to my mind while writing a script that runs multiple commands, and I simply wanted to know how long they are busy. I am aware alternatives exist, but they can get a bit tricky if one wants to have multiple measurements going on simultaneously. For example: exec 42>&0 time --file-descriptor 42 for i in items; in exec 52>&0 time --file-descriptor 52 echo "processing $i" [...] echo "item $i took" exec 52>&- done echo 'all together took:' exec 42>&- What do you think, useful feature or unnecessary bloat? -- Sami Kerola http://www.iki.fi/kerolasa/
Re: feature: time builtin and file descriptor
On 30 October 2014 01:25, Chet Ramey wrote: > On 10/29/14 10:09 AM, Sami Kerola wrote: >> Would it make sense to add to 'time' builtin a way to measure how long >> a file descriptor is been kept open? Something like this. > > You can use $SECONDS for this, but you have to do the math and keep track > of the file descriptors yourself. Hi again, Sounds the there is not much enthusiasm about making this sort of feature to work. This proposal belongs to archived never implemented ideas area. Good that effort wasting was kept minimal. -- Sami Kerola http://www.iki.fi/kerolasa/
Re: feature: time builtin and file descriptor
On 30 October 2014 20:14, Eduardo A. Bustamante López wrote: >> Sounds the there is not much enthusiasm about making this sort of >> feature to work. This proposal belongs to archived never implemented >> ideas area. Good that effort wasting was kept minimal. > Remember that working patches are better than just requesting > features. There are lots of pending features that are requested more > frequently, so that's a lot of work for a single person to handle. I prefer first getting understanding if a feature is wanted, before starting to hack too much. My time has value to me. I don't want to spend it in writing a change that will be rejected. Neither I want to spend maintainer time to go through that sort of stuff. In other words; fail as fast & cheap way as possible is a good workflow. -- Sami Kerola http://www.iki.fi/kerolasa/
