Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11803

Re: SIGSTOP and bash's time built-in

From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: SIGSTOP and bash's time built-in
Date 2015-10-29 20:42 -0400
Organization ITS, Case Western Reserve University
Message-ID <mailman.1288.1446165772.7904.bug-bash@gnu.org> (permalink)
References <20151026165906.3ceb8d0a@tauner-w510>

Show all headers | View raw


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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: SIGSTOP and bash's time built-in Chet Ramey <chet.ramey@case.edu> - 2015-10-29 20:42 -0400

csiph-web