[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: Mon, 11 Jun 2007 22:57:10 +1000


I am still as confused as before. I have kept my greptest directory.
Here is what it looks like:

|   TestGrep.txt
|   |   grep-2.5.1a-1-bin.zip
|   |   grep-2.5.1a-1-dep.zip
|   |   grep.exe
|   |   libiconv2.dll
|   |   libintl3.dll
|   |   pcre3.dll
|   |   TestGrep.txt
|   |
|   \---2.5.1a
|           grep.exe
|           libiconv2.dll
|           libintl3.dll
|           pcre.dll
|   +---GnuWin32Grep
|   |       grep-2.5.1a-1-bin.zip
|   |       grep-2.5.1a-1-dep.zip
|   |       grep.exe
|   |       libiconv2.dll
|   |       libintl3.dll
|   |       pcre3.dll
|   |       TestGrep.txt
|   |
|   +---OldGnuGrep
|   |       grep.exe
|   |       Grep_1.exe
|   |       Grep_2.exe
|   |
|   \---UnxUtils
|           grep.exe
|           TestGrep.txt
|           UnxUtils.zip
|       grep.exe
|       Grep_1.exe
|       Grep_2.exe
   |   grep.exe
   |   UnxUtils.zip

Each grep.exe as you are aware contains the word 'help'. I have also
deliberately modified ./GnuWin32Grep/TestGrep.txt to have a line
containing the word help. All other text files do not have this.

When I run grep in GnuWin32 v2.5.1a without the --include but with the
'.' as you recommended like this:
 grep -R -P help .

I have got this:
Binary file ./GnuWin32Grep/2.5.1a/grep.exe matches
Binary file ./GnuWin32Grep/grep.exe matches
./GnuWin32Grep/TestGrep.txt:      Hello with Tab+space help Perl
Binary file ./greptestdata/GnuWin32Grep/grep.exe matches
Binary file ./greptestdata/OldGnuGrep/grep.exe matches
Binary file ./greptestdata/OldGnuGrep/Grep_1.exe matches
Binary file ./greptestdata/OldGnuGrep/Grep_2.exe matches
Binary file ./greptestdata/UnxUtils/grep.exe matches
Binary file ./LatestGnuGrep/grep.exe matches
Binary file ./LatestGnuGrep/Grep_1.exe matches
Binary file ./LatestGnuGrep/Grep_2.exe matches
Binary file ./UnxUtils/grep.exe matches
Binary file ./UnxUtils/temp/grep.exe matches

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

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

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. So I am
confused. Ideally, I should be able to specify this:

grep -R -P help *.txt

To a Windows program, this is the most logical specification. But it
does not work as it produces no results.

Do you have a good tutorial site devoted for recursive search?

I have even used the Windows XP "for /R" command and then get grep to
process file by file in the for command like this:
for /R . %A in (*.txt) do type %A |grep -P help

Not as nice as it still prints out the empty directories.

On 6/10/07, Bob Proulx <address@hidden> wrote:
LeonM wrote:
> Hate to disappoint you. My bug report to the GnuWin32 brought a
> different reaction.

I am not disappointed.  I suggested that you follow up with the
GnuWin32 folks and you have done that by filing a bug there.  That is
perfect!  Thank you for doing that.

> Obviously a developer (both those examining the bug report and myself)
> realizes that there is definitely a stuff up or bug in the transition
> from 2.5.1a to 2.5.1a-1 when they produce totally distinct behaviours
> with the same command line argument in the same OS.

No disagreement there.

> Either in processing the file globs or even doing reg exp matching, or
> both. They have accepted my bug report and has changed the status. You
> may follow the report in reguest ID 1733145.

I looked and did not see any commentary attached to that bug report at
this time.  But it is a freshly submitted issue.  I am sure that after
an apropriate time that it will get resolved.

> As a Windows programmer, I have to disagree with your assertion and
> dare to say that irrespective of any OS, when two minor version
> releases exhibit totally different behaviour, someone have stuffed
> that up.

You misunderstand me.  Let me explain my previous posting.

The use of '*' as an argument to grep when using grep's recursive
directory walking feature is not recommended.  It creates a data
dependent behavior that depends upon the files that exist at that time
in the current directory.  As Andreas pointed out any files mentioned
on the command line will always be considered regardless of --include
directives.  It is much better to use '.' instead of '*' as an
argument in these cases.  This is independent of OS.

> For your information, I have 2 copies of ver 2.5.1 of GNU Win32 grep
> (one from one known location and the other unknown) that work
> according to the documentation. The only one that fails to conform to
> the documentation is version 2.5.1a-1.

And you have filed a bug to the appropriate people at GnuWin32 on that
problem.  That is great.  Your attention to detail is appreciated.

> Hence I am happy and continue to use the grep. You may disagree with
> me, the right syntax to find the string 'include' in any text file
> recursively using the Perl Regular Expression is:
> grep -R --include="*.txt" -P "include" *

I do not understand why you would say this when it does not follow
from the documented behavior.  The use of '*' will expand to match
files in the directory.  Files in the directory are considered
regardless of the --include option.  Your original report was
specifically on this issue.  The reason for it is because of the use
of the '*' file glob in the command.  Avoiding the '*' and using '.'
solves the problem.  This is regardless of any particular *additional*
bug that may exist in the GnuWin32 grep-2.5.1a-1 binary that you are
using.  I don't dispute that there is an additional bug there.  I am
not familar with that particular binary version.  But using '*' with
both -R and --include is clearly not the best practice and should be

The confusion almost certainly is related to the fact that the
documentation is split into two places.  The grep documentation
describes grep in detail.  The bash (or other command shell)
documentation describes the command shell in detail.  Both sets of
docs need to be understood in conjunction with each other in order to
understand how file glob expansion works with commands.  The benefit
of this split is that the shell applies uniformly across all commands
and therefore is a high knowledge leverage across the entire system.


reply via email to

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