Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re^3: Find images regardless of filetype extension.

by blazar (Canon)
on Aug 04, 2005 at 11:02 UTC ( #480764=note: print w/replies, xml ) Need Help??

in reply to Re^2: Find images regardless of filetype extension.
in thread Find images regardless of filetype extension.

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
foreach $file (@files) { open FH, $file or die "Error opening $file: $!\n";
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() }
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 #!/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__ $ ./ aaa The contents of `aaa' are: asdfdaf sfdfdd sffgsdd $ ./ '|echo "Gotcha!">' The contents of `|echo "Gotcha!">' are: $ cat Gotcha!
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...
elsif ( data =~ /^\x89PNG\x0d\x0a\x1a\x0a/) { type = 'PNG'; }
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...

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://480764]
[ovedpo15]: consider the following format of strings: some_data-doesn't- matter,value. how I get the value with regex? it should be after the last comma (last string)

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2018-05-27 08:46 GMT
Find Nodes?
    Voting Booth?