Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!freja.diku.dk!kimcm
From: kimcm@diku.dk (Kim Christian Madsen)
Newsgroups: comp.unix.shell
Subject: Re: Why use find? (Was: Can U pipe filenames to rm???)
Message-ID: <1990Oct7.001518.14216@diku.dk>
Date: 7 Oct 90 00:15:18 GMT
References: <28790001@col.hp.com> <1977@sixhub.UUCP> <1990Sep30.182331.14363@iconsys.uucp> <941@hls0.hls.oz> <1990Oct5.145825.9454@diku.dk> <1990Oct06.011438.8265@virtech.uucp>
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 66

cpcahil@virtech.uucp (Conor P. Cahill) writes:

>In article <1990Oct5.145825.9454@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes:
>>There are a lot of uses of xargs that are superior to using find with the
>>exec option. Find is *SLOW*, so if you have the names of files you want to
>>do something with in a file or pipe use xargs for performance.

>Find, in itself, is not slow.  The exec of a new process (the rm in this
>case) for every file found is *SLOW*.  Obviously, if you already have the
>list of files you don't need to run find to get them again. 

Maybe not on your system, but on my system (a SYSV) system, find perfoms
a getpwd(3C) each time it enters a directory, and getpwd(3) is by
standard implemented by forking a shell to do a pwd(1) in oorder to
get the result ... This makes it slow.

If this was not enough, find insists on wading through the entire
filesystem (relative to the starting point) even if matches was found, 
just to ensure that no additional matches are found - most often
you don't want this functionality (unless you're making a backup).

>>Find is also complicated to use for non-trivial tasks, and the syntax  is
>>often confusing to non-wizards, so specialized shell-scripts or programs
>>are often more intuitive and faster to create and maintain.

>This is getting into a typical religous issue, so I won't say much in
>response other than the fact that if someone knows enough about the system
>to creat shell scripts and/or programs it behooves them to take an 
>extra few minutes to learn find.

How about grouping selection criterias and the precedence of the -a and
-o (and & or) operators when grouping selection criterias ???

>Find in itself is not complicated (just some name selection logic) and 
>should be one of the tools that anyone writing shells is intimately aware
>of.  (BTW - I am one of the people that believe you shouldn't be allowed
>to write any shell scripts until you have made a complete pass through
>sections 1 & 1m (or 8, depending upon your OS) AND you should repeat this
>on a regular basis).

I'm not an apprentice in UNIX, in fact I have used the system extensively
for the last 8+ years, and uses find on a regular basis, also with fairly
complicated expressions. Still, there are times when find is not part of
the solution, and shell scripts are more intuitive.

>As an aside, most of the specialized shell scripts that you mentioned will
>usually run a find as part of the script anyway.

Sometimes, but most often good ole ls(1) will do the job nicely and faster.

>But to make the correct selection you should be aware of most, if not
>all, of the tools available (nothing is better than an educated decision).

There might be occasions when faced with the problem:

	The right way to solve problem X is to use tool Z, but in order
	to use tool Z which is either complicated to use or unfamiliar,
	the amount of time used in studying tool Z takes longer than to
	use another tool, that might not be the best, but is faster to
	employ and does the job.

The morale is optimal solutions are good -- but don't forget common
sense, or you'll end up searching indefinetely for the optimal solution
and gets nothing done, when time is critical!!!

					Kim Chr. Madsen