From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17347 invoked from network); 16 Nov 2008 21:19:07 -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.6 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 21:19:07 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 60051 invoked from network); 16 Nov 2008 21:18:59 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 16 Nov 2008 21:18:59 -0000 Received: (qmail 20481 invoked by alias); 16 Nov 2008 21:18:54 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26049 Received: (qmail 20466 invoked from network); 16 Nov 2008 21:18:53 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 16 Nov 2008 21:18:53 -0000 Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by bifrost.dotsrc.org (Postfix) with ESMTP id 43C7A80525C9 for ; Sun, 16 Nov 2008 22:18:49 +0100 (CET) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20081116211849.SRSS1717.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Sun, 16 Nov 2008 21:18:49 +0000 Received: from pws-pc.ntlworld.com ([81.107.43.40]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20081116211849.LXHC22934.aamtaout04-winn.ispmail.ntl.com@pws-pc.ntlworld.com> for ; Sun, 16 Nov 2008 21:18:49 +0000 Received: from pws-pc (pws-pc [127.0.0.1]) by pws-pc.ntlworld.com (8.14.2/8.14.2) with ESMTP id mAGLIgK5003632 for ; Sun, 16 Nov 2008 21:18:42 GMT Message-Id: <200811162118.mAGLIgK5003632@pws-pc.ntlworld.com> From: Peter Stephenson To: "Zsh Hackers' List" Subject: Re: parse error in process substitution In-Reply-To: Message from Bart Schaefer of "Sat, 15 Nov 2008 20:10:55 PST." <081115201055.ZM13767@torch.brasslantern.com> Date: Sun, 16 Nov 2008 21:18:42 +0000 X-Cloudmark-Analysis: v=1.0 c=1 a=NLZqzBF-AAAA:8 a=8TRc0Evl07F79Ot_CwgA:9 a=ytISijj5hz27obhW9icA:7 a=nOQ-egV7tkOK9ydnw_mn3ALXIAMA:4 a=_dQi-Dcv4p4A:10 a=fUzIcyR-ki4A:10 X-Virus-Scanned: ClamAV 0.92.1/8636/Sat Nov 15 06:05:47 2008 on bifrost X-Virus-Status: Clean Bart Schaefer wrote: > } ">" 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. I think they're more specialised than I previously assumed. The one I was particularly aiming at was % var="" % print ${var##<([a-z]##|)>} (which still works) which is similar to what's used in Test/comptest. This is probably due to the comment quoted below. > 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. Your're right, I've claimed more than what's actually the case. I think I've achieved what I was mainly aiming at, i.e. allowing anything that was previously valid still to be so (cases like this previously reported a parse error at the "<" or ">"), but it doesn't correspond to what I said in the documentation. The key point is this comment in the lexical analyser: When called from gettok(), with sub = 0, we have already identified any interesting initial character and want to get the rest of what we now know is a string. However, the string may still include metacharacters and potentially substitutions. When called from parse_subst_string() with sub = 1, we are not fully parsing a command line, merely tokenizing a string. In this case we always add characters to the parsed string unless there is a parse error. I've allowed <(...) and >(...) to be expanded when sub = 0, but not when sub = 1, which is what happened before except only if the expansions were complete arguments, so I need to find a better description. "When parsing a string" is close but perhaps doesn't quite express it. (It's not at all obvious why you would ever use the substitutions like that but I'm aiming at consistency rather than imposing arbitrary limitations on cases I don't feel like handling.) > } 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. Yes, that may well be the case, as occurred to me over the weekend, so I don't need to do anything cleverer since I don't want < and > to become special in double quotes. > 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. I haven't changed any of the parsing for redirections: they are handled separately. So it looks like this is now inconsistent and needs fixing. Again, it's not clear why you would ever do that. I suppose since the file name produced by the substitution is essentially opaque to the user you could argue it should report an error in this and similar cases---otherwise, it looks like the case "when parsing a string", with the complication that globs here trigger the multio syntax which isn't relevant to the case of process substitution. An error would probably be simpler. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/