patchgrep - Patches: patch #4354, add --no-recurse-symlinks feature

 
 

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

patch #4354: add --no-recurse-symlinks feature

Submitter:  None
Submitted:  Fri 26 Aug 2005 02:25:07 PM UTC
Votes: 20
 
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Originator Email:  -email is unavailable-
Open/Closed:  Closed

Jump to the original submission

Thu 15 Mar 2012 09:56:05 PM UTC, comment #6: 

As it happens I installed a patch for this in the past 24 hours, using the simpler approach similar to what's in bug #17623:

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

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

I'll close bug #17623 as well.

Paul Eggert <eggert>
Group Member
Thu 15 Mar 2012 09:30:38 PM UTC, comment #5: 

I'm surprised that this need hasn't been satisfied for over 7 years since the initial patch.

For your information, bug #17623 also deals with the same thing.

Seungbeom Kim <musiphil>
Sat 27 Aug 2005 07:13:18 AM UTC, comment #4: 

Hi, many thanks for your comments.

No, I don't think grep needs to implement all of find's expressiveness.  But it would be good at least to have a way to recurse without following symlinks, as this is the basic functionality that you get with -R in other GNU programs such as ls or chmod, so I'm a little surprised it isn't already the default for grep.

I think the --symlinks=ACTION idea is a good one, but I feel that the actions should be "follow", "skip" and something like "follow-if-listed".  The reason for "follow" rather than "recurse" is that some links may be to regular files etc.  If we go this route, then for consistency this option should also apply in the absence of recursion, even if it is rarely useful to specify it in that case.

I am going to be unable to check this page for at least the next few days, but I'll have a go at producing an updated patch I guess some time later next week, unless anyone else feels like doing it in the meantime.

Many thanks for the suggestion regarding code cleanup.  I suspect that the specific lines may change a bit anyway in the updated patch, but I will try to apply the same principles.  (Somehow I'd got the impression that GNU style was to use braces even for single-statement if/while/for, perl-style, but obviously this is wrong.)

Anonymous
Fri 26 Aug 2005 11:43:57 PM UTC, comment #3: 

The find command already does not follow symbolic links by default, so that the following pipeline can be used:

  find /usr/include -type f -print0 | xargs -0r grep -H lstat

instead of a hypothetically new

  grep -r --no-recurse-symlinks lstat /usr/include

Do we really need to duplicate all of find's expressiveness in grep?  If so, then I have looked at the patch and have the following comments:

-- The new "--help" source code string line should use the same end-of-line convention as its neighbors.

-- I think the patch is correct in not assigning a new single letter option (among the few that are left) for this.

-- In the currently added code in grepdir() [please use "diff -pu"], I would remove the redundant comment, unfold the if-condition on a single line and remove the braces around that inner-if body.

-- Another possibility for option syntax would be to remain consistent with --directories=ACTION and --devices=ACTION (already implemented in GNU grep) and use --symlinks=ACTION, where action could be "recurse", "skip", and something like "recurse-if-listed".  If push comes to shove, the -S option is still available in this case, but I would prefer not to.

Charles Levert <charles_levert>
Fri 26 Aug 2005 07:59:19 PM UTC, comment #2: 

Many thanks for the information about other GNU programs.

I feel that the behaviour in this context is not quite analogous to something like "ls".  In the case of ls, there is a meaningful way in which the symlink can be processed without following it.  With grep, all you can do is either follow symlinks or ignore them completely, and I think for example that using --no-dereference to refer to skipping symlinks would be rather confusing.  (And there is little use for skipping symlinks which are explicitly mentioned on the command line, except possibly a command line produced with shell globbing.)

I agree with using a consistent option name when the meaning is consistent, but by the same token I think when there is a different enough meaning a different name should be used.

Regards,
Alan

Anonymous
Fri 26 Aug 2005 07:14:33 PM UTC, comment #1: 

This should use an option name that is consistent with other GNU
programs.  The usual names for these options are as follows:

  -H, --dereference-command-line
                         follow symbolic links listed on the command line
  -L, --dereference      follow all symbolic links
  -P, --no-dereference   never follow symbolic links

The short names (-H, -L, -P) are specified by POSIX for many
commands, e.g., "ls".  Grep already uses these flags for
something else, but it should use the same long names anyway.

The flags -H, -L, and -P should override each other; the last one
specified on the command line should win.  POSIX requires this
for other programs.

I would say -H should be the default, but that's a judgment call
(it would change the semantics), and perhaps you'd prefer -L.

Paul Eggert <eggert>
Group Member
Fri 26 Aug 2005 02:25:07 PM UTC, original submission:  

Please find attached a patch which adds a flag --no-recurse-symlinks to GNU grep 2.5.1, for use with the --recurse option.

This patch allows the option to ignore symlinks encountered in the course of recursion, although any symlinks explicitly listed on the  command-line are still followed.

The reason for this patch is that although there is already a trap to avoid symlink loops, there are situations where following symlinks on recursion can still be unwanted -- e.g. the same file or directory gets searched multiple times, or a link points to a directory outside of the tree being recursed.

Anonymous

 

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

Attached Files
file #9284:  grep-2.5.1-no-recurse-symlinks.patch added by None (2KiB - application/octet-stream - Patch for --no-recurse-symlinks (against stable version 2.5.1))

 

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 (Posted a comment)
  • -email is unavailable- added by musiphil (Voted in favor of this item)
  •  

    There are 20 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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-03-15 eggert StatusNone Done
        Open/ClosedOpen Closed
    2011-08-13 musiphil Carbon-Copy- Added musiphil
    2005-08-26 None Attached File- Added grep-2.5.1-no-recurse-symlinks.patch, #5080
        Carbon-Copy- Added a --DOT-- m --DOT-- iwi --AT-- rl --DOT-- ac --DOT-- uk

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code