Re: Regarding strcoll() in glibc 2.2

[Andreas Schwab]

"Dmitry Yu. Bolkhovityanov" <address@hidden> writes:

|>     Hi!
|> 
|>     There's a problem (in fact, two problems) with strcoll() in glibc 2.2.
|> 
|>     First, strcoll() in many locales (at least en_US, de_DE, ru_RU, uk_UA,
|> the only exception is "C") ignores non-alphanumeric characters, e.g. ".".
|> This completely breaks directory listings -- see either "ls" or "mc"
|> (RedHat 7.1):

Then don't use that locale.

|>     As I understand, this was done in order to follow national traditions --
|> most vocabularies are "case-insensitive".  But there is also a need to do
|> case-sensitive *and* locale-sensitive comparison.  Are there any plans to
|> implement something like "strnocasecoll()/strnocasexfrm()"?  Or should
|> Austin group be pushed in this direction first?

Define your own locale that does what you want.

|> (BTW, '(libc.info.gz)Collation Functions' says:
|> 
|>     The `strcoll' function is similar to `strcmp' but uses the collating
|>     sequence of the current locale for collation.
|> 
|> -- in my understanding, this implies that strcoll() should distinguish upper-
|> and lowercase (as strcmp() does.)

What about title case?  General collation sequences are much more
complicated than the ASCII collation sequence so that the distinction
between case sensitive and case insensitive cannot be meaningfully defined
in this context.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
address@hidden
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5