in reply to Re: 'unlink' seems to not work correctly ...
in thread 'unlink' seems to not work correctly ...

... or unlink on the fly, with the no_chdir option. With no_chdir $File::Find::name and $_ are equivalent.
find( {wanted => \&wanted, no_chdir=>1}, @directories ); sub wanted { my $wanted = -l && !-e; push @msgs, $_ and $counter++ if $wanted; return if $param{test} or !$wanted; unlink or croak "Warning: couldn't unlink '$_' :$OS_ERROR\n"; return; }
Update Refactored wanted function.

print+qq(\L@{[ref\&@]}@{['@'x7^'!#2/"!4']});

Replies are listed 'Best First'.
Re^3: 'unlink' seems to not work correctly ...
by merlyn (Sage) on Dec 03, 2009 at 05:01 UTC
    That is, if you're willing to pay the performance penalty for no_chdir, and in this case, it seemed unwarranted, since the workaround was so easy.

    -- Randal L. Schwartz, Perl hacker

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

      performance penalty?
        Yes, no_chdir means that find needs to keep readdirring and stating longer and longer paths, repeatedly traversing the parent directories. Real find, like the default File::Find, uses chdir to ensure that the readdir and stats traverse the minimal number of inodes.

        -- Randal L. Schwartz, Perl hacker

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.