From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id CAA12730 for ; Thu, 27 Jun 1996 02:01:34 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id LAA10735; Wed, 26 Jun 1996 11:53:26 -0400 (EDT) Resent-Date: Wed, 26 Jun 1996 11:53:26 -0400 (EDT) From: "Bart Schaefer" Message-Id: <960626085405.ZM2495@candle.brasslantern.com> Date: Wed, 26 Jun 1996 08:54:04 -0700 In-Reply-To: Zoltan Hidvegi "Re: Use of qualifiers without glob pattern?" (Jun 26, 4:52pm) References: <199606261452.QAA11640@turan.elte.hu> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.607 07jun96) To: Zoltan Hidvegi Subject: Re: Use of qualifiers without glob pattern? Cc: zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"dh8zD3.0.cd2.rpLqn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1448 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jun 26, 4:52pm, Zoltan Hidvegi wrote: } Subject: Re: Use of qualifiers without glob pattern? } } > } > the problem is, $i(:r) gives the same as $i!!! } > } > Gosh, guys, this is pretty basic stuff to have suddenly stop working. } } The (:...) modifiers stopped working only if the argument had no wildcards } so *(:r) always worked. And foo.bar(:r) works only since about a year. Ah. zagzig<1> i=foo.bar zagzig<2> echo $i:r $i(:r) foo foo.bar Hmm. zagzig<3> echo ${i(:r)} zsh: closing brace expected Oh, well. } > This is why I get nervous every time a big patch like the metafication } > stuff gets put in. } } That particular bug is related to the execcmd reorganization Right, I was using metafication for example only. } to allow } things like foo=exec ; $foo bar work which is probably more basic than } the modifiers. I agree (now) that in this case the problem wasn't serious; I thought the parameter-substitution modifiers were broken as well. } In beta21 there was no really serious problems. I'm going to release } beta22 within a couple of days. It will contain a partial solution of the } signal reentrancy problem by saving and resoring some variables which fixes } the most serious problems. Sounds worthwhile. } If no problems reported within a few days } of that release I'll announce this beta in some newsgroups as a 3.0 } pre-release. Has this one, reported a few days ago by someone else, been fixed? zagzig<9> echo "foo\ > $bar" foo$bar That seems like an important thing to get right. } Maybe beta22 is not a good name for that. It may be better } to call it to zsh-2.99.0 as the next stable release will be zsh-3.0.0. Why not 3.0-prerelease, or something like that? } I know that there were many changes since beta16, more than I wanted. RC } announced a feature freeze a year ago. New features were introduced in } beta17 but these new features were already well tested as these were } present in my non-official releases for more than a year. Sine beta17 } there were many conceptual changes to fix long-standing bugs and to improve } sh compatibility. Yes; let me reiterate that I'm happy with all of this, I was just wondering about how much longer it was going to continue. } Also several debug tests were added and these are enabled by default. } These debug messages might give a feeling that recent betas are more buggy } than older ones but most of these bugs were always there. I understand about that. I based my impression on the number of bug reports that crossed the list following release of beta20. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"