3

In Windows there is a common problem: the filenames should be converted to local codepage, before they are passed to open(). Of course, there is a possibility to use Win32::API for that, but I don't want my script to be platform-dependent. At the moment I have to write something like:

open IN, "<", encode("cp1251", $filename) or die $!;

but is there any library, that hides these details? I think the local codepage can be automatically detected, so I just want to pass unicode filename and forget about the details. Why is it still not in the box?

Community
  • 1
  • 1
dma_k
  • 10,431
  • 16
  • 76
  • 128
  • Found relative post: http://stackoverflow.com/questions/1721807/how-do-i-create-then-use-long-windows-paths-from-perl – dma_k May 09 '10 at 00:11

1 Answers1

5

It used to just work until 5.8.1, then Jarkko took it out, and broke the -C switch in an gratutious incompatible change on top. This makes Windows a second class citizen and annoys me until today, because any other dynamic language does not have this ridiculous defect. Perhaps now is a good time that we could hear a justification for this change for the worse.

Anyway, you want PerlIO::fse, but it's not a perfect solution, as you will soon discover on your own.

daxim
  • 39,270
  • 4
  • 65
  • 132
  • Nice answer, thanks a lot. Maybe you can give a link to `-C` (enables given Unicode features) switch discussion? What was the reason to break compatibility? – dma_k May 09 '10 at 14:38
  • I've got your point: the behaviour of `-C` has been dramatically changed and now does not control the wide character API setting, so it cannot be used as a solution for a problem anymore (I've found the complete list of current options here http://perldoc.perl.org/perlrun.html#*-C-[_number/list_]*). Do you happen to know any discussion thread (say: critics) about new policy for `-C` switch? – dma_k May 10 '10 at 17:57
  • http://markmail.org/message/ijklg7cnr6xv6bgu http://markmail.org/message/fjiiyvbuck75v5sa – daxim May 11 '10 at 07:11