You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that passing a plain directory as argument to -g should match files in that directory. Moreover, prefixing a match string with ! should negate the results. This seems to the behaviour most of the time.
If this is a bug, what are the steps to reproduce the behavior?
## from temp, empty directory
mkdir a b
echo hello > a/test.txt
cp a/test.txt b
rg -g a hello ## return nothing
rg -g '!b' hello ## returns match from file in 'a'
If this is a bug, what is the actual behavior?
Above script yields following (showing output of negated search only)
▶ sh /tmp/run.sh
a/test.txt
1:hello
If this is a bug, what is the expected behavior?
Should have yielded results for either both or neither (preferably both) the invocations in the reproduction steps.
The text was updated successfully, but these errors were encountered:
This is correct behavior. The -g/--glob flag applies to every file path searched. So the -g a behavior will cause ripgrep to descend into your a directory but not your b directory. However, a doesn't match any file inside your a directory. You can confirm this behavior by adding a a/a file:
$ echo hello > a/a
$ rg -g a hello
a/a
1:hello
If you do want to search everything in a, then you need to use a glob pattern that both matches the directory and the the files inside of it:
What version of ripgrep are you using?
How did you install ripgrep?
Compiled from source
What operating system are you using ripgrep on?
MacOS (Catalina)
Describe your question, feature request, or bug.
I think that passing a plain directory as argument to
-g
should match files in that directory. Moreover, prefixing a match string with!
should negate the results. This seems to the behaviour most of the time.If this is a bug, what are the steps to reproduce the behavior?
If this is a bug, what is the actual behavior?
Above script yields following (showing output of negated search only)
If this is a bug, what is the expected behavior?
Should have yielded results for either both or neither (preferably both) the invocations in the reproduction steps.
The text was updated successfully, but these errors were encountered: