On 10/26/15 11:59 AM, Stefan Tauner wrote:
> Hi,
>
> 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):
>
> $ time sleep 5
> ^Z
> [1]+ Stopped sleep 5
>
> real 0m0.880s
> user 0m0.002s
> sys 0m0.000s
[...]
> I have briefly looked at the code... but there are way too much
> recursions in execute_pipeline() and signal handling all over the place
> that I'd rather not touch it yet. :) However, if you'd give me some
> pointers I can look into it.
If you look at time_command(), you'll see that it prints timing statistics
when execute_command_internal() returns. However, that will return when
the foreground job changes state (since that indicates that the shell
should read and execute another command). The shell isn't structured well
to discover at this point that the most recent job has been suspended, nor
are there enough hooks to print timing statistics when the command is
restarted and finally completes.
--
``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/
