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. 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 -- 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.tau...@technikum-wien.at I: embsys.technikum-wien.at I: www.technikum-wien.at
