From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22636 invoked from network); 2 May 2001 15:00:56 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 May 2001 15:00:56 -0000 Received: (qmail 26202 invoked by alias); 2 May 2001 15:00:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14202 Received: (qmail 26166 invoked from network); 2 May 2001 15:00:45 -0000 From: "Bart Schaefer" Message-Id: <1010502150000.ZM14338@candle.brasslantern.com> Date: Wed, 2 May 2001 14:59:59 +0000 In-Reply-To: Comments: In reply to Peter Stephenson "Re: order of processing in brace expansion" (May 2, 10:50am) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Peter Stephenson , zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: order of processing in brace expansion MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 2, 10:50am, Peter Stephenson wrote: } Subject: Re: order of processing in brace expansion } } > If tokenizing when it's not necessary doesn't hurt anything, then I think } > we should fix the bug. ("make check" does pass with the patch applied.) } } I would be fairly confident about this, since there are plenty of other } tokens which might be left hanging around, e.g. #'s or ~'s when } EXTENDEDGLOB isn't set. With regard to zsh-workers/14153: > That is, in all versions of zsh so far, using a parameter expansion is a > way to quote commas against brace expansion while still getting filename > generation after the expansion. I was wondering whether there might be some sort of compromise, such as only tokenizing commas when BRACE_CCL is set. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net