Let's not 'fix' it (not carve it on a stone), but offer a few well-thought-out options. For instance, Perl may offer (not that these are particularly well-thought-out) 'just treat this as a sequence of octets', 'locale', and 'unicode'. 'locale' on Unix means multibyte encoding returned by nl_langinfo(CODESET) or equivalent. On Windows, it's whatever 'A' APIs accept or is returned by ACP_??(). 'unicode' is utf8 on Unix-like OS, BeOS and 'utf-16(le)' on Windows.
Something like that could work, yes.
creating files with UTF-8 names while still using en_GB.ISO-8859-1
locale. Why does Perl have to be held responsible for your intentional act
that is bound to break things?
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?
Well, actually, if your WinXP file system has only characters covered by Windows-1252,
And how would Nick know that, or he could he guarantee that, if the Windows
share is in multiuser use?
PLEASE, PEOPLE: stop thinking of this in terms of an environment controlled
solely by one user.
--
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
