From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-10989-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 25965 invoked from network); 28 Apr 2000 05:42:40 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 28 Apr 2000 05:42:40 -0000
Received: (qmail 17084 invoked by alias); 28 Apr 2000 05:42:34 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 10989
Received: (qmail 17076 invoked from network); 28 Apr 2000 05:42:34 -0000
X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer goliath.siemens.de)
From: "Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>
To: "Bart Schaefer" <schaefer@candle.brasslantern.com>,
   <zsh-workers@sunsite.auc.dk>
Subject: RE: globbing bug, 3.0.6
Date: Fri, 28 Apr 2000 09:42:09 +0400
Message-ID: <000001bfb0d4$7e6ed010$21c9ca95@mow.siemens.ru>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <1000428010153.ZM21628@candle.brasslantern.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

> On Apr 27,  3:11pm, Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= wrote:
> } Subject: Re: globbing bug, 3.0.6
> }
> } Chmouel Boudjnah <chmouel@mandrakesoft.com> 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.
>


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.

-andrej