Re: Grep --include does not work

[LeonM]

> I did not recommend that.  I recommended this:
>
>   grep -R --include="*.txt" "include" .
>
> > I have got this:
> > [...all of the binaries match...]
>
> That is as expected.  Right?
For 2.5.1a yes. That's correct behaviour as I have asked it to
consider all files, ie. no --include

> > Now if I run it with
> > grep -R --include="*.txt" -P help .
> >
> > I have got this:
> > ./GnuWin32Grep/TestGrep.txt:    Hello with Tab+space help Perl
>
> That is also as expected, right?  You said that you modified that file
> to contian the help word.  It matches.  None of the other files match
> the '*.txt' pattern and so were not considered as part of the grep.
>
> So far all looks as expected.  Agreed?
Yes, we are all in agreement with version 2.5.1a but not 2.5.1a-1. In
2.5.1a-1, it has been acknowledged as a bug fixed in 2.5.1a. See
comment
https://sourceforge.net/tracker/?func=detail&atid=379173&aid=1733145&group_id=23617

> > I am not disputing the fact that with or without --include a much
> > larger dataset (file list) is generated. The fact is that all I care
> > in the output are those in the text file. Moreover, the --help message
> > for --include says this:
> > --include=PATTERN     files that match PATTERN will be examined
>
> Yes.
Thank you. Glad my reading of the instructions is right.

> > So my reading tells me that it will generate a long list of files but
> > only those that matches this pattern (in my case *.txt) will be
> > examined. So without --include, everything will be examined and the
> > result seems to agree with this interpretation.
>
> Yes.
>
> > If I replace the end '.' with '*' I get the same result.
>
> Huh?  This is not what you reported previously.  Previously you said
> that grep ignored the --include option and searched all files in the
> directory tree and printed all matches.  But all of this depends upon
> what files are in the current directory for the '*' to be expanded
> into when running the command.  This is probably causing confusion.
My previous command uses * and I must have misread your suggestion not
to use * but to use .

All my concern is with respect to the correct processing of the
--include. But don't forget I am talking about recursive here with the
-R and so the files are what are the files in the current directory
and in its sub-directories. My tests with using . and * seem to make
no difference at all. Using Grep.exe in 2.5.1a, with the same command
line argument bar the end . or * produces the same result. This
observation has not invalidated my report, which claims 2.5.1a-1 fails
to process --include correctly.

If I use grep 2.5.1a-1 it all picks up all the binaries with * or .

So I am confused with the usage of last character * and . That's
 grep -R --include="*.txt" -P help .
 grep -R --include="*.txt" -P help *

Since they produce the same result I will use the * as it seems to be
more logical - everything zero or more.

> Grep was developed on the Unix system in 1973 and behaves as expected
> on a Unix system.  MS-Windows had not been invented yet.  Grep is not
> doing bad for a 34 year old paradigm!
Not trying to influence the command syntax of grep, which is rooted in
Unix. I am just making a point as a Windows user.

> This is actually a common FAQ and also shows up for other commands
> too.  Here is one that talks about 'rm' but also applies to your
> question too.  (Full disclosure: I wrote that FAQ entry.)
Thanks for the information.