From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16857 invoked by alias); 14 Oct 2013 12:53:43 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18025 Received: (qmail 1628 invoked from network); 14 Oct 2013 12:53:38 -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 autolearn=ham version=3.3.2 Date: Mon, 14 Oct 2013 14:41:27 +0200 From: Vincent Lefevre To: zsh-users@zsh.org Subject: process substitution bug with set -e? Message-ID: <20131014124126.GA31070@ypig.lip.ens-lyon.fr> Mail-Followup-To: zsh-users@zsh.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.21-6305-vl-r59709 (2013-04-16) The zshexpn(1) man page of zsh 5.0.2 says: There is an additional problem with >(process); when this is attached to an external command, the parent shell does not wait for process to finish and hence an immediately following command cannot rely on the results being complete. The problem and solution are the same as described in the section MULTIOS in zshmisc(1). Hence in a simplified version of the example above: paste <(cut -f1 file1) <(cut -f3 file2) > >(process) (note that no MULTIOS are involved), process will be run asynchronously as far as the parent shell is concerned. The workaround is: { paste <(cut -f1 file1) <(cut -f3 file2) } > >(process) The extra processes here are spawned from the parent shell which will wait for their completion. Now, consider the following script: #!/usr/bin/env zsh set -e { /bin/cp } 2>>(sleep 1; cat -n) Due to /bin/cp failure and the "set -e", the parent shell exits immediately, without waiting for the extra processes: ypig% ./zsh-procsubst ypig% 1 /bin/cp: missing file operand 2 Try '/bin/cp --help' for more information. (tested under Debian/unstable). Shouldn't the parent shell wait in this case? If this is the expected behavior, the man page should be fixed, and possibly give another workaround in the case of set -e. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)