On 10/30/15 3:34 PM, Stefan Tauner wrote:
> On Fri, 30 Oct 2015 14:00:10 -0400
> Chet Ramey <chet.ra...@case.edu> wrote:
>
>> On 10/30/15 12:50 PM, Mike Frysinger wrote:
>>> On 26 Oct 2015 16:59, Stefan Tauner wrote:
>>>> I was creating some exercises for my students when I noticed very
>>>> strange behavior of the time built-in when sending SIGSTOP to a timed
>>>> command interactively (via ^Z):
>>>
>>> you could always install the dedicated time program and then do:
>>> $ /usr/bin/time sleep 5
>>>
>>> that'll handle ^Z and such
>>
>> It's probably already installed, and \time will work to invoke it.
>
> Yes of course and this is the workaround I suggested to my students,
> but this is still a major bug IMHO. The output of time(1) is defined in
> POSIX as "[…]time between invocation of utility and its termination."
> (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/time.html).
> I am not aware of any exceptions...(?) so the bash built-in clearly
> breaks this major aspect of the defined behavior.
It's not a builtin command. It's a commnand modifier -- that's what
allows it to time pipelines and shell builtins, which an external
command cannot do.
The fact that it isn't tied to job control is technically a bug, but a
minor one. It comes up occasionally as a problem.
This is on the list of things to look at, but is not a high priority.
If you'd like to take a shot at modifying bash to support this behavior,
you'd probably have to start with time_command() and go into augmenting
the job structure with timing info.
If you're interested in a survey of shells' implementations of `time',
bash, ksh93, and mksh print timing statistics when the process being
timed is suspended, dash and its siblings don't implement `time' at all,
and zsh behaves as you'd like.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
