It'll be great, I'll use it often, but there is a problem with files beginning with a '.'. They are identified as being type('d'). Indeed it seems that all type('f') files are reported as type('d') after the first dot file is encountered.

YuckFoo

Ahh, thanks for finding that. It's a misunderstanding on my part about how File::Find works. I was presuming that _ was always correct, and apparently, it's not. I'll have File::Finder do a single lstat($_) before calling the step chain then. That'll cure it, and you can simulate that right now with:

my $steps = File::Finder->eval(sub{lstat})-> ...;
[download]

and you should see proper results then.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

---

update: The fix for your bug is in version 0.02, along with the ->comma step to emulate GNU-find's comma operator. Now blasting to CPAN mirrors near you.

And now you've joined the huge throng of those who have had their scripts made slower by this File::Find "optimization".¹

Instead, set $File::Find::dont_use_nlink = 1 and go back to using _ and your module will no longer produce two calls to stat/lstat per file much of the time.

You could make sensible use of this optimization in your module since you can tell whether the files are being selected only based on their names. But File::Find should really only use this optimization in the few cases when it is useful, based on the user asking for that optimization.

                - tye

¹ I don't much mind the speed penalty of often doing two stat/lstat calls per file, but I do mind it being caused by something claiming to be an optimization, especially when that optimization is responsible for breaking so much code, including the first version of a module sent to CPAN by merlyn (if merlyn, long advocate of File::Find, got caught by this in published code, surely many, many other people have lost time due this supposed time-saver).

How about adding "mindepth" & "maxdepth" features (that control the depth of directory to start in and not exceeding a certain depth respectively.)?

It was a surprise to me that File::Find (my version is 1.05) lacked it on its own. It will be swell if your modules introduces above two much needed features.

Of course, you could get those already with:

File::Finder->eval(sub { $File::Find::name =~ tr././. > 3 })-> ...;
[download]

But I suspect over time that I'll add every flag that GNUfind has. I just wanted the initial release to be fairly complete with respect to find2perl, which it is.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

  require File::Finder;
  require File::Find::Rule;
  require File::Find::Rule::ImageSize;
  my $ffr = File::Find::Rule->file->image_x('>1000')->image_y('>1000')
+;
  my @big_friends = File::Finder->ffr($ffr)
    ->in("/Users/merlyn/Pictures/Sorted/Friends");
[download]

Awesome! I've always liked that filter-chaining style (having used it for other things on a few occasions), and this seems the perfect fit for it. File::Find, while incredibly powerful, has always been a little awkward. I'm using this from now on. Good work!

I'm confused. On what occasion would this module be a better choice than FFR? I did look at the PODs, but aside from the nesting syntax (->left / ->right vs ->or( ... ) and friends) there doesn't seem to be anything fundamentally different from FFR's approach.

I'm somewhat skeptical right now, but would honestly be interested if you can "sell" me this module. (Maybe this advertisement should also go into your POD; I'm certainly not the only one with these questions.)

Nifty!