On Thu, 25 Dec 2003, Jarkko Hietaniemi wrote: > >> Whoa! It's the other way round here. Nick is using a locale that > >> suits him for other reasons (e.g. getting time and data formats in > >> proper British ways), but why should he be constrained not to use for his > >> filenames whatever he wants? > > > > Then, he should switch to en_GB.UTF-8. > > 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.
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 (some of them far far longer than Linux/glibc has). In the past, all the locales don't come free, but these days, they all come with no extra charge so that it depends on the 'will'/'policy' of the system administrators whether that's available or not. Sure, there are a number of other Unix, old and new, and many old ones don't support UTF-8 locales. I do want to respect people's wish to make UTF-8 files on their file systems even if their version of Unix don't support UTF-8 locales. Otherwise, I wouldn't have come up with a set of 'options' Perl can offer to them. However, people doing so should be aware that there's price to pay. For instance, in their shell, file names would not be shown correctly (i.e. 'ls' would show you garbled characters) They can't use usual set of Unix tools (e.g. 'find' wouldn't work as intended). > > ISO-8859-1, which is why I wrote about mixing up two encodings > > in a single file system _under_ his control. > > I think we are here talking past each other :-) I'm assuming the > not all file systems (like Samba mounts) are not necessarily under > his control, you are assuming they Well, I think that's a different story. He explicitly wrote why he still uses en_GB.ISO-8859-1 (like some old programs breaking under UTF-8 locale). > > Moreover, why would you think that en_GB.UTF-8 locale gives him the > > time and date format NOT suitable for him? > I'm not thinking that. What I think his point is is that plain > en_GB.iso88591 is _enough_ for him to get time/date formats etc > working right, but en_GB.UTF-8 brings in _too much_ (such as some > programs not yet being UTF-8 aware enough, What you had in parentheses was what he wrote in his original message, but what you wrote didn't sound like that to me. At lesat, you took a bad example of time/date format. > or him wanting to use iso8859-1 file names in some directories, but in > some directories not). Yes, that's what I meant. He made a conscious decision to mix up two encodings (read his message. 'If I want Unicode characters in file names, I'd just use UTF-8' or something like that), for which he has to pay whatever price he has to pay. If Perl offers a set of options as I outlined in my previous message, he has to be careful when opening files in different directories. For some directories, he has to use one option while for other directories, he has to use another option. > > You're making a mistake of binding locale and encoding. > > I'm not-- many UNIX vendors do, and I have to with that fact. If Linux > and glibc are doing the Right Thing, that's marvelous, but not all the > world is Linux and glibc. 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 Linux/Glibc did - actually, when Linux/Glibc 1.x has almost __zero__ locale support, UTF-8 or not). Whether they're installed by the system admin. is a different story. 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 fact that it is on Unix is just an artifact of Unix file system > > Not quite. UNIX doesn't care. In traditional UNIX filenames are just > bytes. You're absolutely right. I didn't mean to say 'file system' there as I corrected in my subsequent email. > >> PLEASE, PEOPLE: stop thinking of this in terms of an environment > >> controlled solely by one user. > > > > Before writing that, please read the man page of 'smbmount' and > > 'mount' if Linux system is available to you. They're not environment > > variables. > > Please read my sentence again to see that I had no "variable" in it :-) > Just environment. OK. Sorry for misreading it. Anyway, Perl can't help resolve that problem. It can only offer a set of flexible options (as I listed in 'a few messages ago') that help people solve the problem for themselves. Jungshik [1] SGI Irix seems to lag behind in this area. FreeBSD was slow, but seems to have done a catch-up recently.
