Florian Weimer <[EMAIL PROTECTED]> writes:
> * Paolo Bonzini:
>
>> and these do not include regex character ranges. LC_COLLATE would only
>> be used for sorting and for string comparisons.
>
> You end up with similar behavior if you read the POSIX spec carefully,
* Paolo Bonzini:
> and these do not include regex character ranges. LC_COLLATE would only
> be used for sorting and for string comparisons.
You end up with similar behavior if you read the POSIX spec carefully,
IIRC. LC_COLLATE should not affect character ranges.
I can only guess the outcry if Perl started obeying LC_COLLATE.
What do you mean, "started"? It's been doing that for years now.
By default, Perl ignores the current locale. The "use locale" pragma
tells Perl to use the current locale for some operations:
and t
On 2005-02-17 20:29:00 +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Paolo Bonzini) wrote on 17.02.05 in <[EMAIL PROTECTED]>:
> > I can only guess the outcry if Perl started obeying LC_COLLATE.
>
> What do you mean, "started"? It's been doing that for
[EMAIL PROTECTED] (Paolo Bonzini) wrote on 17.02.05 in <[EMAIL PROTECTED]>:
> > The sort alghorithm has nothing to do with ls, but with your selection of
> > LC_COLLATE. But then, BSD (at least the variant used in MacOSX) is way
> > behind current l10n standards.
>
&
The sort alghorithm has nothing to do with ls, but with your selection of
LC_COLLATE. But then, BSD (at least the variant used in MacOSX) is way
behind current l10n standards.
At least they do not break s/[A-Z]// which on "well-internationalized"
OSes is case-insensitive with most loc
