"quick" (even with Indexing service started) search program
and SQL engine is too much efford, here is my solution:
# my 'music' directory contains over 5000 files
# so the fastest way to be listed:
D:\tree /f /a .\music > \music_list.txt
# later the following script is 'move'd to
# %systemroot%\system32
### begin
use strict;
my $argv = join '.*', @ARGV;
my $song = qr/\|(?!\+\S{3})(\s.*?)$argv/i;
my $clean = qr/^\W+(.+?)\W+$/;
my $file = 'd:\music_list.txt';
my $album = q::;
open my $fh, $file
or die "cannot open $file: $!$/";
while(<$fh>){
/(\\|\+)-{3}/
and $album = $_
and next;
if (/$song/) {
s/$clean/$1/ for $_, $album;
$album
? print "album: $album$/","song: $_$/$/"
: print "album: . $/","song: $_$/$/";
$main::counter++;
}
}
print "$/total: $main::counter song(s) found$/"
if $main::counter;
__END__
### end
# finally
D:\copy ffind.pl %systemroot%\system32
D:\ffind.pl compare
album: Good music
song: Sinead O'Connor - Nothing Compares 2 U.mp3
album: party
song: Sinead O'Conner - Nothing Compares To You.mp3
total: 2 song(s) found
That's all.
The only problem with the OP code is that you have to remember to run "tree" yourself -- and save its output in a specific file whose name is hard-coded in your perl script -- before running the script, so that you know your file list is up-to-date. But that's unnecessary -- just run "tree" inside the perl script (it'll still run just as fast):
my $music_path = ".\\music"; # probably should make this an absolute path...
open my $fh, "D:\\tree /f /a $music_path |"
or die "cannot run tree on $music_path: $!";
while ( <$fh> ) {
# everything else stays the same...
}
(not tested -- I'm not a windows user)
Actually, it might also be interesting to see whether a win/dos port of the unix "find" utility is slower or faster than "tree"...
# rough comparison
D:\music>perl -MFile::Find -e "find(sub{$File::Find::name}, '.');print time-$^T"
6
D:\music>perl -e "`tree /f /a`;print time-$^T"
1
Where "music" contains 5547 files (without the directory inodes).
I'm wondering what you mean by that. There are windows ports of "find" available (google "unix tools for windows"); the ATT Research Labs version and the cygwin version are both authentically "unix-like" (or maybe "gnu-ish" is the better term).
"tree" filtered results solve to some extent this problem
Oh yes. That seems consistent with what I've seen in the unix domain -- about a 5- or 6-to-1 speed ratio comparing File::Find to "find". For really big directory trees, that multiplier becomes devastatingly significant.
/J
my $search_what = shift
|| die "no search criteria provided\n";
my $search_where = shift;
my $file = qr/\|(?!\+\S{3})(\s.*?)$argv/i;
my $clean = qr/^\W+(.+?)\W+$/;
$dir = -d $dir
? $dir
: '.';
for(`tree /a /f $search_where`){
/(\\|\+)-{3}/
and $dir= $_
and next;
if (/$search_what/) {
s/$clean/$1/ for $_, $dir;
$dir
? print "dir: $dir$/","file: $_$/$/"
: print "dir: . $/","file: $_$/$/";
}
}
This was discussed in considerable length in Myth busted: Shell isn't always faster than Perl and was wondering if you can back up the claim of "much longer" . My tests show differences of only a fraction of a second on 100 meg tree.
I'm not really a human, but I play one on earth. flash japh
In any case, I posted some benchmarks here and here. Looking at those again just now, my statement above about "5- or 6-to-1" should have simply been "5-to-1".