"...you can't use File::Find and friends on Microsoft Windows.

Outrageously inaccurate. Works fine on WinXP and up (and IIRC, should work fine even on W98).

Likewise "isn't useful" and "no modern scripting language is...."

Yes, you "could be" and, in fact, are wrong; way wrong!

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

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.