The following reply was made to PR bin/35055; it has been noted by GNATS.

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/35055: /bin/sh wait bug
Date: Sun, 26 Nov 2006 18:52:29 +0000

 On Sun, Nov 26, 2006 at 07:30:03AM +0000, Wada Keiji wrote:
 >  
 >  dieter.r>  > #!/bin/sh
 >  dieter.r>  > #!/emul/freebsd/bin/sh
 >  dieter.r>  > sleep 3 &
 >  dieter.r>  > sleep 1 &
 >  dieter.r>  > 
 >  dieter.r>  > wait %1
 >  dieter.r>  > r1=$?
 >  dieter.r>  > echo $r1
 >  dieter.r>  > wait %2
 >  dieter.r>  > r2=$?
 >  dieter.r>  > echo $r2
 >  dieter.r>  > -----
 >  dieter.r>  > Both r1 and r2 should be 0.
 >   
 >  dieter.r>  Why do you think so? By the time the first wait returns,
 >  dieter.r> the second sleep has finished and so you don't have a job 2
 >  dieter.r> anymore. 127 is the return value wait gives when you specify
 >  dieter.r> a non-existing child.
 
 I've just read the SUS spec
 http://www.opengroup.org/onlinepubs/009695399/utilities/wait.html
 It states: This volume of IEEE Std 1003.1-2001 requires the implementation
 to keep the status of terminated jobs available until the status is requested
 
 	David
 
 -- 
 David Laight: david@l8s.co.uk