time builtin handles backgrounding poorly

[Jack Lloyd]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE  -O2 -g -pipe 
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux wks9 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006 
x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 3.1
Patch Level: 7
Release Status: release

Description:

        The time builtin seems to be confused if something is
        backgrounded, and prints immediately the time rather than
        waiting for the job to complete. I found this very unexpected.

Repeat-By:

$ time sleep 5
# hit C-Z to stop the job before 5 seconds

[1]+  Stopped                 sleep 5

real    0m0.525s
user    0m0.000s
sys     0m0.000s
$ fg
sleep 5
# the 5 second sleep continues
$

Expected behavior is:

$ /usr/bin/time sleep 5
# hit C-Z to suspend
[2]+  Stopped                 /usr/bin/time sleep 5
# wait a little bit here
(wks9 ~)$ fg
/usr/bin/time sleep 5
0.00user 0.00system 0:05.00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+184minor)pagefaults 0swaps

I want to emphasize that this report is *not* about the different
output formats of the bash builtin and GNU time, but that bash does
not wait for the job to complete before printing the output. Instead
it seems to print as soon the prompt returns (?) - except this does
work OK:

$ time sleep 5 &
[2] 20220
$ # wait for 5 seconds
real    0m5.017s
user    0m0.000s
sys     0m0.004s

[2]-  Done                    time sleep 5
$ 

Instead of using C-Z to suspend, you can also send a SIGSTOP to the
sleep process, same result.

I know 3.1.7 is old, but I didn't see anything in the changelog that
suggested this behavior had changed in 3.2. Apologies if it is already
known and/or fixed.