However find has one huge advantage. It is one of the few ways to get around limitations with listing large numbers of files in shell scripts. The nom script given doesn't do that.

A second advantage is that while find has a more complex API, it is also more flexible... :-)

find . -type f -not -name '*.html' -maxdepth 1 -print | xargs rm -rf;

The above only launches three processes (well, actually a few more if xargs decides there are too many files), and since it's I/O bound, I doubt a Perl based solution would be significantly faster (and personally, my wager is that it would be slower).

However, I agree that shell scripting would be slower in general than Perl, for the reason of process creation. But I don't think this case counts.

Ciao,
Gryn :)

And it freaks badly if you have any filenames with whitespace in them, especially a newline. This same thing in Perl works just fine in one process:

#!/usr/bin/perl
opendir DOT, ".";
unlink grep { -f and  not  /\.html$/ } readdir DOT;
[download]

-- Randal L. Schwartz, Perl hacker

In case you care:

find . -type f -not -name '*.html' -maxdepth 1 -exec rm '{}';

Does the same job with only one process.

For me, performance doesn't matter that much. I usually deal with 100..2000 files each time and running time isn't much different.

One should measure the total time from the split-second in which your brain decided what you want to do and until you see the next command prompt :)

This is why it's useful to have simple basic blocks (with short names :) that do the job.