Actually, no I know there are modules/methods that should be used to clean up paths, but it isn't something I have really done as of yet. Exactly what should I be doing?? If you dont mind explaining the whats and whys. Should I be using the canonpath or catfile methods? The manpage says that canonpath does a logical cleanup.. What exactly is that?

I meant, to be absoultely sure about portability, instead of "$dir/$_" one {c,sh}ould use File::Spec's catfile method.

Thanks for your variation. The string comparison would be a better way to go in this situation. Regexes are probably my weakest point with perl, so this is something I have been overusing trying to get used to. The performace hit is good mention. thanks.

Regexen rock! However people often tends to overuse them. Including me, sometimes...

I am almost possitive I have seen mention here or in one of the perl books that you should close filehandles and check for error code ( oops ) just as you do with calls to open... And that it is common mistake that people only check for success on open and not the close.

Well, indeed some people recommend to check the return value of close calls too. To me, that's a bit of an exaggeration. As far as regular files are concerned, that is. (More info about this topic below.)

Well, I can't comment on your whole logic. But rather than having $recurse flag I would try to arrange things in other to have at some point a recursion for @dirs (this hypothetical @dirs not being yours), so that when @dirs is empty simply no recursion happens...

The point of the flag is if you do not want recursion at all, the main $recursion flag can be set to 0 and then it will only return images in the top directory.

So far, so fine. I hadn't thought of that. As I said I've not practiced much the sport of reimplementing File::Find. If it were me I would just use the latter if I wanted recursion (and I could also control the depth of the search if needed) and perhaps a simple glob if I didn't.

Now, glob is for some reason I ignore an oft underused and underestimated function. I frequently find myself advocating its use when I see people explicitly using opendir, readdir and grepping on filenames whereas it would take care of doing all of this for them. Granted: behind the curtain it does use a module, but I hope that doesn't overwhelmingly bother you:

$ perl -MO=Deparse -e '<*>'
use File::Glob ();
glob('*');
-e syntax OK
[download]

    foreach $file (@files) {
        open FH, $file or
            die "Error opening $file: $!\n";
[download]

Ditto as above wrt using lexical filehandles. Also, some disagree, but I always recommend using the three args form of open.

I obviously do not understand your reference to lexical filehandles. Are you sugesting I dont check for error? HuH?? I must be having a brain fart because I am not following you.

I meant something like this:

for my $file (@files) {
    open my $fh, '<', $file or
      die "Error opening `$file': $!\n";
    # do something with $fh
    # ...
    # no need for an explit close() 
}
[download]

I have heard mention that calling the three arg method is better, but have not heard good reasoning for this.

Well, for one thing it clearly stresses at a glance what the file is being opened for. And as such is IMHO more elegant and terse. Also, consider this oversimplified example:

$ cat foo.pl
#!/usr/bin/perl

use strict;
use warnings;

my $file=shift;
open my $fh, $file or die $!;

print "The contents of `$file' are:\n", <$fh>;

__END__

$ ./foo.pl aaa 
The contents of `aaa' are:
asdfdaf
sfdfdd
sffgsdd

$ ./foo.pl '|echo "Gotcha!">foo.pl'
The contents of `|echo "Gotcha!">foo.pl' are:

$ cat foo.pl
Gotcha!
[download]

This is a security hole that has actually been exploited e.g. in poorly written CGI scripts. Not to say that people could not write secure programs with the two args form of open nor that the three args one is bullet proof. Indeed in any situation where it may matter, one must validate his imput to protect from malicious users, but the latter provided a first good protection for a small expense.

Ouch! It doesn't mach my PNG images, not to say a few other tenths of popular formats, not to mention more exotic ones... Seriously this may be a good reason for using a dedicated module...

Here....

      elsif ( data =~ /^\x89PNG\x0d\x0a\x1a\x0a/) {
         type = 'PNG';
      }
[download]

Now it checks your pngs... Happy? :)

It doesn't check my TIFF and PNM images!! :-)

That is definetly cleaner. Perls flexibility of giving different values depending on how it is called can sometimes be confusing. So I have developed a defense mechanism that whenever any errors are encountered or I am unsure on precedence order then add paranthesis or force return mode scalar. Although not necessary, I think if not tooo overboard it isnt bad habit. What do you think given that reasoning?

I think that a concise code is generally more clear to read and understand. Well written perl code tends to be concise. Of course I'm not talking about extreme conciseness like the one people tries to achieve e.g. when golfing, as that brings into obfuscation instead. I'm talking about the Right(TM) amount conciseness...