Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: SIGSTOP and bash's time built-in Date: Thu, 29 Oct 2015 20:42:31 -0400 Organization: ITS, Case Western Reserve University Lines: 33 Approved: bug-bash@gnu.org Message-ID: References: <20151026165906.3ceb8d0a@tauner-w510> Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1446165772 9200 208.118.235.17 (30 Oct 2015 00:42:52 GMT) X-Complaints-To: action@cs.stanford.edu Cc: chet.ramey@case.edu To: Stefan Tauner , bug-bash@gnu.org Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <20151026165906.3ceb8d0a@tauner-w510> X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5632BCF7.0153,ss=1,re=0.000,fgs=0, ip=173.191.75.166, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: c80eb8232d19608447aa54be9fb33bd3 X-Junkmail-Whitelist: YES (by domain whitelist at mpv3-2015.case.edu) X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5632BCFA.0046,ss=1,re=0.000,fgs=0, ip=173.191.75.166, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: 981e6d8399dccac1a167c3b980359249 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 129.22.103.194 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11803 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/