From: Rick Bradley <rick@...>
Date: 2002-06-15T13:34:34+09:00
Subject: Re: Are Unix tools just slow?

* Chris Gehlker (gehlker@fastq.com) [020614 21:54]:
> I've learned of list that some other *nixen have optimized equivalents of
> find but they are always called something other than 'find'.

Define "equivalents".  If by that we mean "return lists of filenames
matching a substring request" then there are typically optimized
variants, and one can imagine a number of other optimizations for the
"where's my file?" crowd.  However, find is much more powerful than
this, and this power is the reason for its continued presence in
(?:/usr)?/bin.  Think of find as the Swiss Army Knife for traversing,
selecting, and acting upon filesystem nodes.

Here are a few of the many find invocations from my bash history over
the past day or so:

 cat /tmp/missing | sed 's/^\(.*\)/echo "\1"; find split_new -type f -exec grep -l "\1" {} \;/' | sh -s

 find split_new -type f -name '*.new' -exec perl -i.orig -pne '$_.= ">" if(m:<par/$:)' {} \;

 find merge -newer timestamp -exec cp {} ../complete \; ; touch timestamp

That's ignoring the less frequent usage of [acm]time, user, perm, prune,
etc., arguments that have expired from my history, but which are
littered about crontabs far and wide.

[ forgive the senseless use of 'cat' -- it is easier to prepend the
  input source when building command-lines than to worry about the
  wasted process; oh, and forgive that perl snippet -- I'm still
  getting acclimated to Ruby... ]

Rick
-- 
 http://www.rickbradley.com    MUPRN: 950    (77F/82F)
                       |  regex function like
   random email haiku  |  this: prefix_index.php the file,
                       |  that should be cached.