Jim has a point, but its not insurmountable, see

Win32::Unicode, Win32::Unicode::Native, Re^5: Is File::Find Unicode-(Conformant|Compliant|Enabled|Capable)?

Path::Class::Unicode, Win32::LongPath

stuffing stuff into global namespace should be possible with monkeypatching, for File::Find , File::Find::Rule.... or for CORE ... someone just has to do it or at minimum file a bug report

and what might be slightly harder is getting overload file test operators to work update they should work Re: Check if unicode directory exists
Bug #60888 for perl5: Win32: support full unicode in filenames (use Wide-system calls)
Bug #75000 for perl5: Unicode symbols damaged in $File::Find::name

so its 90% done, dare I say even 95%, just needs more tests and more bug reports and a little cooperation ...

The new news here is Win32::LongPath, which looks very promising. It was officially released just three months ago, so it wasn't around in 2010 when I asked "Is File::Find Unicode-(Conformant|Compliant|Enabled|Capable)?" It has already been enhanced (just days ago) with an important feature:  support for Cygwin. This new CPAN module addresses the problems that I lamented earlier makes Perl—like other modern scripting languages—not generally and dependably useable for folder and file manipulation in the modern Windows environment, including Unicode, long paths and junction/mount points.

Perl scripts written with Win32::LongPath aren't portable, of course. And as far as I can tell, there's no new File::Find::foo module that exploits the new Windows-specific capabilities afforded by Win32::LongPath. But having the ability to manipulate folders and files on Windows reliably using a comprehensive, well-documented and seemingly well-written CPAN module is a big win for Modern Perl versus other scripting languages.

Jim

The new news ...

Not really more promising than Win32::Unicode , but I welcome the improvements it provides

there's no new File::Find::foo

:D I already provided the code once, all you had to do was release it :) adapt it for Win32::LongPath ... combine with ex::override ... :D

an important feature: support for Cygwin.

LOL!!!! As Cygwin isn't windows, it shouldn't need specific suport from a Win32 module because it just doesn't belong ... all the regular Cygwin should just take care of everything, cause thats cygwin promise ...

Hi

Oh, I wish I were wrong, ww—believe me. And if you can demonstrate with working Perl code examples and accompanying test cases that I'm wrong, no one will be more thrilled than I will be.

Perl's built-in functions don't use the Windows API that they must use if they are to work correctly with Unicode file names, paths that exceed MAX_PATH, and junction points. At least this is how it has always been until the last time I researched the topic. If Perl's limitations with respect to file and folder handling on Windows have been fixed very recently, that's terrific. But I don't think they have or I'd know about it already.

Jim

You can't use chdir to change the current working directory to a Japanese folder name (Unicode) on Windows. It fails.

Running this trivial Perl script…

    #!perl

    use strict;
    use warnings;
    use utf8;
    use autodie qw( chdir );

    binmode STDERR, ':encoding(UTF-8)';

    chdir 'C:/日本/';

…fails with this error message…

    Can't chdir('C:/日本/'): No such file or directory at JapanFolder.pl line 8

File::Find uses chdir.

I'm running Strawberry Perl version 5.16.2.

Jim

UPDATE:

Running this Perl script…

#!perl

use strict;
use warnings;
use utf8;
use autodie qw( chdir );

binmode STDERR, ':encoding(UTF-8)';

chdir 'C:/Doesn’t Work/';
[download]

…fails with this error message…

    Can't chdir('C:/Doesn’t Work/'): No such file or directory at DoesntWork.pl line 8

Had you limited your indictment (first sentence) to working with Japanese characters, I couldn't and wouldn't have argued. But your indictment was global... and that's still wrong.

For working code examples, you don't need a new and redundant post from /me. There are examples enough already on site, if you seek them out.

ww,

It was a lament, not an indictment. And I was careful to mention that other modern scripting languages have the same problems handling Microsoft Windows file systems as Perl does so that no fellow monks would get their tender feelings hurt. I still don't see what part of my earnest post got your hackles up. And I challenge your assertion that it is "outrageously inaccurate." No it's not.

If there was any tacit indictment in my post, it was of Microsoft and its own piece-o'-sh*t modern scripting language, PowerShell. When I wrote "I could be wrong," I meant I could be wrong about my insinuation that PowerShell is just as incapable of handling paths that exceed the infamous MAX_PATH limitation as other scripting languages. Well, I just checked the interwebs. I wasn't wrong. PowerShell is as broken with respect to MAX_PATH as just about everything else Microsoft includes in its expensive commercial operating systems (Windows Explorer, the DIR and COPY commands, etc.).

The point of my second post has nothing to do with Japanese per se. I simply used a Japanese folder name (日本, "Japan" in Japanese) in my example Perl script because that folder happened to be on my system drive, and it's one chdir can't change to. That's all. I could just as easily have illustrated the problem with Ｉ ♡ 🐪 or any folder name including any one of the over 110,000 graphical characters in the Unicode character repertoire that will cause chdir to fail. (N.B. I've updated my earlier post with a new example.)

For working code examples, you don't need a new and redundant post from /me. There are examples enough already on site, if you seek them out.

I realize there are innumerable examples on PerlMonks of Perl scripts that use File::Find and that are intended to be run on Windows. And many of them will work just fine until—BAM!—they don't. I enumerated three verifiable reasons any one of these otherwise "working" code examples will not work. And when it fails, you're screwed, because there are no trivial, portable, sensible solutions to any of the problems. There may be workarounds nowadays as Anonymous Monk has pointed out below, but IMHO, they all suck. And they all mean you can't use File::Find, which is my point.

Jim