bin/181435: sh(1) wait(1) builtin fails after bg job was SIG(STOP|TSTP|CONT) controlled

[Jilles Tjoelker]

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

From: Jilles Tjoelker <jilles at stack.nl>
To: bug-followup at FreeBSD.org, sdaoden at gmail.com
Cc:  
Subject: Re: bin/181435: sh(1) wait(1) builtin fails after bg job was
 SIG(STOP|TSTP|CONT) controlled
Date: Thu, 22 Aug 2013 00:16:01 +0200

 In PR bin/181435, you wrote:
 > sh(1) wait(1) builtin fails after bg job was
 > SIG(STOP|TSTP|CONT) controlled
 
 There is definitely a bug here because the wait builtin may delete a
 stopped job named on the command line, as if it were done.
 
 Additionally, handling of stopped jobs in general is not as prescribed
 by POSIX, and the handling prescribed by POSIX may be undesirable as
 well.
 
 It looks like POSIX allows 'wait' only on jobs whose "process IDs are
 known in the shell environment", in other words (for jobs that have not
 been waited for yet) when the job was started as an asynchronous list
 and was not used with 'fg', or the job was used with 'bg' and the last
 use with 'bg' was after the last use (if any) with 'fg'. Therefore, kill
 -STOP or -CONT do not affect this. If an explicit job is given and it is
 not "known", it shall be as if it exited with status 127; there shall be
 no error message. This is certainly not nice.
 
 The POSIX behaviour for operandless wait seems less strange. However, it
 is still harder to understand than sh's current behaviour of waiting for
 all jobs that are not stopped (it is the same if you do not use kill to
 stop or continue processes). Note that sh only uses WUNTRACED |
 WCONTINUED if interactive (and job control is compiled in).
 
 A further related change is r238865 which makes 10-current sh use
 WCONTINUED. This is not in older branches.
 
 -- 
 Jilles Tjoelker