[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grep --include does not work

From: LeonM
Subject: Re: Grep --include does not work
Date: Thu, 14 Jun 2007 00:17:53 +1000

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

> 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

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.


> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]