Jungshik Shin <[EMAIL PROTECTED]> writes: >> That will work if there's en_GB.UTF-8 available for him in his >> particular Unixes and assuming using UTF-8 locales won't break other >> things.
Just so we get this clear. A year or so back I - as a Unicode advocate - tried to switch to en_GB.utf8. Within minutes I had two text editors core dump on me because UTF-8 locale means text is UTF-8 and I had opened a file which contained text like £1.42 in good-ole-8859-1. Also perl5.8.0 made that same assumption. > > IIRC, he explicitly mentioned 'Linux' in his message. Besides, >Solaris, Compaq Tru64, AIX, and HP/UX [1] have all supported UTF-8 locales >for a 'long' time And XFree86's handling of compose and or dead keys is far less intuitive than Solaris's ! This is another area that drives me up the wall - X has a "locale" fixation as well - which determines input methods and font-sets (another doomed compromise...). > I never implied that, let alone saying that. (I always prefer to say >Unix in place of Linux. To me, Linux is just one of many Unix) And, >please check out recent commercial Unix. They DO offer UTF-8 locales as I >wrote above (Solaris and AIX had offered solid UTF-8 locales years before Solaris's UTF-8 locale support for en_GB was rather rough. >Anyway, exactly because of the unavailability >of UTF-8 locales for whatever reason, we've been discussing this issue >(to convert Perl's internal Unicode to and from the 'native' encoding >in file I/O.). The ORIGINAL suggestion was that "locale" told you the "native" encoding my point is it doesn't.
