Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail From: Stefan Tauner Newsgroups: gnu.bash.bug Subject: Re: SIGSTOP and bash's time built-in Date: Fri, 30 Oct 2015 20:34:02 +0100 Lines: 52 Approved: bug-bash@gnu.org Message-ID: References: <20151026165906.3ceb8d0a@tauner-w510> <20151030165022.GM5154@vapier.lan> <5633B02A.30309@case.edu> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1446233662 12770 208.118.235.17 (30 Oct 2015 19:34:22 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: chet.ramey@case.edu Envelope-to: bug-bash@gnu.org X-Virus-Scanned: Debian amavisd-new at polyxena.technikum-wien.at In-Reply-To: <5633B02A.30309@case.edu> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.245.225.22 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:11810 On Fri, 30 Oct 2015 14:00:10 -0400 Chet Ramey wrote: =20 > 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): > >=20 > > you could always install the dedicated time program and then do: > > $ /usr/bin/time sleep 5 > >=20 > > that'll handle ^Z and such >=20 > 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 "[=E2=80=A6]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. I'd rather see the built-in removed than continuing to provide a known bad implementation... but I guess that opinion/expectation is rather far-fetched :) > 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. Thanks four that explanation. It does not sound too encouraging thus I really hope someone will beat me to fixing it :) KR --=20 Dipl.-Ing. Stefan Tauner Research and Development Embedded Systems Department University of Applied Sciences Technikum Wien Hoechstaedtplatz 6, 1200 Vienna, Austria T: +43 1 3334077-316 E: stefan.tauner@technikum-wien.at I: embsys.technikum-wien.at I: www.technikum-wien.at