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 MAA27160 for <mason@werple.mira.net.au>; Thu, 27 Jun 1996 12:24:45 +1000 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id WAA18353; Wed, 26 Jun 1996 22:16:54 -0400 (EDT)
Resent-Date: Wed, 26 Jun 1996 22:16:54 -0400 (EDT)
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
Message-Id: <199606270103.DAA05565@hzoli.ppp.cs.elte.hu>
Subject: Re: Use of qualifiers without glob pattern?
To: schaefer@nbn.com
Date: Thu, 27 Jun 1996 03:03:57 +0200 (MET DST)
Cc: zsh-workers@math.gatech.edu
In-Reply-To: <960626085405.ZM2495@candle.brasslantern.com> from Bart Schaefer at "Jun 26, 96 08:54:04 am"
X-Mailer: ELM [version 2.4ME+ PL17 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"262jT1.0.hU4.MyUqn"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/1453
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

> } 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

$i:r and $i(:r) are different.  The former always works when $i is expanded
while the later is special form of filename generation (globbing).

> zagzig<3> echo ${i(:r)}
> zsh: closing brace expected

Yes, because (:r) is a glob modifier which only works if the word ends in
an unquoted closing parenthesis and there are no wildcards or embeded
parenthesis in this trailing parenthesized part of the word.

> 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.

Yes, I already fixed that but I did not send the patch.  The patch below
fixes that.

> } 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 think it is better if there are only numbers in the version since it is
easier to parse in scripts.  Also 3.0-prerelease is too long. 3.0-pre1 may
be better.  I used to have version specific code in my startup files but
removed these since it became too complicated to handle things like
2.5.03, 2.6-beta9, 2.6-beta21, 2.6-beta15-hzoli14, 2.6-beta??-test??
(fortunately I never tried any version older than 2.5.0 so that case can be
omitted).

But fortunately 3.0-something lexicographically comes before 3.0.something
so it is easy to handle this case which means that the next release may be
called 3.0-pre1.

Zoltan


rcsdiff -qc -kk -r2.26 -r2.27 Src/lex.c
*** Src/lex.c
--- Src/lex.c	1996/06/25 23:15:04	2.27
***************
*** 1016,1022 ****
  		add(c == '$' || c == '\\' || (c == '}' && !intick && bct) ||
  		    c == '\"' || c == '`' ? Bnull : '\\');
  	    else if (sub || unset(CSHJUNKIEQUOTES) || endchar != '"')
! 		c = hgetc();
  	    break;
  	case '\n':
  	    err = !sub && isset(CSHJUNKIEQUOTES) && endchar == '"';
--- 1016,1022 ----
  		add(c == '$' || c == '\\' || (c == '}' && !intick && bct) ||
  		    c == '\"' || c == '`' ? Bnull : '\\');
  	    else if (sub || unset(CSHJUNKIEQUOTES) || endchar != '"')
! 		continue;
  	    break;
  	case '\n':
  	    err = !sub && isset(CSHJUNKIEQUOTES) && endchar == '"';