Re: [PATCH] t9129: fix UTF-8 locale detection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yann Droneaud venit, vidit, dixit 24.05.2010 19:08:
> Le mardi 18 mai 2010 à 19:08 +0200, Yann Droneaud a écrit :
>> Le mardi 18 mai 2010 à 18:05 +0200, Michael J Gruber a écrit :
>>> Yann Droneaud venit, vidit, dixit 18.05.2010 16:41:
>>>> Since I don't have en_US.utf8, some tests failed:
>>
>>>>
>>>> On my system locale -a reports:
>>>>
>>>>    en_US
>>>>    en_US.ISO-8859-1
>>>>    en_US.UTF-8
>>>>
>>>
>>> locale -a|grep en_US
>>> en_US
>>> en_US.iso88591
>>> en_US.iso885915
>>> en_US.utf8
>>>
>>> This is on Fedora 13, which is not exactly exotic. What is your system?
>>>
>>
> 
> I've checked carefully multiple system and configuration, and found why
> we have some little locale problem here.
> 
> Since glibc 2.3, a file can hold all locales in file "locale-archive"
> instead of having a tons of directory. To store all the locales in this
> file, it uses an index based on a "normalized" codeset, e.g. it converts
> codeset to lowercase, removes dash and minus. 
> So when one ask for the locale list, locale first go through the
> "locale-archive" content and report normalized codeset (utf8)  instead
> of canonical codeset (UTF-8), then it proceed with the legacy locales
> directories, using for them the canonical codeset.
> 
> Until recently, Mandriva Linux doesn't make use of "locale-archive", so
> UTF-8 locales were reported. Version in development uses
> "locale-archive" + legacy locale directories, hence the mix I've
> reported. Other Linux distributions like Fedora and Ubuntu uses only
> "locale-archive" and so, have only "normalized" codeset.
> POSIX doesn't specify the output of locale -a, so it's not really a bug
> to show "normalized" codeset name.
> 
> But all others "POSIX" system I've found report "canonical" codeset,
> e.g. UTF-8 (all but latest cygwin). 
> 
> Here's the bug report:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11629

Thanks a lot for doing the leg work! Is there any way to, say,
set_local(a) and check whether get_locale() == a up to equivalence?

> 
> BTW, I will shortly provided a fix for the testcase, which will handle
> all cases.
> 
> Regards.
> 

Thanks,
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]