From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2786 invoked from network); 16 Nov 2008 04:11:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 16 Nov 2008 04:11:47 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 82481 invoked from network); 16 Nov 2008 04:11:40 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 16 Nov 2008 04:11:40 -0000 Received: (qmail 13296 invoked by alias); 16 Nov 2008 04:11:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26048 Received: (qmail 13287 invoked from network); 16 Nov 2008 04:11:35 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 16 Nov 2008 04:11:35 -0000 Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by bifrost.dotsrc.org (Postfix) with ESMTP id 8F0BB80524C4 for ; Sun, 16 Nov 2008 05:11:30 +0100 (CET) Received: from torch.brasslantern.com ([96.238.220.215]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KAE006HPRM89VW2@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 15 Nov 2008 22:10:57 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id mAG4AtZZ013769 for ; Sat, 15 Nov 2008 20:10:56 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id mAG4Atcb013768 for zsh-workers@sunsite.dk; Sat, 15 Nov 2008 20:10:55 -0800 Date: Sat, 15 Nov 2008 20:10:55 -0800 From: Bart Schaefer Subject: Re: parse error in process substitution In-reply-to: <20081113210044.4cea912c@pws-pc> To: "Zsh Hackers' List" Message-id: <081115201055.ZM13767@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20081106150224.GA10992@apartia.fr> <081106082517.ZM27477@torch.brasslantern.com> <20081110082152.GA9563@apartia.fr> <20081110142850.0add2680@news01> <20081112105241.40c116d9@news01> <20081113210044.4cea912c@pws-pc> Comments: In reply to Peter Stephenson "Re: parse error in process substitution" (Nov 13, 9:00pm) X-Virus-Scanned: ClamAV 0.92.1/8636/Sat Nov 15 06:05:47 2008 on bifrost X-Virus-Status: Clean On Nov 13, 9:00pm, Peter Stephenson wrote: } } A non-initial = usually isn't handled specially, and raw parentheses } (i.e. without a disambiguating character in front) are somewhat } overworked in zsh, so I couldn't make =(...) special anywhere except at } the start of an argument. I think this is OK, as it's already ambiguous with respect to array assignment syntax when not at the start of a word. I"m glad to see that var==(cmd) still assigns a file name to $var. } ">" and "<" never used to need quoting when used inside parentheses or } parameter substitutions, so to keep this I've had to forbid the use of } <(...) and >(...) in such places. Can you give examples of a couple of "such places"? I thought I knew what you meant, but when I try what I thought should fail, it doesn't. For example: schaefer[514] echo x<(echo foo)y x/proc/self/fd/11y schaefer[515] echo (<(echo foo)|>(echo bar)) bar zsh: bad pattern: (/proc/self/fd/11|/proc/self/fd/13) OK, so it's a bad pattern, but the substitutions still happened. } Parsing of the contents of these expressions is done rather more simply } than for $(...) expressions. I don't really know if there's any mileage } in making parsing of process substitutions more similar (inside the } parentheses only, the context dependence will have to remain } different). Is the $(...) one perhaps more complex because it has to work inside double-quotes and therefore with possible quote nesting? Otherwise I would think that the simplest parse that doesn't fail on convoluted cases is the one that both of them should be using. One last item ... perhaps you can explain what's going on here: schaefer[518] cat <<(echo foo)what? foo schaefer[519] I'm not sure exactly what I expected, but that wasn't it.