Help with $File:Find

[roperl]

I'm using the File::Find module to find files that matches a certain type

Occasionally I get this in my STDERR log : "Use of uninitialized value $_ in pattern match (m//)" when using the code below

     find( { wanted => \&get_files, preprocess => \&nodirs }, "$DIR" )
+;

     sub nodirs {
         grep !-d, @_;
     }

     sub get_files {

         my @array;
         push @array, $File::Find::name if ( (/^.*\.($TYPES)$/i) );
     }

How can I check if $_ is initalized before matching the pattern?

[huck]

push @array, $File::Find::name if (defined $_ &&  (/^.*\.($TYPES)$/i) 
+);

[tinita]

It would be interesting to find out, though, when $_ an actually be undef. I can't find anything about that in the File::Find documentation. I only see a case where $File::Find::fullname is documented to be undef.

[roperl]

Ok I was thinking that but I wasn't sure if needed to check if $File::Find::name was defined.
So I can write it as:


push @array, $File::Find::name if ( ($_) &&  (/^.*\.($TYPES)$/i) );


that is they syntax I've been using to check for defined without actually using "defined"

[Marshall]

Your code for sub get_files looks a bit odd to me. The reason being that @array is not accessible after the find() operation. Normally you have to declare @array at the same scope as find(). Also, there actually isn't a need for sub nodirs{}. You could just have a next if (-d $File::Find::name); in the get_files{} sub. I am a bit flummoxed as to how $_ could wind up being undef because this is a file name like readdir() would return. Show us what $TYPES is? There could be something odd in the regex, often \Q$TYPES\E is needed.

A a debug thought, I would add: print "looking at $_\n"; in your get_files routine. I would be astounded if that specific line shows an attempt to print an undef value error.

[roperl]

There is more to my get_files sub that does a foreach (@array) and then checks the files for certain criteria.
I left out that section for clarity here.
My $TYPES is defined like so:

my $TYPES = 'txt|gz|zip';


The only thing I can think of is that the find could be finding a number of files in a directory first and then filling in the names and so if the file is gone in the middle of the operation $File::Find::name will fail because the file name isn't defined.

[Marshall]

I and other Monks aren't sure what is happening here. Let's get more info:

Add the line $|=1; at the top of your program. This will unbuffer STDOUT. Then put in some print statements as I suggested earlier. Then when the error happens, we will have an idea of what the program was doing. By default, STDOUT is buffered meaning that it only prints when its line buffer is full. STDERR is non-buffered by default meaning that it's error lines print right away. When you un-buffer STDOUT, the time sequence of the normal prints and error prints are preserved. The line right before the error will show what the program was doing right before the error occured.

Update: you said "There is more to my get_files sub that does a foreach (@array) and then checks the files for certain criteria. I left out that section for clarity here." It could very well be that your simplification obscures the actual problem. Can you reproduce the problem with your simplified code?

[beech]

Hi,

Use File::Find::Rule::Procedural

Write something like

use File::Find::Rule 'find';
my @files = find( file => name => qr/\.($TYPES)$/i )->in( $DIR );