From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12268 invoked by alias); 22 Aug 2010 05:42:36 -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: 15317 Received: (qmail 27029 invoked from network); 22 Aug 2010 05:42:34 -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: <100821224229.ZM32224@torch.brasslantern.com> Date: Sat, 21 Aug 2010 22:42:29 -0700 In-reply-to: <20100821194122.583e05e4@pws-pc> Comments: In reply to Peter Stephenson "Re: Synchronous vs. Asynchronous" (Aug 21, 7:41pm) References: <100820083501.ZM29362@torch.brasslantern.com> <20100820164507.419dc0bc@csr.com> <100820103638.ZM29775@torch.brasslantern.com> <20100821194122.583e05e4@pws-pc> 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 21, 7:41pm, Peter Stephenson wrote: } } "external_command > >(blah)" apparently executes "blah" asynchronously } is because it forks "external_command" before starting the process } substitution. Ah, I should have thought of that. } So there's no chance of >(blah) grabbing the terminal when it } shouldn't because it's already associated with a job that's } disconnected from the terminal [...] } (If it tried to talk to the terminal, having } already been forked, the job would be stopped by SIGTTIN, so you'd find } out straight away --- I think that would indicate in this case that the } logic was screwy rather than what we were trying to do was wrong, } however.) Hm. schaefer<515> /bin/echo >>(tty 0<&1) /dev/ttys001 schaefer<520> /bin/echo >>(cat 0<&1) cat: stdin: Input/output error In neither case is there a SIGTTIN, so there's something wrong with this analysis. Nevertheless ... } The change I made simply means it grabs the terminal when it } should, which is when it's in the foreground and there was no fork ... that seem likely correct, because withOUT your patch: schaefer<525> : >>(trap "print Nyah nyah" TTIN; cat 0<&1) cat: stdin: Interrupted system call Nyah nyah Without the trap, I get a silently stopped process with no way to bring it to the foreground, which becomes a zombie if I SIGTERM it. So there definitely is an argument for having *something* wait for those process substitutions. } That's the case of >(...) as an ordinary(**) command line argument Oops, just misconstrued this in my response to Vincent. } I think the difference must be because with >(...) we add the PID to our } job table of things to wait for I'm not sure that's true. schaefer<537> : >(trap "print Nyah nyah" TTIN; cat 0<&1) cat: stdin: Interrupted system call Nyah nyah Here again, if I omit the trap then I end up with a zombie cat. (That sounds like a line from a low-budget horror flick.) Nothing's waiting. } I'm tempted to back off the change for non-redirection process } substitution and attack that separately, and commit the remaining } shebang. I tentatively agree, but confess I've lost precise track of what the end result is. } (**) "the case of >(...) as an ordinary command line argument": This } reminds of a sketch I can vaguely remember of a gorilla travelling on } the Tube (London Underground to overseas visitors) and everyone ignoring } it. It might have been Monty Python. Or I might just have invented it. About 3:30 into this: http://www.youtube.com/watch?v=Px_4JxrIVHc