|
in reply to Re: Trouble with File::Find::Rule
in thread Trouble with File::Find::Rule
"...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!
Quis custodiet ipsos custodes. Juvenal, Satires
|
Re^3: Trouble with File::Find::Rule (win32 unicode overload file test operators)
by Anonymous Monk on Dec 14, 2013 at 11:31 UTC
|
| [reply] |
|
|
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
| [reply] |
|
|
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
| [reply] |
|
|
Re^3: Trouble with File::Find::Rule
by Jim (Curate) on Dec 14, 2013 at 04:38 UTC
|
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
| [reply] |
Re^3: Trouble with File::Find::Rule
by Jim (Curate) on Dec 14, 2013 at 05:15 UTC
|
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/';
…fails with this error message…
Can't chdir('C:/Doesn’t Work/'): No such file or directory at DoesntWork.pl line 8
| [reply]
[d/l] |
|
|
| [reply] |
|
|
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
| [reply] |
|
|
