Does rg -g='glob' help to overcome "argument list too long" limitations?

[learnbyexample]

I was recently helping someone to filter files matching a pattern. With grep, they ran into argument list too long issue (which I believe is independent of the command being used). find is one way to workaround this problem.

I'm wondering if using the -g option (say rg -g='*.txt' 'search' instead of rg 'search' *.txt) will not run into this argument list too long issue.

[BurntSushi]

I think the surface level answer is "yes." It's definitely true that -g/--glob at least won't run afoul of the argument list too long problem because the glob is given literally for ripgrep itself to evaluate. But when you do something like rg search *.txt, that glob is evaluated by the shell (on Unix anyway) and expanded into a list of arguments before invoking ripgrep. So in the latter case, ripgrep doesn't even know a glob was used at all.

The other question is whether -g '*.txt' and *.txt are actually equivalent. They are not! Example:

$ tree         
.
├── bar.md
├── foo.txt
└── quux
    ├── bar.md
    └── foo.txt

1 directory, 4 files

$ rg -l wat        
foo.txt
bar.md
quux/foo.txt
quux/bar.md

$ rg -l wat -g '*.txt'
foo.txt
quux/foo.txt

$ rg -l wat *.txt     
foo.txt

In this case, you would need rg -l wat -g '/*.txt' to anchor it to the current directory.

[learnbyexample]

It's definitely true that -g/--glob at least won't run afoul of the argument list too long problem because the glob is given literally for ripgrep itself to evaluate.

Thanks, that's what I was looking for.

Sorry for the poor description of the problem. There were no sub-directories. Good to know the glob-pattern to exclude sub-directories.