Re: code cleanup

Bruce Evans <bde_at_zeta.org.au> wrote:
> On Thu, 29 Apr 2004, Kris Kennaway wrote:
> 
> > On Thu, Apr 29, 2004 at 04:56:02PM -0400, John Baldwin wrote:
> > > On Thursday 29 April 2004 02:55 pm, Brian Fundakowski Feldman wrote:
> > > > For what it's worth, I don't think it is good to hide things as much as
> > > > FOREACH_PROC_IN_SYSTEM() -- this specific instance -- does, but grep is not
> > > > a good tool for a tree as large as FreeBSD's.  Try using cscope instead.
> > >
> > > I've used glimpse in the past but it is buggy.  Actually, grep -r on ssc/sys
> > > doesn't take that long, esp. if you do it multiple times as most of the tree
> > > is still in cache for subsequent grep's (at least on my laptop).  I also tend
> > > to have lots (around 7 or so) trees that have work going on in them at any
> > > one time.
> >
> > The problem with grep -r in src/sys is that it chokes on the symlinks
> > created by module builds and pollutes the output with hundreds of
> > lines of errors unless you remember to first remove the module build
> > files.
> 
> Use find(1) to not follow symlinks.  E.g.:
> 
> %%%
> Script started on Fri Apr 30 23:15:17 2004
> ttyp0:bde_at_besplex:/tmp> cd /sys
> ttyp0:bde_at_besplex:/sys> time find . -type f | time xargs grep fooo
>         0.42 real         0.01 user         0.06 sys
>         0.49 real         0.11 user         0.29 sys
> ttyp0:bde_at_besplex:/sys> exit
> 
> Script done on Fri Apr 30 23:15:33 2004
> %%%
> 
> This was fast because /sys was already in the disk cache.  It would have
> taken 15 seconds with a cold cache.

Yeah, but this fast is with nothing in the cache ;-)
{"/usr/src/sys"}$ time csgrep fooo
    0.15s real     0.00s user     0.03s system
It's hard to compare because you have to actually manually filter out those 
falses where "fooo" is not actually a C identifier.

> I also have:
> 
> lrwxrwxrwx  1 bde  wheel  28 Mar  6 06:57 /sys/i386/compile_at_ -> /usr/obj/usr/src/sys/compile
> 
> (see Makefile.i386 rev.1.28)
> 
> so I don't have any object files under /sys to slow down the search,
> except grep -r would follow this symlink too.
> 
> Perhaps it is a bug for grep -r to follow symlinks by default, especially
> since there is no way to change the default and whether symlinks are
> followed is not mentioned in the man page.  diff -r has the same problem.

I think it is very much a bug for grep to print out that it detected and 
stopped a directory loop -- that is very much the expected good-program 
behavior, is it not?  So much software gets this wrong.  Following directory 
symlinks isn't a terrible default behavior if it can detect loops, but 
having no control whatsoever like we do permanently is pretty gross.

Thankfully, cvs(1) is a repository format which could never support 
directory/symlink loops, so cvs diff -r at least doesn't get it wrong
(by luck).

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green_at_FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\