File::Find giving wierdness

bturns

TS 5.5.2
Solaris 8

I am calling the following sub routine from a perl script. When I call this subroutine more than once with in the script I get no results the 2nd - nth time. Does anyone know if there are any problems with calling the File::Find module more than once with in a script?

sub get_dcr_ea_values{

my ($directory, $eaVal, $hashRef) = @_;
my $return = "0";
my @fileArray;

sub fileProcess {
my $filePath = $File::Find::name;
push(@fileArray, $filePath);
return;
}

find(\&fileProcess, $directory);

foreach my $full_file (@fileArray) {
do some stuff
}

return $return;

}

Adam Stoller

If you enable warnings I think you'll get a big of a clue here. If you enable diagnostics, you'll get even more information. I took your routine and modified it slightly to run it on my local machine (without TeamSite).

Although I ran this on my local machine with Perl 5.8.1 - you'll get similar results if you run it with 5.005_03 on your machine.

---

#!/usr/bin/perl
use strict;
use warnings; # For 5.005_03 add '-w' to #! line and remove this
use File::Find;
use diagnostics;

get_dcr_ea_values("/tmp");
print "=" x 70, "\n";
get_dcr_ea_values("/tmp");

sub get_dcr_ea_values{
my $directory = shift;
my @fileArray;

sub fileProcess {
my $filePath = $File::Find::name;
push(@fileArray, $filePath);
return;
}

find(\&fileProcess, $directory);

print "" . @fileArray . "\n";
}If you run this you'll get something like this:

---

Variable "@fileArray" will not stay shared at ./foo.ipl line 17 (#1)
(W closure) An inner (nested) named subroutine is referencing a
lexical variable defined in an outer subroutine.

When the inner subroutine is called, it will probably see the value of
the outer subroutine's variable as it was before and during the *first*
call to the outer subroutine; in this case, after the first call to the
outer subroutine is complete, the inner and outer subroutines will no
longer share a common value for the variable. In other words, the
variable will no longer be shared.

Furthermore, if the outer subroutine is anonymous and references a
lexical variable outside itself, then the outer and inner subroutines
will never share the given variable.

This problem can usually be solved by making the inner subroutine
anonymous, using the sub {} syntax. When inner anonymous subs that
reference variables in outer subroutines are called or referenced, they
are automatically rebound to the current values of such variables.

1
======================================================================
0

---

If you move the declaration of @fileArray up and make it scoped globally to the file and change the line where you declare it now to look like: ...
@fileArray = ();
...The warning goes away and the results appear to be correct.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com