zsh-3.1.2-zefram4

zsh-3.1.2-zefram4

[Andrew Main]

-----BEGIN PGP SIGNED MESSAGE-----

Time for the next unofficial release.  Version 3.1.2-zefram4 exists, and,
as before, ftp space is hereby requested.  I have made patches relative
to 3.1.2 and 3.1.2-zefram3.  The full release tar also contains man
pages and texinfo this time.

Sizes:

145125 zsh-3.1.2-3.1.2-zefram4.diff.gz
 37128 zsh-3.1.2-zefram3-3.1.2-zefram4.diff.gz
832208 zsh-3.1.2-zefram4.tar.gz

MD5 checksums:

0599b5675ed14971135076834f095d7f  zsh-3.1.2-3.1.2-zefram4.diff.gz
b0726775a56e5647d2608e8e482dc7c4  zsh-3.1.2-zefram3-3.1.2-zefram4.diff.gz
ea1fd24e02836cb819e765bf72328fcf  zsh-3.1.2-zefram4.tar.gz

Changes
=======

There are lots of fixes for the build process.  There are a few
outstanding bug reports from zefram3, but I can't be sure which
reported bugs have actually been fixed.  Therefore please report any
build problems with zefram4, even if you previously reported the same
problem with zefram3.

Most nifty compctls that have been posted are included, though I don't
think any of them are unmodified.  Could the various authors please
check that I haven't broken anything.

Peter's KSH_GLOB patch is included, but I backed out a lot of the changes.
I'd like to have options affect as little as possible, preferably just one
thing each: KSH_GLOB in this version *only* affects the interpretation
of parens preceded by the magic characters (in fact, the option is
only tested on one line of the source).  Parens *not* preceded by the
magic characters are unaffected by the option.  Glob qualifies are also
unaffected: that `-', mandatory with KSH_GLOB and forbidden without,
was just too nasty to use.  I added an option BARE_GLOB_QUAL to enable
interpretation of glob qualifiers -- in a future version I'd like to add
an unambiguous syntax (maybe `(&...)') to make glob qualifiers available
in ksh emulation mode.

I also backed out the special handling of `(^...)', which changed
the semantics of `^' in an extremely non-obvious way.  You can use
`(^(...))' to invert the whole group.  This turned up a very old
bug in the exclusion handling: `(foo~bar)BAZ' is actually treated as
`fooBAZ~barBAZ', rather than the exclusion being properly localised.
This bug is not fixed in the zefram4 release -- it has taken long enough
already.  It'll be fixed in the next release, by me unless someone
else gets to it first.  The Misc/globtests scripts do a proper test of
exclusions, and so some of those tests currently fail.

The Zoltan Situation
====================

I think it's pretty obvious by now that Zoltan will not be taking an
active part in zsh development in the foreseeable future.  It's time to
start thinking about a permanent replacement in the post of maintainer.
Opinions are hereby solicited.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: ascii

iQEVAwUBNSwPVpmk9GeOHh7BAQEzPwf/RKKxZM6FIcpa4n+GzicHPzpDGkd2LpM5
4rM8IMh/sJ5xItI6UFLTwN/v2vgAIi4/3u0fysiVdlgLOiKL0UXt+otI7QwMGRG2
UXIX4zwnd9s9Ck4nKQIOf+dxYpjMnVBkHYdn1WiILLAW2OOM3rkI0B/8Np+U3IEu
eSupESQiYJMe+iWUxzrdqn+zMLcXkp97sWiiJg6qcHLXJU6+GB1SxR4Z/NaTsFGM
3ueqvyunsRKhMhJgpeEzxaX4bWyzWFZsWvuji6lzm+Rbk8IeAXuigC0gBE49BTFr
sJgIqinO5EWAa0Uhy0sWC2+f83SBYDY1DB9xzoG+B8QZydRmHs4bfw==
=H+go
-----END PGP SIGNATURE-----

Re: zsh-3.1.2-zefram4

[Richard Coleman]

> The Zoltan Situation
> ====================
> 
> I think it's pretty obvious by now that Zoltan will not be taking an
> active part in zsh development in the foreseeable future.  It's time to
> start thinking about a permanent replacement in the post of maintainer.
> Opinions are hereby solicited.

Unless you don't want to do it, you're elected (or drafted, as the
case may be).

Once you find a site to host it, I'll point my automatic mirror at
that site.

Richard Coleman
coleman@math.gatech.edu

Re: zsh-3.1.2-zefram4

[Louis-David Mitterrand]

On Thu, Apr 09, 1998 at 11:21:50PM -0400, Richard Coleman wrote:
> > The Zoltan Situation
> > ====================
> >
> > I think it's pretty obvious by now that Zoltan will not be taking an
> > active part in zsh development in the foreseeable future.  It's time to
> > start thinking about a permanent replacement in the post of maintainer.
> > Opinions are hereby solicited.
>
> Unless you don't want to do it, you're elected (or drafted, as the
> case may be).

As a simple user I've always noticed Zefram's dedication and
helpfulness, even on trivial questions. I also trust his judgement on
what patches to include into zsh because his decisions are always
soundly argumented and well explained. Zefram is the ideal "Primus inter
pares" to take over zsh maintenance.

--
Louis-David Mitterrand
http://www.aparima.com
mito@aparima.com

New maintainer

[Andrew Main]

Richard Coleman wrote:
>Unless you don't want to do it, you're elected (or drafted, as the
>case may be).

As there appears to be a consensus, I'll consider that official.

Henceforth, the primary archive is

	<URL:ftp://mason.primenet.com.au/pub/zsh/>

(That's Geoff's site.)  Wait until Geoff has got the site up to date
before you start mirroring it.

I'll make a 3.1.3 release shortly; it'll be little change from
3.1.2-zefram4.

-zefram

Re: New maintainer

[Richard Coleman]

> Richard Coleman wrote:
> >Unless you don't want to do it, you're elected (or drafted, as the
> >case may be).
> 
> As there appears to be a consensus, I'll consider that official.
> 
> Henceforth, the primary archive is
> 
> 	<URL:ftp://mason.primenet.com.au/pub/zsh/>
> 
> (That's Geoff's site.)  Wait until Geoff has got the site up to date
> before you start mirroring it.

Excellent.  I'm glad the development pace of zsh is picking up again.

Let me know when to switch my mirror.

rc

Re: zsh-3.1.2-zefram4

[Andrej Borsenkow]

Andrew Main wrote:
> 
> Time for the next unofficial release.  Version 3.1.2-zefram4 exists, and,
> as before, ftp space is hereby requested.  I have made patches relative
> to 3.1.2 and 3.1.2-zefram3.  The full release tar also contains man
> pages and texinfo this time.
> 

Just to let you know, that it builds quite fine. Thanks!

-- 
============================================================
Andrej Borsenkow 		Fax:   +7 (095) 796 99 20
SNI ITS Moscow			Tel:   +7 (095) 796 99 24

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
============================================================

Re: zsh-3.1.2-zefram4

[Peter Stephenson]

just got back...

Andrew Main wrote:
> Peter's KSH_GLOB patch is included, but I backed out a lot of the changes.
> I'd like to have options affect as little as possible, preferably just one
> thing each: KSH_GLOB in this version *only* affects the interpretation
> of parens preceded by the magic characters (in fact, the option is
> only tested on one line of the source).  Parens *not* preceded by the
> magic characters are unaffected by the option.  Glob qualifies are also
> unaffected: that `-', mandatory with KSH_GLOB and forbidden without,
> was just too nasty to use.

