From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18852 invoked by alias); 21 Oct 2014 20:08:36 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33487 Received: (qmail 4046 invoked from network); 21 Oct 2014 20:08:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Originating-IP: [80.3.229.105] X-Spam: 0 X-Authority: v=2.1 cv=S8BXwecP c=1 sm=1 tr=0 a=uz1KDxDNIq33yePw376BBA==:117 a=uz1KDxDNIq33yePw376BBA==:17 a=NLZqzBF-AAAA:8 a=uObrxnre4hsA:10 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=20KFwNOVAAAA:8 a=8DwIfwRio5C9p2zHpLgA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 Date: Tue, 21 Oct 2014 21:02:34 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: bug in zsh wait builtin - rhbz#1150541 Message-ID: <20141021210234.199eee3d@pws-pc.ntlworld.com> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 21 Oct 2014 09:53:33 +0200 Tim Speetjens wrote: > I'ld like to report a bug originally filed in > https://bugzilla.redhat.com/show_bug.cgi?id=1150541 which is still present > in the latest version, 5.0.7 > > Title: > zsh wait builtin shows an error and doesn't propagate exit code for a > finished child process There's an explanatory note in the latest POSIX standard about this, quoted below. It seems that the shell is basically required to remember all background processes indefinitely (up to not very helpful get out clauses). As a baseline, CHILD_MAX here is 1024. This probably needs to be a special hash. On most implementations, wait is a shell built-in. If it is called in a subshell or separate utility execution environment, such as one of the following: (wait) nohup wait ... find . -exec wait ... \; it returns immediately because there are no known process IDs to wait for in those environments. Historical implementations of interactive shells have discarded the exit status of terminated background processes before each shell prompt. Therefore, the status of background processes was usually lost unless it terminated while wait was waiting for it. This could be a serious problem when a job that was expected to run for a long time actually terminated quickly with a syntax or initialization error because the exit status returned was usually zero if the requested process ID was not found. This volume of POSIX.1-2008 requires the implementation to keep the status of terminated jobs available until the status is requested, so that scripts like: j1& p1=$! j2& wait $p1 echo Job 1 exited with status $? wait $! echo Job 2 exited with status $? work without losing status on any of the jobs. The shell is allowed to discard the status of any process if it determines that the application cannot get the process ID for that process from the shell. It is also required to remember only {CHILD_MAX} number of processes in this way. Since the only way to get the process ID from the shell is by using the '!' shell parameter, the shell is allowed to discard the status of an asynchronous list if "$!" was not referenced before another asynchronous list was started. (This means that the shell only has to keep the status of the last asynchronous list started if the application did not reference "$!". If the implementation of the shell is smart enough to determine that a reference to "$!" was not saved anywhere that the application can retrieve it later, it can use this information to trim the list of saved information. Note also that a successful call to wait with no operands discards the exit status of all asynchronous lists.) If the exit status of wait is greater than 128, there is no way for the application to know if the waited-for process exited with that value or was killed by a signal. Since most utilities exit with small values, there is seldom any ambiguity. Even in the ambiguous cases, most applications just need to know that the asynchronous job failed; it does not matter whether it detected an error and failed or was killed and did not complete its job normally. pws