www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/07/18/06:52:34

Date: Thu, 18 Jul 1996 13:46:31 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "Dr. John Refling" <refling AT comet DOT lbl DOT gov>
Cc: djgpp AT delorie DOT com, DJ Delorie <dj AT delorie DOT com>
Subject: Re: find41b slow behaviour.....
In-Reply-To: <4sk11r$k46@overload.lbl.gov>
Message-Id: <Pine.SUN.3.91.960718130643.781A-100000@is>
Mime-Version: 1.0

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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019