From owner-freebsd-bugs@FreeBSD.ORG Wed Aug 21 22:20:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5B261EF for ; Wed, 21 Aug 2013 22:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4571920C2 for ; Wed, 21 Aug 2013 22:20:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7LMK1wq056814 for ; Wed, 21 Aug 2013 22:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7LMK1dg056813; Wed, 21 Aug 2013 22:20:01 GMT (envelope-from gnats) Date: Wed, 21 Aug 2013 22:20:01 GMT Message-Id: <201308212220.r7LMK1dg056813@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Jilles Tjoelker Subject: Re: bin/181435: sh(1) wait(1) builtin fails after bg job was SIG(STOP|TSTP|CONT) controlled X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jilles Tjoelker List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 22:20:02 -0000 The following reply was made to PR bin/181435; it has been noted by GNATS. From: Jilles Tjoelker To: bug-followup@FreeBSD.org, sdaoden@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