From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7624 invoked from network); 28 Apr 2000 08:03:15 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 Apr 2000 08:03:15 -0000 Received: (qmail 24945 invoked by alias); 28 Apr 2000 08:03:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10993 Received: (qmail 24925 invoked from network); 28 Apr 2000 08:03:03 -0000 Date: Fri, 28 Apr 2000 10:02:39 +0200 (MET DST) Message-Id: <200004280802.KAA20596@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Fri, 28 Apr 2000 01:01:53 +0000 Subject: Re: globbing bug, 3.0.6 Bart Schaefer wrote: > On Apr 27, 3:11pm, Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= wrote: > } Subject: Re: globbing bug, 3.0.6 > } > } Chmouel Boudjnah writes: > } > } > it's the POSIX standard behavior when locale setting is set. > } > } And that's horribly broken IMHO. At least, I think it's broken in > } shell expansion > > I don't want to change this in 3.0.8 unless it's also changing in 3.1.7 > or soon thereafter. What's the verdict on this one, folks? Apparently > bash behaves as zsh does now, but that's not a conclusive argument. Right, and they get their own bug reports about this (for example on gnu.bash.bug). Andrej Borsenkow wrote: > That's general question - how far is compatibility with current Unix > standards important? For better or for worse - current behaviour is one > of the requirements. The problem is (I can go into more details if > needed) Zsh in current form does not and *can* not support full i18n as > specified in docs (this applies to such obscure things as "collate > elements" e.g.). So, the ultimate question is - should we aim at full > POSIX/SUS/... compatibility, at least as an option (that may need > substantial rewrite), or drop it in favour of more "user friendliness". > > Now, with much more powerful regular expressions, I even agree - for > interactive shell plain ASCII collating may be more appropriate - and > scripts should use [[:class:]] form anyway. I'd say we should add an option that turns on POSIX/i18n behaviour and defaults to `off' and documented like `currently this only affects...'. I think its a case where not conforming to standards is the right thing, reducing the number of (probably horrible) surprises. Then we could think about adding the match-flags to turn on/off the behaviour determined by the option for single patterns (I haven't had a look at this match-flag code yet so I don't know how hard to implement this is). And later we can make the option control more things. This also reminds me that the classes in match specs don't care about the locale at all... Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de