Create an empty array, then change the contents of the “wanted” subroutine (the anonymous sub) to push the required files onto the array rather than printing them:

#! perl
use strict;
use warnings;
use File::Find;

my @filtered = (...);
my @files;

find(sub { push @files, $File::Find::name if /\.lef$/ } , @filtered); 

# access @files as needed
[download]

Hope that helps,

thanks Athanasius! you save my day

finally , I am able to assign after so many tries :( . i tried push earlier but it didn't work due to various syntax errors.

find ( sub { print  $File::Find::name ,  "\n" if /\.lef$/  } , @filter
+ed);
print join("\n" , @files, "\n");
[download]

There are many many ways to do that trick. One way is to wrap a call to the callback sub and pass a "return" parameter into it:

#!/usr/bin/perl
use warnings;
use strict;
use File::Find;

my @filtered = 'aaa/';
my @results;

find(sub {callback(\@results)}, @filtered);

print "$_\n" for @results;


sub callback {
    my ($results) = @_;
    
    push @$results, $File::Find::name if /\.pl$/;
}
[download]

There are variations on the theme that involve using global variables in various ways or variations that work well with object oriented techniques. Avoiding globals is good for maintainable code and the object oriented variations tend to be trivial changes to the code shown.

Why so complicated? (a sub in a sub)

use strict;
use warnings;

use File::Find;

my @result;
find (sub {
    m/\.pl$/ and push @result, $File::Find::name;
    }, "aaa");
[download]


Enjoy, Have FUN! H.Merijn

Because I hate javaScript nested functions!

Actually, for a trivial sub the inline sub is fine. For something that does a little more work the inline call to the callback sub allows parameters to be passed and much more maintainable code.

Premature optimization is the root of all job security

I agree that global variables are almost always undesirable. I do not think that accessing the same variable by reference rather than by name justifies the added complexity. Perhaps it would be better to restrict the scope of the 'global' variable by placing it in a subroutine along with the call to find.
Bill

Those sort of decision depend a great deal on context. The OP is almost context free so showing the "complex" version provides a robust scale-able pattern and a good starting point for further discussion.

It's not clear to me how localizing the global (to the callback) variable avoids the need to pass the variable to the callback if the callback is out of line. Obviously if the callback is inline there is no need to pass in the variable and then it really doesn't matter what the scope of the variable is.

Premature optimization is the root of all job security

use File::Find::Rule qw/ rule /;
my @files = rule( file => name => qr/\.lef$/ )->in( @dirs );
[download]