Re: Bugs in File::Find on Windows

One possibility that should work is to turn on no_chdir for File::Find... but in fact, this is broken on Windows too! It fails to recurse at all.

The following works fine for me:

use strict;
use warnings;
use File::Find;

find( {no_chdir => 1, wanted => sub { local($\)=$/; print if -d} }, 'E
+:/windows');
[download]

i. e. prints all the name (paths) of all the subdirectories below and including my E:/Windows

In fact, I never liked the idea of changing the current directory inside my programs, so I always used File::Find with no_chdir and have never experienced problems with it.

Comment on Re: Bugs in File::Find on Windows Select or Download Code

Replies are listed 'Best First'.
Re^2: Bugs in File::Find on Windows by jdporter (Paladin) on Feb 19, 2007 at 14:48 UTC
You haven't reproduced my failure scenario, which requires that the target directory be a drive letter with no other path info. Try this: `cd /d e:\windows cd /d c:\ find({ no_chdir => 1, wanted => sub { print if -d } }, 'E:' );` [download] But I've discovered more about this bug. Try this: `cd /d c:\ mkdir test\windows\foo cd test cd /d e:\ perl -MFile::Find -e "$\=$/; find( sub { print if -d }, 'c:' );"` [download] Output is just as you'd expect: `. windows foo` [download] But if you run `perl -MFile::Find -e "$\=$/; find({ no_chdir => 1, wanted => sub { pri +nt if -d } }, 'c:' );"` [download] you get unexpected (erroneous) output: `. . . c:/windows/$hf_mig$/KB898461/update c:/windows/$MSI31Uninstall_KB893803$ c:/windows/$MSI31Uninstall_KB893803$/spuninst c:/windows/$NtServicePackUninstall$ c:/windows/$NtServicePackUninstall$/spuninst c:/windows/$NtUninstallKB816486$ . . . c:/windows/ADDINS c:/windows/AppPatch c:/windows/assembly c:/windows/assembly/GAC_32 c:/windows/assembly/GAC_32/CustomMarshalers c:/windows/assembly/GAC_32/CustomMarshalers/2.0.0.0__b03f5f7f11d50a3a . . .` [download] In other words, if it finds a subdirectory of the target directory named X, it searches under C:\X, even if the target directory is not C:\. It's definitely a bug. A word spoken in Mind will reach its own level, in the objective world, by its own weight	[reply] [d/l] [select]
Re^3: Bugs in File::Find on Windows by pKai (Priest) on Feb 19, 2007 at 19:30 UTC
I see now. I took your "...broken on Windows too! It fails to recurse at all." as an absolute verdict on `no_chdir`, rather than as an outcome in your special situation, depending on the current directories on both drives and even the top-level directories of C:. Tricky stuff.	[reply] [d/l]


Do you know where your variables are?
	PerlMonks