Date: Fri, 30 Apr 2004 09:50:16 -0400 From: Brian Fundakowski Feldman <green@freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: code cleanup Message-ID: <200404301350.i3UDoGnX076521@green.homeunix.org> In-Reply-To: Message from Bruce Evans <bde@zeta.org.au> <20040430231553.X15963@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans <bde@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@besplex:/tmp> cd /sys
> ttyp0:bde@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@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@ -> /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@FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404301350.i3UDoGnX076521>