buggrep - Bugs: bug #17623, add option to grep -R to NOT...

 
 

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

bug #17623: add option to grep -R to NOT follow symlinks to directory

Submitter:  Emmanuel Viennet <emmanuelito>
Submitted:  Wed 06 Sep 2006 07:09:24 AM UTC
Votes: 26
 
Category:  None Severity:  2 - Minor
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Jump to the original submission

Thu 15 Mar 2012 09:58:15 PM UTC, comment #7: 

I installed a patch for this, so that -r does not follow symlinks or read devices (but -R still does, for those who prefer this):

http://git.savannah.gnu.org/cgit/grep.git/commit/?id=c6e3ea61d9f08aa0128a0eb13d31a2fbad376f99

So I'm closing the bug report as 'fixed'; if there's a problem with the solution, please let me know and we can reopen the bug.

Paul Eggert <eggert>
Group Member
Tue 03 Jan 2012 11:32:41 PM UTC, comment #6: 

This would break compatibility, but distinguishing based on case would be a simple option: -r/-R. For example, grep in Heirloom seems to be doing that. Afaict, for grep 2.7 -R, -r, --recursive are all the same.

From Heirloom grep man:

The following options are supported as extensions:
-r         With this option given, grep does not directly search in each given file that is a directory, but descends it recursively and scans each regular file found below it. Device files are ignored. Symbolic links are followed.
-R         Operates recursively as with the -r option, but does not follow symbolic links that point to directories unless if they are explicitly specified as arguments.


Alexei Colin <alexei>
Tue 16 Mar 2010 07:47:09 PM UTC, comment #5: 

Any chance of an update? This would be really amazingly helpful.

For example, when trying to find a string which we know is in /etc/<somewhere>, it's sensible to grep through a few MB of stuff in /etc. Except that apache is often configured with symlinks from /etc/ to /lib 

Similarly, when searching in /home, one might come across .wine/dosdevices/*  which symlink back to /

And the grep then ends up taking an hour.

Richard Neill <richardneill>
Wed 23 Dec 2009 07:55:25 AM UTC, comment #4: 

What about --[no-]dereference-symlink-to-dir (can be shortened to --[no-]dereference since there's no ambiguous option)?  cp's -H could become --dereference-symlink-to-dir=cmdline (using an optional argument).

-S can be used as a short option.

Karl's proposal to have --directories=recurse-no-symlink is a bit ugly because there is no quick way to specify it as a short option.

Paolo Bonzini <bonzini>
Tue 22 Dec 2009 10:18:19 PM UTC, comment #3: 

Use the same option name as in coreutils?
--dereference-command-line-symlink-to-dir

And FWIW, personally I'd be happy if --dereference-command-line-symlink-to-dir became the new default (even me, Mr. Backward Compatibility Rules :).  I suspect that's what users really want/expect 99% of the time.

Having these things as option values for --directories sounds reasonable, given that we are talking about following symlinks to dirs, not files (right?).



Karl Berry <karl>
Group Member
Tue 22 Dec 2009 08:31:02 PM UTC, comment #2: 

Hi Paolo,

I too have long wished for a way to make grep -R not follow symlinks.

My first thought was to handle it like find, cp, du, ls and chown etc.
have done, with their -H, -L and -P options, but all of those are already
in use with grep.

One approach would be to extend
--directories=...
or some new long-option to accept three new values,
corresponding to these (useful only with --recursive, which is
equivalent to --directory=recurse, or perhaps implying that):

  H  traverse-command-line-symlink-to-dir
  L  traverse-every-symlink-to-dir
  P  traverse-no-symlink-to-dir

Jim Meyering <meyering>
Group administrator
Tue 22 Dec 2009 09:12:32 AM UTC, comment #1: 


> grep -R follows symbolic links, unlike cp or ls.
> At least, one option should be provided to disable this behaviour.


Jim, do you have an opinion on this?  I'm inclined to mark it as invalid or at least as an enhancement, but you're the expert on these things. :-)

Paolo Bonzini <bonzini>
Wed 06 Sep 2006 07:09:24 AM UTC, original submission:  


grep -R follows symbolic links, unlike cp or ls.
At least, one option should be provided to disable
this behaviour.




Emmanuel Viennet <emmanuelito>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by eggert (Posted a comment)
  • -email is unavailable- added by musiphil (Voted in favor of this item)
  • -email is unavailable- added by alexei (Posted a comment)
  • -email is unavailable- added by alexei (Voted in favor of this item)
  • -email is unavailable- added by gregor (Voted in favor of this item)
  • -email is unavailable- added by richardneill (Posted a comment)
  • -email is unavailable- added by karl (Posted a comment)
  • -email is unavailable- added by meyering (Posted a comment)
  • -email is unavailable- added by bonzini (Posted a comment)
  •  

    There are 26 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-03-15 eggert StatusNone Fixed
        Open/ClosedOpen Closed
    2012-03-15 musiphil Carbon-Copy- Added musiphil
    2012-01-03 alexei Carbon-Copy- Added alexei
    2011-09-18 gregor Carbon-Copy- Added gregor
    2009-12-23 bonzini Severity3 - Normal 2 - Minor
        Summarygrep -R should NOT follow symlinks add option to grep -R to NOT follow symlinks to directory

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code