Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Use of qualifiers without glob pattern?
- X-seq: zsh-workers 1448
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Zoltan Hidvegi <hzoli@xxxxxxxxxx>
- Subject: Re: Use of qualifiers without glob pattern?
- Date: Wed, 26 Jun 1996 08:54:04 -0700
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: Zoltan Hidvegi <hzoli@xxxxxxxxxx> "Re: Use of qualifiers without glob pattern?" (Jun 26, 4:52pm)
- References: <199606261452.QAA11640@xxxxxxxxxxxxx>
- Reply-to: schaefer@xxxxxxx
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"
Messages sorted by:
Reverse Date,
Date,
Thread,
Author