From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23869 invoked by alias); 12 Sep 2017 14:34:04 -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: 41687 Received: (qmail 8077 invoked by uid 1010); 12 Sep 2017 14:34:03 -0000 X-Qmail-Scanner-Diagnostics: from cventin.lip.ens-lyon.fr by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(140.77.13.17):SA:0(-1.9/5.0):. Processed in 2.325654 secs); 12 Sep 2017 14:34:03 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Date: Tue, 12 Sep 2017 16:21:45 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: trap, eval and wait (was: [BUG] exec + builtin and traps) Message-ID: <20170912142145.GA10597@cventin.lip.ens-lyon.fr> Mail-Followup-To: zsh-workers@zsh.org References: <20170912100257.GA32535@zira.vinc17.org> <20170912111906.397cffec@pwslap01u.europe.root.pri> <20170912103919.GA1794@zira.vinc17.org> <20170912115006.4d1b964d@pwslap01u.europe.root.pri> <20170912114220.GB1794@zira.vinc17.org> <20170912125139.4f698399@pwslap01u.europe.root.pri> <20170912120237.GA7326@zira.vinc17.org> <20170912131054.4f7c11a5@pwslap01u.europe.root.pri> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170912131054.4f7c11a5@pwslap01u.europe.root.pri> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.9.0-7151-vl-r99863 (2017-09-05) On 2017-09-12 13:10:54 +0100, Peter Stephenson wrote: > On Tue, 12 Sep 2017 14:02:37 +0200 > Vincent Lefevre wrote: > > Why is "foo" (from the trap) printed before "bar", then? > > OK, so it's on the *sub* list after the command before the && > (wait) has executed successfully, but before the foo is executed. I still don't understand. Actually, the real issue is that "wait" should not have terminated successfully. Perhaps, this should be clearer with: ------------------------------------------------------------ trap 'echo foo' USR1 ( sleep 1; kill -USR1 $$; sleep 1; echo child ) & eval "wait && echo bar" echo OK sleep 2 ------------------------------------------------------------ After 1 second, the following is printed: foo bar OK And after another second: child So, this means that the "wait" has ended due to the USR1 signal, not by a process termination. But then, the fact that "wait" terminates with the exit status 0 does not seem to be correct. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)