File::Find broken with pre/postprocess

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

Hi, this is with perl 5.8.7 and 5.8.8 on Linux. This code works as expected:

find({wanted => \&wanted,},'/tmp');

sub wanted {
 print "$File::Find::name\n";
}
[download]

this works not as expected:

find({wanted => \&wanted,
      preprocess => \&preprocess,
      postprocess => \&postprocess},'/tmp');

# wanted see above

sub preprocess {
 print "pre\n";
}

sub postprocess {
 print "post\n";
}
[download]

edit: and that is because I have not read the complete docs for "preprocess", but stopped after the first sentence. Oh my. See merlyns answer for a solution. if preprocess looks like this:
sub preprocess { my @dir = @_; print "pre\n"; return @dir; }
[download]
the code does "the right thing".

(there is no directory 1 in /tmp, and there are thousands of files) While the first code example willingly traverses my /tmp directory, the second one gives me a rather weird output:

/tmp
pre
/tmp/1
post
[download]

According to the docs, I would expect to have preprocess and postprocess being called befor resp. after processing every directory, but the traversal should be not influenced by this. What am I doing wrong here? Or is it a bug?

Bye
PetaMem All Perl: MT, NLP, NLU

Comment on File::Find broken with pre/postprocess Select or Download Code

Replies are listed 'Best First'.
Re: File::Find broken with pre/postprocess by merlyn (Sage) on May 09, 2006 at 17:53 UTC
You've misunderstood "preprocess". From the docs: "preprocess" The value should be a code reference. This code reference is + used to preprocess the current directory. The name of the currently +pro- cessed directory is in $File::Find::dir. Your preprocessing +function is called after "readdir()", but before the loop that calls +the "wanted()" function. It is called with a list of strings (ac +tually file/directory names) and is expected to return a list of st +rings. The code can be used to sort the file/directory names alphab +eti- cally, numerically, or to filter out directory entries based + on their name alone. When follow or follow_fast are in effect, +"prepro- cess" is a no-op. [download] It's doing what you ask. Your preprocess is returning the single value "1" (the result of the print). -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply] [d/l]
Re: File::Find broken with pre/postprocess by blazar (Canon) on May 10, 2006 at 10:50 UTC
That's because `preprocess` is for preprocessing the list of a directory entries. Although merlyn already explained that, I'm stressing it because I do use `preprocess` e.g. to do `preprocess => sub { sort @_ },` [download]	[reply] [d/l] [select]