Descending directory hierarchy?

[Guy Harris]

>I've been thinking about the find command on SysV's... the one that makes you
>type find / name [filename] -print to find files, and only finds files with
>the exact filename specified...

No, it finds files whose names match the *pattern* specified, e.g.

	find / -name '*.c' -print

will show all the files with names that end in ".c".

>and I've been thinking about writing a program that will act like the
>BSD find... it list all files with the phrase you look for in the
>filename... (like if I looked for t, I'd get a lot of files listed)

The BSD "find" is really two programs jammed into one executable file:

	1) the standard UNIX "find", which exists on BSD, S5, etc.,
	   etc., and recursively walks a directory tree;

	2) the "fast find", which searches a database built, generally,
	   by a "cron" job that runs at night.

You're thinking of the second program.  Unfortunately, since they *were*
jammed into one executable (and source) file, and since the first
program is derived from AT&T-licensed code, you can't get the source to
the second program without an AT&T source license, unless they've either
1) replaced the first program with an "AT&T-free" version or 2) split
them into two files.  I really wish they'd at least do the latter....

>Which brings me to the question: Is there a way to descend the directory 
>hierachy into every directory, or do I have to write a routine to do that?

The "fast find" doesn't descend the directory hierarchy; it just zips
through a database built from a script that runs the conventional "find"
(the first program).  If you wrote a version that worked like the "fast
find" but that descended the directory hierarchy, it would act just like

	find / -name <pattern> -print

which is 1) a lot easier to type than the source code to a program that
duplicates this functionality and 2) a lot slower than "fast find".

(To be precise, quoting the comment at the front of the 4.3BSD "find.c":

 *              The second form searches a pre-computed filelist
 *              (constructed nightly by /usr/lib/crontab) which is
 *              compressed by updatedb (v.i.z.)  The effect of
 *                      find <name>
 *              is similar to
 *                      find / +0 -name "*<name>*" -print
 *              but much faster.
       
Note that the "fast find", according to a comment I remember its author,
James A.  Woods, making, doesn't handle files with names containing
characters with the 8th bit set.  Yes, such files exist; at one point I
had a symbolic link to "/vmunix" named "/UNIX(R)", where "(R)" was the
ISO Latin #1 "registered trademark" symbol.  I could easily believe that
users in countries whose native language isn't English - especially
non-computer-weenie users - would give files names in their native
language, including accented letters from ISO Latin #1.)
Newsgroups: johnb at lakesys.lakesys.com
Subject: Re: Descending directory hierarchy?
Summary: 
Expires: 
References: <1372 at lakesys.lakesys.com>
Sender: 
Reply-To: guy at auspex.auspex.com (Guy Harris)
Followup-To: 
Distribution: usa
Organization: Auspex Systems, Santa Clara
Keywords: directory list find search

>I've been thinking about the find command on SysV's... the one that makes you
>type find / name [filename] -print to find files, and only finds files with
>the exact filename specified...

No, it finds files whose names match the *pattern* specified, e.g.

	find / -name '*.c' -print

will show all the files with names that end in ".c".

>and I've been thinking about writing a program that will act like the
>BSD find... it list all files with the phrase you look for in the
>filename... (like if I looked for t, I'd get a lot of files listed)

The BSD "find" is really two programs jammed into one executable file:

	1) the standard UNIX "find", which exists on BSD, S5, etc.,
	   etc., and recursively walks a directory tree;

	2) the "fast find", which searches a database built, generally,
	   by a "cron" job that runs at night.

You're thinking of the second program.  Unfortunately, since they *were*
jammed into one executable (and source) file, and since the first
program is derived from AT&T-licensed code, you can't get the source to
the second program without an AT&T source license, unless they've either
1) replaced the first program with an "AT&T-free" version or 2) split
them into two files.  I really wish they'd at least do the latter....

>Which brings me to the question: Is there a way to descend the directory 
>hierachy into every directory, or do I have to write a routine to do that?

The "fast find" doesn't descend the directory hierarchy; it just zips
through a database built from a script that runs the conventional "find"
(the first program).  If you wrote a version that worked like the "fast
find" but that descended the directory hierarchy, it would act just like

	find / -name <pattern> -print

which is 1) a lot easier to type than the source code to a program that
duplicates this functionality and 2) a lot slower than "fast find".

(To be precise, quoting the comment at the front of the 4.3BSD "find.c":

 *              The second form searches a pre-computed filelist
 *              (constructed nightly by /usr/lib/crontab) which is
 *              compressed by updatedb (v.i.z.)  The effect of
 *                      find <name>
 *              is similar to
 *                      find / +0 -name "*<name>*" -print
 *              but much faster.
       
Note that the "fast find", according to a comment I remember its author,
James A.  Woods, making, doesn't handle files with names containing
characters with the 8th bit set.  Yes, such files exist; at one point I
had a symbolic link to "/vmunix" named "/UNIX(R)", where "(R)" was the
ISO Latin #1 "registered trademark" symbol.  I could easily believe that
users in countries whose native language isn't English - especially
non-computer-weenie users - would give files names in their native
language, including accented letters from ISO Latin #1.)