#define AUTHOR "thieleke@icaen.uiowa.edu (Jeff Thieleke)"

/*
 * The point is that the recursive grep patch is already written, and it 
 * would take zero effort to included it in the NetBSD distribution.  If you 
 * want to write your database tool, then by all means, go ahead and write 
 * it.  Such a tool would be far too complicated for typical searches - 
 * why build a whole datebase just to search for one word.  For a file space 
 * as large as /usr/src/sys, you would need to search for a lot of patterns 
 * before you would even break even, compared to rgrep or find/grep.  Also, 
 * as others have pointed out, similar tools already exist.

A point which I forgot to acknowledge in my last letter.  Yes, such tools
exist, and to suit a particular purpose.  Such as looking through a
whole source tree for relevant words (like routine/variable/structure
tag/macro names or include files).

I still maintain that "find $DIR -xdev -name \*.c -print | xargs grep ..."
is not that hard to learn.

Besides that, if you're going to use grep in that manner to its full
advantage, don't you want to include YACLF to provide a glob as to which
files it should be looking at?  I sure as hell don't want to sit and wait
for an rgrep to go looking through the entire contents of a mostly-built
and populated /usr/src tree, only to blow up on a particularly large
object file or an executable because it wasn't smart enough to handle
a user-specified subset of files.

I think what people are trying to get across here is that while the
principle may have merit, the implementation is far too restrictive
and unnecessary to be of any real use.  Its scope becomes more limited
in that sense, and because more people may gravitate toward that scope,
because the code is limited in what it can do, the program actually
becomes fragile; people stop expecting grep to function as a standard
grep and they expect it to be something more.  Then they want it
to do even more ("Hey, we've kludged something in before, so we could
conceivably do it again...") and before too long, you're going to have
a bloated version of a program which should not have ever been expected
to do what it's doing, and not only will it be bloated but even more
fragile than it was.

Bells, whistles and chrome have mass in physical reality.  The same applies
to a piece of code.  And chrome isn't the most steadfast material --
it just makes the underlying metal look nicer.

One could look at grep and say "There's way too many flags in there".
Well, how many of those other flags can be achieved with other programs?
I don't see any.  The context grep code cannot be achieved with a program,
command or pipeline because grep won't spit out any of the other surrounding
lines.  Hence context printing must be included in the code.

Potential examples of code bloat are:
	The -h flag (suppress filename printing) could go away because one
	could use sed to achieve the same thing.

	The -o flag is nice, but not necessary, because one could simply
	provide an alternate filename on the command line, as has been
	done for(;;).

But those are *minimal* enhancements which make no assumptions on what
patterns the user wants, or from what files.  In a recursive grep,
you are assuming that the user wants to look through every file.

This is of course easy enough to fix, and I've been pounding on a very
minor nit, but do you see the points that people are trying to make?
There are other ways to do this without making grep into a program
which, when run outside of a special case, will exhibit its frailties.

Properly done, it is much better to trust two or more rock-solid
ends of a pipeline than to try and second-guess what your user will
want, and special-casing your program.  If you want to special-case
something, write a {shell,perl,whatever} script to handle the request.
I think the "old-timers" actually have it right on this one.

I also still maintain that dumbing things down is the wrong way to go and,
to paraphrase Chris (Demetriou), if you can't be bothered to learn something
or read the manual, what the hell are you doing using UNIX?

 *
 * Jeff Thieleke
 * 
 */
#undef AUTHOR	/* "thieleke@icaen.uiowa.edu (Jeff Thieleke)" */




				--*greywolf;
--
Solaris 2.0 -- "What a totally amazing excellent discovery.  NOT!"