Allow following symlinks to files

[smammy]

I just got caught in the situation described in #460: ripgrep didn't find a file I knew existed, and it turned out that the file was actually a symlink to another file in the same directory.

In general, it seems to me that skipping symlinks to directories is a sensible default, but I'm not quite convinced that skipping symlinks to files is sensible. At least I'd like to be able to ask ripgrep to follow symlinks to files and search their contents without ripgrep also following symlinks to directories and recursing into them.

While following a symlink to a huge directory, or a directory on a network share, or to, say, /proc or /sys could cause all sorts of pathological behavior, following a symlink to a file only doubles the matches output for that file.

I propose an extension to the --follow switch to specify which target types should be processed via symlinks. It could be documented as follows:

-L, --follow[=WHICH]
    By default, ripgrep only processes symlinks given
    as PATHs on the command line. This flag instructs
    ripgrep to also process symbolic links it
    encounters while traversing directories.
    
    Note that ripgrep will check for symbolic link loops
    and report errors if it finds one. ripgrep will also
    report errors for broken links. To suppress error
    messages, use the --no‐messages flag.
    
    WHICH can be `to-files' or `to-directories' to limit
    ripgrep to only processing symlinks that resolve to
    regular files or directories, respectively.

Thanks for considering this!

[BurntSushi]

What does GNU grep do here?

[smammy]

grep -r ignores all symlinks (other than those given on the command line), and grep -R dereferences all symlinks. If I wasn't accustomed to ripgrep, I'd probably use something like this:

find haystack \! -xtype d -exec grep -H needle '{}' +

(But I'd prefer not to have to.)