http://qs1969.pair.com?node_id=810662

chexmix has asked for the wisdom of the Perl Monks concerning the following question:

O Monks,

Emphasis should be on the "seems to" in the topic ...

Every once in a while -- er, more often than I care to admit, really -- I find myself staring at code that I vow USED to work and suddenly DOESN'T any more, despite the fact (?) that I can't remember having done anything to it.

Here is an example: I have written a script to uncover dead symbolic links, delete them and report on what was deleted. If run in '--test' mode, it simply reports out the presence of the dead links.

The problem is that the script is finding and reporting out the dead links I am creating for my testing, but when I run the script "for real", e.g. to have it delete the links, it emails a report that claims the links were deleted ... and when I go to the supposedly cleaned directory, the dead links are still there.

Here is the code that handles the deletion:

find( \&wanted, @directories ); sub wanted { -l && !-e && ( ( push @msgs, "$File::Find::name" ) && $counter++ ); ( -l && !-e && unlink "$File::Find::name" || croak "Warning: couldn't unlink $File::Find::name:$OS_ERROR\n" +) unless $param{test}; return; }

... When I run the script from the CL, I don't get an error output saying the links can't be deleted, either. Nothing. Everything works fine except the links ... aren't being deleted.

If anyone has any insight into this, I'd appreciate it. Not that it matters, but I swear this used to work ...

Thanks,

GB

Replies are listed 'Best First'.
Re: 'unlink' seems to not work correctly ...
by gmargo (Hermit) on Dec 02, 2009 at 20:17 UTC

    You have a precedence problem with the unlink. Since unlink is a list operator and not a unamed unary operator, the statement

    ( -l && !-e && unlink "$File::Find::name" || croak "Warning: couldn't unlink $File::Find::name:$OS_ERROR\n" +) unless $param{test};

    actually binds as

    ( -l && !-e && unlink ("$File::Find::name" || croak "Warning: couldn't unlink $File::Find::name:$OS_ERROR\n") + ) unless $param{test};

    which is certainly not as you intended. I suggest you add explicit parentheses to the unlink. You could also change the "||" to "or" but parentheses are always clearer. Like this:

    ( -l && !-e && unlink("$File::Find::name") || croak "Warning: couldn't unlink $File::Find::name:$OS_ERROR\n" +) unless $param{test};
Re: 'unlink' seems to not work correctly ...
by merlyn (Sage) on Dec 02, 2009 at 19:55 UTC
    Your $File::Find::name contains the whole path, but you are likely chdir'ed into the lowest directory during wanted.

    Either unlink $_ within wanted, or wait until wanted is finished and do it all afterward.

    -- 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.

      ... 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']});
        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.