Follow-up Comment #4, bug #32520 (project grep):
Hi Reuben
I agree that it makes --include useless. I decided that the person writing
the Info file believed it was supposed to work this way from reading this clip
from the info file:
------
grep -rH 'hello' *.c
which merely looks for 'hello' in all files in the current
directory whose names end in '.c'. Here the '-r' is probably
unnecessary, as recursion occurs only in the unlikely event that
one of '.c' files is a directory.
------
Between the --include problem and this Info file statement above... it makes
recursion impossible if you want to recurse only specific files or file types.
BUT -- it was obvious that the writer of the Info file expected this behavior
at least from this type of command.
I just tested --include in grep 2.5.3 and it does work with that version. So I
have to agree, it is a bug.
Normally I just use a grep script that I created that lets me use 5 levels of
and/or/not logic in my searches to reduce unnecessary matches. But I am
working on KDE *.rc config files and there is so much duplication in non *.rc
files that I am being swamped with matches. My script doesn't let me filter
the file names so I was trying to see if I could use --include to solve the
problem.
Until this is fixed I will put in a sed statement to filter the output.
I hope you can fix it.
Thanks for the response.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?32520>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
