in reply to Problem with -d inside find sub

I think your confusion comes from ignoring this part of the File::Find documentation:

Additionally, for each directory found, it will "chdir()" into that directory and continue the search, invoking the &wanted function on each file or subdirectory in the directory.

So the path in $f is always relative (because static is a relative path), and the calls to chdir that File::Find performs take care that the file tests never find the file that you think should be found.

Either pass the no_chdir => 1 option to &find, or do the file checks on $_ instead of $File::Find::name.

Perl 6 - the future is here, just unevenly distributed

Replies are listed 'Best First'.
Re^2: Problem with -d inside find sub
by randian (Acolyte) on Apr 27, 2012 at 01:01 UTC
    Duh! Thanks.
[reply]
      but remember, no_chdir slows things down considerably
[reply]
        Why does no_chdir slow things down?
[reply]
Re^2: Problem with -d inside find sub
by randian (Acolyte) on Apr 27, 2012 at 09:34 UTC
    Found another interesting issue. Run the code below as is. It works fine. Then uncomment the given/when blocks and run it again. When I do that I see the same name printed out over and over instead of the correct file names. 
    use strict;
use warnings;
use 5.010;

use File::Find qw/find/;

my $dir = 'dirname';

my @all;

#given ($dir) {
    #when (-d) {
        my %options = (
            wanted => sub {
                say;
            },
            no_chdir => 1,
        );
        find \%options, $dir;
    #}
#}

local $" = "\n";
say "@all";

    [download]
[reply]
[d/l]
      Two solutions:
      1. Declare the %options outside of the given-when blocks.
      2. say $File::Find::name;
[reply]
[d/l]
[select]
        Weird. I wonder why given/when blocks would handle hash lexicals differently than any other kind of block. Definitely seems like a perl bug.
[reply]

In Section Seekers of Perl Wisdom