Date: Thu, 18 Jul 1996 13:46:31 +0200 (IST) From: Eli Zaretskii To: "Dr. John Refling" Cc: djgpp AT delorie DOT com, DJ Delorie Subject: Re: find41b slow behaviour..... In-Reply-To: <4sk11r$k46@overload.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 18 Jul 1996, Dr. John Refling wrote: > find . -exec dir {} ; > > it grinds away for a long time and never prints anything. > same with -echo {} ; ^^^^^ You mean "-exec echo", right? First, `find' is not supposed to invoke built-in shell commands at all. That's exactly how it works on Unix (try it). So you should actually say something like this: find . -exec command /c echo {} ; With `dir', even that won't work, because `find' calls it with a pathname with forward slashes, which `dir' doesn't understand :-(. That is not a problem if you really need the long listing of the file info, because `find' has a `-ls' option which does just that, but it would be a real problem if you'd like to invoke one of the DOS programs this way. That is why in the improved port of GNU Findutils I added two options: "-dosexec" and "-dosok" that convert all slashes to backslashes before calling the child program. I've uploaded the improved port at least 2 months ago to DJ's server. It's too bad DJ didn't have time yet to put it on SimTel (it also corrects a few more bugs in the original one, is *much* faster, and ports all the programs in the package, including `xargs', `locate' and `updatedb')... > When I use > > find . -exec ls -a {} ; > > I get a few lines of files, then about 5 minutes of hard drive access, then > a few more lines of files, then 10 minutes of disk access, then I control-c I'd guess that this is a manifestation of another bug in the original port of `find': it doesn't set the working directory correctly when it calls the child program. So `ls' gets pathnames that don't exist relative to its working directory, and thus it doesn't print anything. Another possible reason might be that you use a port of `ls' that doesn't grok forward slashes either. > out. It has listed about 100 out of 8000 files in 15 minutes. This is on > a 150MHz pentium! The CPU speed has (almost) nothing to do with the speed of `find', which spends most of its time calling `stat' on files and reading directories. That is a disk-intensive operation whereby you will gain much more from a fast disk than from a fast CPU. The improved port speeds `find' by a factor of 2-8 by letting it consider less files.