Wow, I'm really disappointed by this decision. It seems like it's pretty capricious and based more on tradition and hacker elitism.

<sarcasm>
- Just use a find pipe. It's more powerful. Just remember all six options, to escape the special shell characters, and don't forget xargs for performance.
- User-friendliness is overrated. I know a programmer who uses version 1.0 of Korn shell and turns his nose up at zsh and bash. Tab completion is for sissies.
- We added -r due to user demand, but dammit we're sick and tired of giving users what they want. --exclude-dirs is out of the question. And the maintainers of diff are idiots for supporting such a thing.
</sarcasm>

I hope you get my point. This feature can be added so that it doesn't break backwards compatibility. It's really useful for the majority of people who don't eat and breathe find/xargs. Plus there's at least one other person who was motivated enough to file a bug report: see #11017.

Seriously: **why** don't you want to go down that path? Because something more difficult already exists that can do the job? That doesn't seem like a good reason to me, given that the cost of adding the feature is so low.

I find it a bit more tedious to type. Yes, we could use aliases. But why chain aliases to find to xargs to grep, when it is a simple functionality that grep could (and should, if it can exclude files, which it should if it can recursive search, which it should) do on it's own quite easily.

The advantage of this approach is the unlimited versatility of this pipe; you can use all of the predicates of ``find'' to construct any condition you need.

For example, you can use

find . -type f -name '*.c' | grep pattern

or

find . -type f '!' -name '*.c' | grep pattern

To include or exclude files.

In particular, you can use

find . -type d -name .svn -prune -false -o -type f | grep pattern

to skip all directories named ``.svn''.
I admit this sounds complicated at first if you have never studied Prolog, but you can get into it. And then the possibilities are unlimited.

From this traditional point of view, the --recursive option of grep was always questioned. I know at least one hacker who deliberately ignores this option and uses find.

A short illustration of this position: does

grep --include='*.c' --exclude='core*'

search file core.c or not? If you use find, you never ask this question.

OTOH, the popularity of the ``rgrep'' tool has proved that there is market for quick recursive search; I guess this was why the -r option was introduced into grep.

The next natural step was introducing --exclude and --include. --exclude-dir would be the next natural step, I agree.

But I don't want to go long that path. We have to draw a line somewhere. And I decided to draw the line now and reject your patch. Sorry.

But I think that the ``simple recursive search'' should be as intuitive as possible. Ithink that one naturally tries --exclude=.svn first: and I propose that it should exclude directories too. I created bug #11017 to remember me.

On the contrary, --include doesn't apply to directory names, so --include='*.c' searches the whole subtree for C files.