buggrep - Bugs: bug #32520, If you use --include -- grep does...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #32520: If you use --include -- grep does not recurse all subdirectires

Submitted by:  Keith Daniels <keithwdaniels>
Submitted on:  Thu 17 Feb 2011 05:24:50 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

Mon 28 Feb 2011 08:41:44 AM UTC, comment #6:

No problem.

Paolo Bonzini <bonzini>
Fri 18 Feb 2011 12:27:07 AM UTC, comment #5:

Sorry guys.

--include does work as expected.

The problem was not the grep command but my expectations of what the result "should" be.

I should have dropped back and done some simpler tests instead of using my "complicated" problem as a test bed.

Sorry to have wasted your time.

Thanks for the help and feel free to delete this embarrassing post

I think I am getting too old for this stuff...

<grin>

Keith Daniels <keithwdaniels>
Thu 17 Feb 2011 09:36:03 PM UTC, comment #4:

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.

Keith Daniels <keithwdaniels>
Thu 17 Feb 2011 08:24:11 PM UTC, comment #3:

Looks like a bug to me: everything else in the grep documentation about files and directories suggests that "file" does not include "directory", which means that grep doesn't do what it says. Also, this behavior is rather unfortunate, as it essentially makes --include useless with -r (except for some rather odd and hard-to-imagine-being-used cases).

Reuben Thomas <rrt>
Thu 17 Feb 2011 08:19:13 PM UTC, comment #2:

OK, I'm slow but I finally figured it out.

Ignore everything in my post. It's not a bug--it's a feature.

What confused me was this from the Info file:

`--include=GLOB'
Search only boldfilesbold whose base name matches GLOB (using wildcard matching as described under `--exclude').

You need to point out that it also blocks recursion in any directory whose name does not match the specified GLOB.

Best I can tell, there is no way to do what I wanted to do--without using a loop of some kind in a script as input to grep.

Keith Daniels <keithwdaniels>
Thu 17 Feb 2011 07:27:43 PM UTC, comment #1:

Ignore problem #2

I am posting a separate bug report based on new testing. Problem #2 exist but there is more to it than what I said and now I do not think the two problems are related.

I assume you can not edit your own post....

Keith Daniels <keithwdaniels>
Thu 17 Feb 2011 05:24:50 PM UTC, original submission:

The testing below was based on the example

grep -rH --include='*.c' 'hello' /home/gigi"

from the grep 2.7 Info file.

I found two problems which I think are related:

Problem #1:

If you use --include grep does not recurse all subdirectories.

Converting the Info example above to my situation gives incomplete recursion when this is run:

grep -rH --include='*.rc' 'extraToolBar' /home/$USER/.kde3/share

While this gives complete recursion when it is run:

grep -rH 'extraToolBar' /home/$USER/.kde3/share

Problem #2:

When specifying the path and globbing the file names the results appear to be inconsistent. I would have expected

/home/$USER/.kde3/share/*.rc

to work and

/home/$USER/.kde3/share/ *.rc

NOT to work.

Instead....

Running this gives complete recursion:

grep -rH 'extraToolBar' /home/$USER/.kde3/share/*

Running this does not work at all:

grep -rH 'extraToolBar' /home/$USER/.kde3/share/*.rc

Running this gives complete recursion -- BUT -- gives the error message "grep: *.rc: No such file or directory" at the end:

grep -rH 'extraToolBar' /home/$USER/.kde3/share/ *.rc

Keith Daniels <keithwdaniels>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bonzini (Posted a comment)
  • -unavailable- added by rrt (Posted a comment)
  • -unavailable- added by keithwdaniels (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 28 Feb 2011 08:41:44 AM UTCbonziniStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1