Fine, then post it here with "I know there are ways to do this with a few modules, but one of my design goals was to not use modules

Fair enough. I think I should add that as my standard disclaimer since I have a habit of doing that quite often.

Twice as many stats as you need (because you can get wether it's a file or a dir with one stat).

I was aware that there had to be a better way to end up with both @files, @dirs with one test but was and still am unsure how to do it. What do you suggest? Really... I was hopping for some code suggestions/improvements

Breaks on files name "..\n" (because you'll reject that with your regex match needlessly).

Where in the world are you going to find an image named '..'. I tried to create a file named '..' on windows and it will not let me. Regardless, I agree if you can create a file named '..' it will miss it, but is that really break it?? It's a bug that will silently ignore such file at most, correct? Really... I have seen mention of this before, but have never understood what the problem is. Is the problem eliminated with the use of !/^\.{1,2}\z/??

I do. You've posted this code here. Some crazy fool is going to cargo-cult your code without paying attention to your design goals or the following commentary. And that puts more bad Perl code in the world, not good code. {sigh}

merlyn, you need to stop worring about crazy people. No matter what anyone does they will still be crazy and eventually shoot themselves in the foot. :) However, this discussion has shown me some things I would not have been aware if I had not posted it.

I think I understand your frustration, however I disagree with your ideas on coping with it. The standard use CPAN response is valid but does not lead to people who know how to write better code. They do write better code because the bugs that would have been in their implementation are not there. However, they do not understand why their version had bugs. I think it keeps them as cargo-cult programers who just know how to do the routine to get the results they want. They do not grow. Im trying to grow. Telling me bad boy, dont rewrite. Will just keep me writing bad code in this world. However, If you tell me what Im doing wrong I will (hopefully :) ) learn from my mistakes.

THANKS

I was aware that there had to be a better way to end up with both @files, @dirs with one test but was and still am unsure how to do it. What do you suggest? Really... I was hopping for some code suggestions/improvements

here's one way to do it:

# your version
# my @tmp = readdir(DIR);
# my @files = map { "$dir/$_" } grep { !/^\.{1,2}$/ && -f "$dir/$_" } 
+@tmp;
# my @dirs  = map { "$dir/$_" } grep { !/^\.{1,2}$/ && -d "$dir/$_" } 
+@tmp;

# another version
my @files;
my @dirs;
my @tmp = grep { ! /^\./ } readdir DIR; # grep once.
foreach (@tmp) {
   if ( -d "$dir/$_" ) {                # stat once.
       push @dirs, "$dir/$_";
   } else { 
       push @files, "$dir/$_";
   }
}
[download]

---

He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.
Chady | http://chady.net/

Are you a Linux user in Lebanon? join the Lebanese GNU/Linux User Group.

When I was writing this, I started off just looking for files in the current directory. So,  my @files = map { "$dir/$_" } grep { !/^\.{1,2}$/ && -f "$dir/$_" } was nice and compact and seemed very perlish.

I then decided to allow directory traversal and kept the same code format. Still nice and compact, only 3 lines compared to 10 in your method. Of course, mine is obviously way less efficient.

I can't think of a way to eliminate the extra grep and stat and keep the same compactness.

Thanks for you suggestion.

zzSPECTREz

please read my disclaimer