From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4271 invoked from network); 12 Apr 2000 20:55:06 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 12 Apr 2000 20:55:06 -0000 Received: (qmail 2859 invoked by alias); 12 Apr 2000 20:54:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10714 Received: (qmail 2843 invoked from network); 12 Apr 2000 20:54:55 -0000 To: "Zsh hackers list" Subject: Re: Should we backup this change? RE: Modifier substitutions. In-reply-to: ""Andrej Borsenkow""'s message of "Wed, 12 Apr 2000 19:06:35 +0400." <000601bfa490$b188ed50$21c9ca95@mow.siemens.ru> Date: Wed, 12 Apr 2000 21:54:51 +0100 From: Peter Stephenson Message-Id: "Andrej Borsenkow" wrote: > > ${foo/$bar/...} into ${foo/\\$bar/...} > > The problem is (as I discovered later) it is not complete. There is no > way to anchor pattern to match full string. You should now be able to do ${foo/(#s)$bar(#e)/...}. Unfortunately there's a bug due to the implementation: (#s) always matches, because the substitution only passes the tail end of the string. (#e) works here, but can fail when we are looking for the shortest match for ${...%...}. In principle this isn't hard to keep track of --- the calling code knows whether the beginning or end of the string passed is really that --- but in practice it's messy passing the status into pattry() from igetmatch() in glob.c. I'll think about this. Are there any other areas apart from parameter substitution where the string is longer than we pass to the pattern matching routines? -- Peter Stephenson Work: pws@CambridgeSiliconRadio.com Web: http://www.pwstephenson.fsnet.co.uk