* Leon Timmermans ([EMAIL PROTECTED]) [081126 15:43]:
> On Wed, Nov 26, 2008 at 12:40 PM, Mark Overmeer <[EMAIL PROTECTED]> wrote:
> That is a task for the operating system, not Perl. You're trying to
> solve the problem at the wrong end here IMHO.
In my (and your) case, the operating system is not helping at all
and there is no chance in having that changed. So...
My remark was just one example, and I can give many more, where I
would like to see more abstraction in the OS interface to avoid the
need for each user to re-invent the wheel of interoperability.
> > For instance, you do not know in which character-set the filename is;
> > that is file-system dependent. So, we treat filenames as raw bytes.
>
> On native file-system types (like ext3fs), character-set is not
> file-system dependent but non-existent. It really is raw bytes.
Not on the presentation level to the user. This makes it even more
horrifying. It depends on the setting of an environment variable
of the actual user how the bytes of the filename are interpreted.
On the OS filesystem implementation you are probably correct (in
the UNIX/Linux case), but programs are used for end-user results.
> > This does cause dangers (a UTF-8 codepoint in the filename with
> > a \x2F ('/') byte in it, for instance)
> A \x2F always means a '/'. UTF-8 was designed to be backwards
> compatible like that.
Yes, you are right on this. ASCII does not suffer from UTF-8, so my
example was flawed. The second 128 does cause problems. How can glob()
sort filenames, for instance? UTF-16 names should not enter the Perl
program unless you are aware of it, because those can hurt badly.
Please comment on the big picture in the debate: there are all kinds
of OS dependent things I really would like to see hidden in a (large)
abstraction layer to simplify the development of portable scripts.
I don't say I know all the answers, but I do feel a lot of pain in
each module for CPAN the same thing again.
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
