From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1930 invoked from network); 13 Nov 2008 21:08:29 -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; 13 Nov 2008 21:08:29 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 20581 invoked from network); 13 Nov 2008 21:08:24 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 13 Nov 2008 21:08:23 -0000 Received: (qmail 3971 invoked by alias); 13 Nov 2008 21:08:20 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26043 Received: (qmail 3958 invoked from network); 13 Nov 2008 21:08:19 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 13 Nov 2008 21:08:19 -0000 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by bifrost.dotsrc.org (Postfix) with ESMTP id 2BD5F80524C3 for ; Thu, 13 Nov 2008 22:08:14 +0100 (CET) Received: by ug-out-1314.google.com with SMTP id 36so1550326ugg.18 for ; Thu, 13 Nov 2008 13:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=3n7HhC3lMOmZDpi0Cnm8o8QLLrO8cv5NTY5+Oj+Zi0s=; b=kPth+j6uKjomTH2kavRYNKYTMMA6Qh5ZXXu//0/A/x+5YwLv3ZWxaNm+IAS6qi99HB 7vcLjWnsrjODOEC4ZxXcjoCyEoWw91WIkN9TkYbBH654bolABdxj63tHUThN9GRiLPJ6 kdkeID7UnmgHzxX59M1i5ao7JNCf59uoHZpTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uOVTtzruux2JzRgQRR4ICdYX0iGAYcYtJvA2LRTfVsUsHUDrpLjkYvnVGA1cLY1xlq 7MOZA63d6jiE8Efn9FscXvO1zKD0d/6lbT2CEpqiAz/T+UNH8ykwrbgmlCMOCAcimNXJ Kt2QAyKhTM8VeTtoPNZbm2YtrTUAaxeHon4Do= Received: by 10.210.120.7 with SMTP id s7mr189191ebc.78.1226610494395; Thu, 13 Nov 2008 13:08:14 -0800 (PST) Received: by 10.210.73.14 with HTTP; Thu, 13 Nov 2008 13:08:14 -0800 (PST) Message-ID: <237967ef0811131308g7cca30fdua963c9f375c31da@mail.gmail.com> Date: Thu, 13 Nov 2008 22:08:14 +0100 From: "Mikael Magnusson" To: "Zsh Hackers' List" Subject: Re: parse error in process substitution In-Reply-To: <20081113210044.4cea912c@pws-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081106150224.GA10992@apartia.fr> <081106082517.ZM27477@torch.brasslantern.com> <20081110082152.GA9563@apartia.fr> <20081110142850.0add2680@news01> <20081112105241.40c116d9@news01> <20081113210044.4cea912c@pws-pc> X-Virus-Scanned: ClamAV 0.92.1/8628/Thu Nov 13 16:57:02 2008 on bifrost X-Virus-Status: Clean 2008/11/13 Peter Stephenson : > On Mon, 10 Nov 2008 09:21:52 +0100 > Louis-David Mitterrand wrote: >> So how would you convert that working bash command to zsh? >> >> root-tail <(ssh root@my.host.name tail -F /var/log/kern.log),red, > > This fixes the syntax. Unfortunately, I had to impose some limitations > to prevent existing stuff stopping working. Obviously I'd like to > know about anything else this messes up. I'm not worried about > the undocumented feature that <(...) forced a new word. > > 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. However, you can now put other things after > it. > > ">" 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. (The comptest function falls over if > this isn't done.) This isn't likely to be a big problem > in practice. Because of the previous rule this isn't relevant to > =(...). > > 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). > > Index: README > =================================================================== > RCS file: /cvsroot/zsh/zsh/README,v > retrieving revision 1.58 > diff -u -r1.58 README > --- README 30 Oct 2008 12:18:54 -0000 1.58 > +++ README 13 Nov 2008 20:46:40 -0000 > @@ -69,6 +69,16 @@ > consistent with recent versions of other shells. The option > DEBUG_BEFORE_CMD can be unset to revert to the previous behaviour. > > +Previously, process substitutions of the form =(...), <(...) and > +>(...) were only handled if they appeared as separate command arguments, > +although the latter two forms caused a new command argument to be > +started at that point. This sentence is somewhat confusing, but i guess it means that <() and >() always started a new command argument even if they weren't separate... :) > +Now all three may be followed by other strings, > +and the latter two may also be preceeded by other string. strings > +is subject to process substitution. The expression may be proceeded preceeded > +or followed by other strings except that, to prevent clashes with > +commonly occurring strings and patterns, the last > +form must occur at the start of a command argument, and none of > +the forms may occur inside parentheses used for grouping of patterns or > +inside parameter substitutions. > + > In the case of the tt(<) or tt(>) forms, the shell runs process > var(list) asynchronously. If the system supports the tt(/dev/fd) > mechanism, the command argument is the name of the device file Should this be "the process list"? -- Mikael Magnusson