The idea was that with the ksh and zsh models being incompatible
anyway, it was asking for trouble trying to mix them.  If you write
correct ksh scripts it won't be a problem, though, so it's fine by me.

> I also backed out the special handling of `(^...)', which changed
> the semantics of `^' in an extremely non-obvious way.  You can use
> `(^(...))' to invert the whole group.

?? It didn't have any semantics before, it didn't work at all inside
parentheses.  I can't remember what I did now (which is a bad sign),
but what's wrong with the meaning `negate the following' that it needs
the extra parentheses?

> This turned up a very old
> bug in the exclusion handling: `(foo~bar)BAZ' is actually treated as
> `fooBAZ~barBAZ', rather than the exclusion being properly localised.

?????? How could it possibly mean anything else?  What are parentheses
supposed to mean, anyway?  (foo|bar)BAZ is fooBAZ|barBAZ and in the
same way (foo~bar)BAZ is fooBAZ~barBAZ.  Or are you just referring to
the way it's evaluated in practice (which is as you say and could
therefore probably be simplified, but that doesn't make it a bug)?

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 50 844536
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy
 

Re: zsh-3.1.2-zefram4

[Andrew Main]

Peter Stephenson wrote:
>The idea was that with the ksh and zsh models being incompatible
>anyway, it was asking for trouble trying to mix them.

If we add an unambigous syntax for qualifiers, it will be possible to
mix them.  Anyway, I simplified the code, as well as the documentation,
quite a bit.

>?? It didn't have any semantics before, it didn't work at all inside
>parentheses.

It works just as well as *~, unless I'm missing a critical test case.
As I mentioned earlier, there's a serios bug in ~ processing.

>but what's wrong with the meaning `negate the following' that it needs
>the extra parentheses?

Precedence.  ^ binds tighter than /, | and so on.  ~ binds looser than
anything except |.  You made a ^ immediately after a ( bind looser
than *anything*, which made "(^foo|bar)" and "((|)^foo|bar)" behave
differently.

>> This turned up a very old
>> bug in the exclusion handling: `(foo~bar)BAZ' is actually treated as
>> `fooBAZ~barBAZ', rather than the exclusion being properly localised.
>
>?????? How could it possibly mean anything else?

It matters when what follows the parentheses has more than one way to
match.  This includes the case of having two negations in the pattern or,
and this is the killer, a negation inside a loop.  Consider "(*~foo)b*"
versus "*b*~foob*" -- "foobb" should match the former ("foob" matches
"(*~foo)") but not the latter.

-zefram

Re: zsh-3.1.2-zefram4

[Peter Stephenson]

Andrew Main wrote:
> Precedence.  ^ binds tighter than /, | and so on.  ~ binds looser than
> anything except |.  You made a ^ immediately after a ( bind looser
> than *anything*, which made "(^foo|bar)" and "((|)^foo|bar)" behave
> differently.

Now I remember what was hiding in `I've forgotten exactly what I did'.

> >`(foo~bar)BAZ' is actually treated as
> >> `fooBAZ~barBAZ', rather than the exclusion being properly localised.
> >?????? How could it possibly mean anything else?
> 
> It matters when what follows the parentheses has more than one way to
> match.  This includes the case of having two negations in the pattern or,
> and this is the killer, a negation inside a loop.  Consider "(*~foo)b*"
> versus "*b*~foob*" -- "foobb" should match the former ("foob" matches
> "(*~foo)") but not the latter.

I've got it now.  Maybe I can even broadly see how to fix it.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 50 844536
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy