From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24467 invoked by alias); 28 Mar 2013 15:47:10 -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: 31184 Received: (qmail 28080 invoked from network); 28 Mar 2013 15:47:08 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130328084639.ZM28782@torch.brasslantern.com> Date: Thu, 28 Mar 2013 08:46:39 -0700 In-reply-to: <1364325715.29901.140661209502305.67203343@webmail.messagingengine.com> Comments: In reply to Anthony Heading "exec >& >(tee hello)" (Mar 26, 3:21pm) References: <1364325715.29901.140661209502305.67203343@webmail.messagingengine.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: exec >& >(tee hello) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Mar 26, 3:21pm, Anthony Heading wrote: } } On zsh (5.0 and 4.2.6 - rhel5 x64), this command hangs: } zsh -c 'exec >& >(tee hello)' } It seems to work OK with bash. Define "work". Zsh is waiting for "tee hello" to finish. It's part of the current command line, and nothing was put in the background, so the current command is in the foreground until all parts of it finish. From a job management perspective this is the same as { exec >& } | tee hello Perhaps exec >& >(tee hello &) is what you want? (Older versions of zsh put >(...) entirely in the background rather than treat them as a component of the command line, but that led to race conditions and processes still running after the parent shell exited and various other confusion.) However, there does seem to be a signal-handling bug with your original command. When run in an interactive shell, it probably ought to be possible to interrupt or suspend the >(...) once zsh gets to the point of waiting for it, but that doesn't work. Note that both bash and zsh will exit on a SIGPIPE if the tee is killed.