* Tom Christiansen ([EMAIL PROTECTED]) [081126 23:55]:
> On "Wed, 26 Nov 2008 11:18:01 PST."--or, for backwards compatibility,
> at 7:18:01 p.m. hora Romae on a.d. VI Kal. Dec. MMDCCLXI AUC,
> Larry Wall <[EMAIL PROTECTED]> wrote:
>
> SUMMARY: I've been looking into this sort of thing lately (see p5p),
> and there may not even *be* **a** "right" answer. The reasons
> why take us into an area we've traditionally avoided.
What a long message...
> Mark>> We should focus on OS abstraction.
> Mark>> [...] the design of this needs to be free from historical mistakes.
> ... It cannot be
> done in an automated fashion, since you can't know a filesystem that knew
> *locale* each filename was created under, and without that, you have to
> guess--almost always wrongly.
Exactly. This is an historical mistake, understandable to have at least
a path of growth from the current system open() interface. Only users
which have the same locale can see the names the same. If you change
your locale your filenames break! Say you change from cyrillic into
English.
In my suggestion, the programmer (who is ofter local on the system) can
at least say what the locale was when the filenames where created. On
some OS, that OS can tell you. What I would like is an object model
which does allow us at least to abstract these problems away... whether
it can be resolved automatically or only with help is for later.
> There is ABSOLUTELY NO WAY I've found to tell whether these utf-8
> string should test equal, and when, nor how to order them, without
> knowing the locale:
>
> "RESUME",
> "Resume"
> "resume"
> "Resum\x{e9}"
> "r\x{E9}sum\x{E9}"
> "r\x{E9}sume\x{301}"
> "Re\x{301}sume\x{301}"
This is done by the locale of the user of the script, as usual for
ls(1). So, I do not see your problem here.
I don't mind if problems with unicode are not solved or solvable.
Could be discuss about a buildin File::Spec/Path::Class? And we
allow us the same limitations as these have, for the moment.
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
