From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18470 invoked by alias); 20 Aug 2010 17:36:57 -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: 15308 Received: (qmail 4105 invoked from network); 20 Aug 2010 17:36:55 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <100820103638.ZM29775@torch.brasslantern.com> Date: Fri, 20 Aug 2010 10:36:38 -0700 In-reply-to: <20100820164507.419dc0bc@csr.com> Comments: In reply to Peter Stephenson "Re: Synchronous vs. Asynchronous" (Aug 20, 4:45pm) References: <100820083501.ZM29362@torch.brasslantern.com> <20100820164507.419dc0bc@csr.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: Synchronous vs. Asynchronous MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Aug 20, 4:45pm, Peter Stephenson wrote: } } > So if we're going to cause zsh to wait for >(...), we should change } > the description in the documentation to no longer say "asynchronous". } } Actually, I think it already does that, except in the case of a builtin not } run inside { ... } Based on Vincent's description, it's an external command not run inside { ... } for which it becomes asynchronous. Any builtin, including any command in { ... }, does make it synchronous. (All of this begs the question of what happens with <(...), but that's less likely to be noticed by anyone.) } My big remaining worry is whether the >(...) could think it's in the } foreground when it's actually in the background after the patch in the } second subthread. Yes, mine too.