From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18848 invoked from network); 6 Mar 2009 04:55:11 -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=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; 6 Mar 2009 04:55:11 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 73977 invoked from network); 6 Mar 2009 04:55:02 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 Mar 2009 04:55:02 -0000 Received: (qmail 15299 invoked by alias); 6 Mar 2009 04:54:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26691 Received: (qmail 15290 invoked from network); 6 Mar 2009 04:54:54 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 6 Mar 2009 04:54:54 -0000 Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by bifrost.dotsrc.org (Postfix) with ESMTP id 7B36C80307F7 for ; Fri, 6 Mar 2009 05:54:51 +0100 (CET) Received: from torch.brasslantern.com ([173.67.122.60]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KG2005AUIYMZR52@vms173005.mailsrvcs.net> for zsh-workers@sunsite.dk; Thu, 05 Mar 2009 22:54:27 -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 n264sLrC005162 for ; Thu, 05 Mar 2009 20:54:22 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n264sLsq005161 for zsh-workers@sunsite.dk; Thu, 05 Mar 2009 20:54:21 -0800 From: Bart Schaefer Message-id: <090305205421.ZM5160@torch.brasslantern.com> Date: Thu, 05 Mar 2009 20:54:19 -0800 In-reply-to: <200903051746.n25HkB77026580@news01.csr.com> Comments: In reply to Peter Stephenson "Re: expansion of environment variables" (Mar 5, 5:46pm) References: <090305081548.ZM4603@torch.brasslantern.com> <20090305165400.3fd18bc6@news01> <090305092126.ZM4727@torch.brasslantern.com> <200903051746.n25HkB77026580@news01.csr.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk Subject: Re: expansion of environment variables MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.92.1/9077/Fri Mar 6 03:48:57 2009 on bifrost X-Virus-Status: Clean [>workers] On Mar 5, 5:46pm, Peter Stephenson wrote: } } You're right, I missed that last step, there is indeed stuff in tmp1 } including the correct completion. I've been staring at this and I've concluded (possibly wrongly) that even the stuff in tmp1 is a bit of a red herring. Correct me, but isn't the real problem that the string on the line still looks like "$key." but all of the possible matches look like "2345.xml"? The literal string "$key" is not going to match the literal string "2345" no matter what we do with prefixes, and the -U option (if it helps at all) is merely going to overwrite "$key." with "2345." which is exactly the behavior we were asked how avoid in the first place. This may be a case where the factoring of the old internals into the set of comp* builtins has resulted in a loss of information. We can figure out that [[ 2345.xml = $key.* ]] but it's a lot harder to figure out based on that, that "$key.xml" is what needs to be fed into compadd instead of "2345.xml". What we need is something that recurses along the strings the way that the internals of matchers do, but that knows about parameter replacements instead of (or as well as) matching classes. --