in reply to Is File::Find Unicode-(Conformant|Compliant|Enabled|Capable)?

File::Find uses perl's built-in functions, and no, they don't work with unicode on win32 anymore.

It should be possible to override opendir/readdir/open to use Win32::Unicode

  • Comment on Re: Is File::Find Unicode-(Conformant|Compliant|Enabled|Capable)?

Replies are listed 'Best First'.
Re^2: Is File::Find Unicode-(Conformant|Compliant|Enabled|Capable)?
by Jim (Curate) on Jun 07, 2010 at 04:20 UTC
    Too bad. A lot of stuff in the Perl literature says "use File::Find", but you can't use it if you have a file name that isn't in English or another Western European language, or happens to have an EM DASH in it. So there's no easy way to use Perl for simple recursive file handling stuff on Microsoft Windows and NTFS.
      So there's no easy way to use Perl for simple recursive file handling stuff on Microsoft Windows and NTFS.

      Sure there is. File::Find will return short names (like 0CA1~1.TXT) and you can then use Win32::GetLongPathName to get the unicode version ( like ћевап.txt )

        That fails both the easiness test and the simplicity test. It's also not portable programming.

        Is File::Find magically Unicode-capable on operating systems besides Microsoft Windows?

        Modern Perl really ought to be able to do file handling stuff well (it does), and it ought to be able to handle Unicode well (it does now), and it ought to be able to do both at once well (it doesn't - not on Windows).

        Does anyone here know: Is File::Find going to be enhanced soon to handle Unicode directory and file names? It's a core module.