>>> 	(3) is more flexible (both because of find's flexibility, and
>>> 	    because you can do a lot with a pipeline).
>> 
>> This is true.  But find ... | xargs ... can't be argued to be more 
>> intuitive than grep, and certainly not easier to use.  
> 
> If you're using multiple systems, and you want the 'way you work' to
> be portable between them, then 'recursive grep' is _impossible_ to use.

Reductio ad absurdum: Therefore you never use a single switch on any program
which isn't in every single variant?  What do you do when you get on that
SGI and you just *have* to use "ps -ef", no matter how much your fingers want
to type "ps -aux"?  Do you always do "chown <user> foo ; chgrp <group> foo"
because some System V variants don't supply a "chown" that can do
"chown <user>.<group> foo"?

>> In short:  Unix wizards might despise the idea of a recursive grep, but 
>> it is something that everyone else really needs and could use.  
> 
> I think the answer here is: if you're not willing to learn the basic
> UNIX tools (and find and xargs _are_ basic UNIX tools), why the hell
> are you running UNIX?

So when does the commit go into the tree to remove the "-R" options from
"chown" and "chmod"?  After all, if you need those, you're a wimp ...

> If you want a Mac, go use a Mac.  some of the advantages of UNIX include:
> 	(1) ability to pipe data between programs easily,
> 	(2) simple tools that are easily used in pipelines, and
> 	(3) mostly-standard interfaces to standard tools.
> 
> why screw with it?

Funny you should mention a Mac.  The other day my boss got a strange error
trying to fire up MAE, the Mac emulator for Solaris/HP-UX.  I tried to find
out where the heck this message was coming from.  So of course I tried

bubbles:1:22 [/opt/apple] % find . -type f -print | xargs egrep -l boot2
xargs: Missing quote?: Users Guide

It was stumbling across

./docs/MAE User's Guide

Or how about

netbsd4me:1:34 [/tmp] % ls -l test
total 0
-rw-r--r--  1 earle  wheel  0 Jan 23 14:13 This file has spaces in it
netbsd4me:1:35 [/tmp] % find . -type f -print | xargs egrep -l foo
egrep: ./test/This: No such file or directory
egrep: file: No such file or directory
egrep: has: No such file or directory
egrep: spaces: No such file or directory
egrep: in: No such file or directory
egrep: it: No such file or directory

or

netbsd4me:1:36 [/tmp] % touch test/MAE\ User\'s\ Guide
netbsd4me:1:37 [/tmp] % find . -type f -print | xargs egrep -l foo
xargs: unterminated quote

Now when should we expect commits to fix "find" or "xargs" so that it emits 
filenames enclosed in quotes so "egrep" doesn't barf?  Or fixing "xargs" so
that it handles quotes in filenames?

No; maybe I guess we should just expect all UNIX novices to know how to do
something like

netbsd4me:1:42 [/tmp] % find . -type f -print | sed 's/^\(.*\)$//'\1'/' | \
xargs egrep -l foo
netbsd4me:1:43 [/tmp] %

to get around this, right?  I mean, if they can't use the tools, honestly ...

At first I was prepared to argue that "find" *already* uses the FTS routines
(or so a cursory glance at the -current "find" source would imply), so the
initial assertion that an FTS-aware "recursive grep" would be a lot faster
seems specious.  But appealing to "this is UNIX, if you want a Mac, go use a
Mac" - especially when said UNIX tools are broken in instances such as I've
quoted above - is a lot more specious.  Try again ...

	- Greg