...because that would be a pain. Programming via call-backs sucks. Now, if File::Find were to be totally rewritten instead of just being heavilly patched with lots of backward compatability, then there'd probably be an OO or other non-callback interface and I'd be less likely to roll my own replacement (I'd like to do this rewrite when I get more free time).

Plus, File::Find out of the box fails on most systems I work on because the silly "count number of links to determine how many subdirectories" bad hack has remained long past its usefulness. So rolling my own works better than using File::Find. Now, this particular reroll has the common mistake of not detecting symbolic links to directories. I personally don't have any symbolic links to directories to worry about so this is not a problem for me but it would be good to fix this.

One way to fix that would be to use File::Find, but I don't consider that the best way. File::Find's job just isn't tricky enough that you can't roll your own that is even better with a very small bit of work. Now, the symbolic link problem is found in almost all first versions of rewrites of File::Find. And before that, the problem of having to either prepend the directory-path-so-far or chdir() is found because otherwise the rewrite just doesn't work. So watch out for those at least.