Searching filenames (`-g` option in `ag`) #91

Valloric · 2016-09-25T22:29:39Z

Ag supports using -g to recursively search filenames matching the provided pattern. Ripgrep doesn't have this feature (to the best of my knowledge; I've read the --help output three times looking for it); it's the only ag feature holding me back from fully switching to ripgrep. :)

Since ripgrep already has something unrelated mapped to -g, the option name should be something else. The incompatibility with ag will be unfortunate, but survivable.

The text was updated successfully, but these errors were encountered:

BurntSushi · 2016-09-25T22:30:49Z

I'm pretty sure this has been reported at least several times now. :-) rg has --files for listing files and -g for glob matching.

Valloric · 2016-09-25T22:36:49Z

I'm pretty sure this has been reported at least several times now. :-)

Sorry about that! It might be indicative of a documentation "bug"; it seems people are having trouble locating this feature.

Valloric · 2016-09-25T22:40:43Z

Ah, I get it now. It's a combination of two flags: --files lists all the files that would have been searched and -g can be used to only search files matching a pattern.

This is very non-obvious. It requires users to fully understand two separate, unrelated options and to realize that when combined, they can be used to solve their problem.

Since ripgrep will have lots of users coming from ag who will expect a simple single-flag solution, it might be a good idea to have a single flag (much like ag) for this use-case, if for any reason, than to save you the headache of closing all these issue reports. :)

BurntSushi · 2016-09-25T22:51:28Z

I'd like to solve this with better documentation. It's clear this is an important feature to many, but it's decidedly subservient to ripgrep's primary focus, so I'd like to avoid adding extra flags for it.

gabrielmagno · 2016-09-29T16:16:22Z

That would be a great feature. But it is important to notice the differences.

Let's say I have this directory tree:

.
└── path
    └── to
        ├── file
        │   ├── pattern (file)
        │   └── pattern.txt (file)
        ├── pattern
        │   └── fileA.txt (file)
        └── patterns
            └── fileB.txt (file)

ag returns all the files that have "pattern" in any part of its path

$ ag -g "pattern"
path/to/pattern/fileA.txt
path/to/patterns/fileB.txt
path/to/file/pattern
path/to/file/pattern.txt

rg returns all the files that have "pattern" as its name

$ rg --files -g "pattern"
path/to/file/pattern

So, ideally, if such a feature is implemented in ripgrep to reproduce what The Silver Search does, it should check the path (not only the name) and also match any part of the string (not an exact match, not a glob).

BurntSushi · 2016-09-29T16:46:15Z

Remember that -g gives you the ability to use a glob, so if you want to match any component of the path, then **/pattern/** will work. (Well, to match pattern.txt and path/to/patterns, you will actually need **/pattern*/**.)

nateozem · 2016-12-27T04:56:40Z

In case somebody wouldn't know the syntax for doing a search with the condition of excluding files with a certain name using the command line, here is an example to do so:

$ rg "from_str" -g "\!tags" -g "repos/*"
                    ^^^

As shown, you may need to escape ! with \, if wish to exclude files from search.

BurntSushi · 2016-12-27T07:59:22Z

Or just use single quotes.

…

On Dec 26, 2016 11:56 PM, "nateozem" ***@***.***> wrote: In case somebody wouldn't know the syntax for doing a search with the condition of excluding files with a certain name using the command line, here is an example to do so: $ rg "from_str" -g "\!tags" -g "repos/*" ^^^ As shown, you may need to escape ! with \, if wish to exclude files from search. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAb34sr7aMsWRt2-EZ0DUTcu_0dCcxmwks5rMJqIgaJpZM4KGBgW> .

h5rdly · 2016-12-30T16:52:58Z

Are there search parameters for rg that would list any files that match pattern, but any folder that matches pattern will only appear by itself, aka not relisted with everything inside it?

Say, for 'python' I'd like to get -
c:/python27/
c:/python27/python.exe
c:/python27/pythonw.exe
c:/pdfs/pythonconf.pdf
.[more such stuff]
.

Is that possible directly, without parsing the output?

BurntSushi · 2016-12-30T16:55:13Z

No. ripgrep will never print directories, only file paths. ripgrep isn't a find replacement.

Note that there's enough of libripgrep done that you could write your own CLI tool in Rust fairly easily to do this. I would be happy to mentor that project.

blueyed · 2017-01-21T17:49:56Z

Note that --files also includes binary files (is this a bug?)
The help says:

Print each file that would be searched without actually performing the search.

So to replicate ag -g . I am using rg --files-with-matches . now.
A difference here is that rg does not include empty files like ag does, even when using '' or '.?' for the pattern.

BurntSushi · 2017-01-21T18:00:47Z

Note that --files also includes binary files (is this a bug?)

No. "binary" files isn't a fact one can know without actually searching the file contents.

So to replicate ag -g . I am using rg --files-with-matches .

Those aren't the same. ag -g . is like rg --files. rg --files-with-matches is like ag --files-with-matches.

A difference here is that rg does not include empty files like ag does, even when using '' or '.?' for the pattern.

Whether a file is empty or not has no impact on the output of --files. In an empty directory:

$ touch hi
$ rg --files
hi

blueyed · 2017-01-21T19:24:07Z

@BurntSushi
Thanks for your reply.
I got confused because I had a global .agignore file that excluded *.png, and thought that ag -g . would exclude binary files therefore already.

Whether a file is empty or not has no impact on the output of --files

I was referring to --files-with-matches here, which I think is better to exclude binary files (I am using rg here to list files for ctags).
I think it's good to not include empty files here, but still wonder if you could have a pattern that is always true, also for empty files (e.g. ^ or .?)?

BurntSushi · 2017-01-21T22:01:26Z

I was referring to --files-with-matches here, which I think is better to exclude binary files (I am using rg here to list files for ctags).

It does:

$ echo -e 'z\x00' > test
$ rg --files-with-matches z
$ rg --files-with-matches -a z
test

Please note that "binary" detection cannot possibly be perfect. It uses a simple heuristic: if there's a NUL byte, then the file is considered binary. This is what GNU grep does. (ripgrep does have a bug here, see #52.)

I think it's good to not include empty files here, but still wonder if you could have a pattern that is always true, also for empty files (e.g. ^ or .?)?

ripgrep is a line oriented searcher. If a file doesn't contain any lines, then there's nothing to match. What is your use case?

In the future, could you please open new issues for new bug reports/feature requests?

blueyed · 2017-01-21T22:19:56Z

I was referring to --files-with-matches here, which I think is better to exclude binary files (I am using rg here to list files for ctags).

It does:

And that is good.

ripgrep is a line oriented searcher. If a file doesn't contain any lines, then there's nothing to match.

I see, but somehow thought that ^ should be always true.

But grep -l '^' * behaves the same, it makes sense, and it is a good way to skip empty files (using ., which would work even when ^ would stand for "anything").

In the future, could you please open new issues for new bug reports/feature requests?

I get you, but it is still about mimicking ag -g (and ag -g . in particular), isn't it?

What is your use case?

(I am using rg here to list files for ctags).

I was using ag -g . | ctags --links=no -L- to generate tags for my dotfiles (a globally included tags file).

I've replaced it now with rg --files-with-matches --no-ignore-vcs . | ctags --links=no -L-.

BurntSushi · 2017-01-21T22:28:41Z

I get you, but it is still about mimicking ag -g (and ag -g . in particular), isn't it?

Definitely not. I think there is a lot of value in having a similar interface as other tools, but I've never added something to ripgrep just for the sake of mimicking another tool. :-)

In the future, please open new issues to discuss new features or bugs. This particular issue is closed and done with. If there's a problem, we should start a new discussion.

I've replaced it now with rg --files-with-matches --no-ignore-vcs . | ctags --links=no -L-.

Why does this require printing empty files? Surely you won't be able to jump to any symbol defined in an empty file. ;-)

blueyed · 2017-01-21T22:40:28Z

@BurntSushi
I do not want the empty files - it's a nice side effect of the mimicking / workaround though.

about mimicking ag -g (and ag -g . in particular), isn't it?

Definitely not. I think there is a lot of value in having a similar interface as other tools, but I've never added something to ripgrep just for the sake of mimicking another tool. :-)

Sure, but then this issue is still the place to come to when you want to simulate it - that's what I've meant.

All is fine from my side.. :)
Thanks!

BurntSushi · 2017-01-21T22:49:20Z

@blueyed I see, OK. I had a really hard time understanding what you were trying to say! Glad all is well.

blueyed · 2017-01-21T23:31:00Z

@BurntSushi
Thanks for a faster and bug-free (with regard to the .gitignore handling) replacement for ag!

Valloric · 2017-03-02T21:36:35Z

Seems like I misunderstood what -g did originally; it's for a glob match, not a regex match.

Given that, I can't say that rg --files -g 'pattern' is adequate. What I'd like to see as a user is a regex match on the filenames.

mcandre · 2017-08-16T19:59:12Z

Is there no combination of flags for ripgrep allowing users to constrain both the filename and the content simultaneously? I'd like to search for Makefile's with "$$" in them, for example. Currently working around this with find . -name Makefile -exec grep "\\$\\$" {} \;

BurntSushi · 2017-08-16T20:13:19Z

@mcandre What have you tried? If rg -F '$$' searches too much, then restrict it using exactly the techniques outlined above: rg -F '$$' -g Makefile.

mcandre · 2017-08-16T20:15:24Z

@BurntSushi Thanks for the tip, works like a charm!

I wonder why the ripgrep CLI parsing doesn't treat

rg -g Makefile '$$'

as

rg -g Makefile -F '$$'

Oh well, at least the latter works on my machine^TM.

okdana · 2017-08-16T20:20:42Z

Because $ is a regex meta-character used to match the end of the line; -F escapes all meta-characters so that they're treated literally, which is what you wanted in this case

Might be worth reviewing something like http://www.regular-expressions.info/quickstart.html

mcandre · 2017-08-23T16:31:43Z

@okdana Lol I totally forgot about that! Yeah, -F '$$' works on my machine, and I suppose '\$\$' would work as well.

rosshadden · 2017-09-19T14:59:41Z

@BurntSushi I apologize if you find these kinds of issues annoying, but clearly based on your comments in some of them you understand that a lot of us want this behavior. Your focus up to this point has been on showing that ripgrep already has the behavior, but I think you should heavily consider focusing on making it as easy as it is in ag, pt, and ack.

Using -g in all of those tools is not just a gimmick, it's incredibly useful. In fact I use it just about as much as I do the main functionality. A lot of projects like fzf, unite.vim, and denite.vim even officially recommend using this feature for getting lists of files, as -g '' is a really convenient and fast git-agnostic way to do git ls-files. In fact doing a search for " -g" on fzf's readme shows five occurrences of using ag -g in different ways.

To be clear I'm not proposing you make it -g. But please consider adding a flag that does the equivalent. It will shut all of us up and make us feel much better about jumping into using and loving ripgrep. Thanks!

BurntSushi · 2017-09-19T15:10:51Z

@rosshadden What are you actually asking for? The -g flag's behavior is already set and it isn't changing. Are you asking for a new flag that combines -g and --files? If so, just define an alias?

alias rgg="rg --files"

borekb · 2019-08-20T18:09:18Z

Thanks for the mention of fd! I cloned a repository somewhere on my disk and wanted to abuse ripgrep to find it; fd is the right tool for that as I need to list only directories.

WhyNotHugo · 2020-05-10T14:30:19Z

I'm trying to achieve what's been discussed on this thread, but it's not working for me, I'm not sure if I've misunderstood something, or if something's broken. Say I want to find files named vendor:

$ rg --files . -g vendor
$ rg --files vendor
vendor: No such file or directory (os error 2)
$ find . -iname vendor
./idf/core/static/www/js/vendor
./idf/core/static/www/css/vendor
./enviatufoto/static/www/js/vendor

What am I doing wrong? With ag, this is basically ag -g vendor, but I can't figure out how it works with rg.

BurntSushi · 2020-05-10T18:41:50Z

@WhyNotHugo The glob is applied to every path ripgrep traverses. Is vendor a directory? If so, vendor on its own won't match anything inside of vendor. Use rg --files -g '**/vendor/**' instead.

lamyergeier · 2020-06-29T00:42:28Z

@BurntSushi --files -g doesn't respect the contents of .gitignore

rg --files --type md -g "*Python*" "${PWD}"

BurntSushi · 2020-06-29T00:45:03Z

Please file a new and complete big report. Your comment isn't actionable.

lamyergeier · 2020-06-29T01:02:40Z

I solved this as follows:

To search Python in filenames:

Search=Python
rg --files "${PWD}" | rg --regexp "${Search}[^/]*$" | sort | nl

jjjchens235 · 2020-10-06T22:07:32Z

piggybacking off of @anishmittal2020
This function returns any file name AND directory matches, though directories themselves cannot be returned, as the --file flag returns a list of files only, directory paths are excluded.

function f() {
	#find any files or directories that match arg
	rg --files "${PWD}" | rg --regexp ".*/.*$1.*" #| sort | nl
}

Put in .bashrc, and then call it on the command line.
If searching for filename or directory names that contain the word 'vendor':
f vendor

Taking @WhyNotHugo example:

./idf/core/static/www/js/vendor/bar.py
./idf/vendor.py
./idf/core/static/www/js/vendor/

The first two files will be returned, the first because the path contains a dir called vendor, and the second because it contains a filename with vendor. The last file is a dir, it will not be returned.

Edit: I hate to admit it, but I should have just used fd from the get-go. It allows for regex arguments, and user can specify if they want to search for files, directories, or both.

function f() {
	#list of flags: https://github.com/sharkdp/fd#command-line-options
	#optional flags should be passed in first, then PATTERN and PATH
	fd -H -a -p  "$@"
}

AtomicNess123 · 2021-02-07T09:07:39Z

I have read the whole thread. I have not successfully managed to just find all filenames containing "helm".
When I do:

rga ~/.emacs.d --files -g "*helm*"

I just finds filenames with detached "helm" (i.e., "xxx-helm-xxx.el"), but not "xxxhelmxxx.el".
How to specify this? Thanks!

BurntSushi · 2021-02-07T16:44:39Z

@AtomicNess123 Works just fine for me:

$ touch xxx-helm-xxx.el xxxhelmxxx.el
$ l
total 0
-rw-rw-r-- 1 andrew users 0 Feb  7 11:40 xxx-helm-xxx.el
-rw-rw-r-- 1 andrew users 0 Feb  7 11:40 xxxhelmxxx.el
$ rg --files -g '*helm*'
xxx-helm-xxx.el
xxxhelmxxx.el

AtomicNess123 · 2021-02-07T20:52:33Z

Thanks. Actually, it does work in your example.
But not when I do:

§ rg --files -g '*helm*' ~/.emacs.d

In this case, when I specify the folder to search within, it only finds the "xxx-helm-xxx.el" instances, and not the "xxxhelmxxx.el" ones.

BurntSushi · 2021-02-07T21:03:04Z

Also works just fine:

$ mkdir .emacs.d
$ touch .emacs.d/xxx-helm-xxx.el .emacs.d/xxxhelmxxx.el
$ rg --files -g '*helm*' .emacs.d/
.emacs.d/xxx-helm-xxx.el
.emacs.d/xxxhelmxxx.el

I can't think of a reason why it isn't working for you. Sorry. To be honest, it doesn't make sense to me why *helm* would match xxxhelmxxx but not xxx-helm-xxx. I suspect there is something else going awry. Please consider making a smaller reproduction.

AtomicNess123 · 2021-02-07T21:28:16Z

I won't work like this in my system.

rg --version  
ripgrep 12.1.1

What is your version?

BurntSushi · 2021-02-07T21:31:05Z

Same, but there aren't any recent changes that would impact this AFAIK. Please consider trying my exact set of commands in a fresh directory. Try running with the --debug flag. Paste its output and all the exact commands you're running.

AtomicNess123 · 2021-02-07T21:31:12Z

Other question: how many levels (subdirectories) will the command search?

BurntSushi · 2021-02-07T21:31:24Z

All...

AtomicNess123 · 2021-02-07T21:37:20Z

Then, it makes no sense. It works in your example. But I want to find any filename with "helm" in the name. If I search from root or any other folder, it only finds the files at the .emacs.d/modules and .emacs.d/other, but not in .emacs.d/elpa. It is very strange. But when I enter the elpa directory and run the command from there, it finds all the files.

AtomicNess123 · 2021-02-07T21:41:40Z

Ok... does .gitignore affect results? It seems elpa is in .gitignore!

BurntSushi · 2021-02-07T21:58:54Z

Of course. The first two sentences of the readme:

ripgrep is a line-oriented search tool that recursively searches your current directory for a regex pattern. By default, ripgrep will respect your .gitignore and automatically skip hidden files/directories and binary files.

This is why I suggested the --debug flag. It will tell you which things ripgrep skips and why.

AtomicNess123 · 2021-02-08T08:09:47Z

Yes, you were right. I'm just newbie in command line functions. I wonder if it's possible to override .gitignore setting?

BurntSushi · 2021-02-08T11:49:17Z

Sure. See the guide. If you have a specific question then open a new discussion post.

sergeevabc · 2021-05-02T12:02:25Z

Sorry to dig up this issue once again, but as a Windows user I believe workarounds provided earlier are not sterling, because alias rgg that combines --files -g part-of-filename is a Linux thing and fd utility to use instead of rg to search for filenames is still buggy to be relied upon. Yet this task arises daily (at least on my end), so I would vote with both hands for a short switch (to remember it easily and not to type long now imaginary --search-for-filenames). For example, -ff.

BurntSushi · 2021-05-02T12:23:59Z

Other software being buggy is not something I'm receptive towards as a motivation for adding more features to ripgrep.

AtomicNess123 · 2021-07-27T09:17:42Z

piggybacking off of @anishmittal2020
This function returns any file name AND directory matches, though directories themselves cannot be returned, as the --file flag returns a list of files only, directory paths are excluded.
function f() {
	#find any files or directories that match arg
	rg --files "${PWD}" | rg --regexp ".*/.*$1.*" #| sort | nl
}

Thanks for this. What is the meaning of "${PWD}"?

chris-w-jarvis · 2021-08-12T19:59:56Z

Whats wrong with doing rg --files | rg foo ?

This seems to work fine for me :)

foucist · 2022-03-23T20:26:33Z

Inspired by the earlier alias, I'm trying something like this. Function is named ag because old habits die hard 😅

function ag() { rg --files | rg ".*/.*$1.*" | sort | rg $1 }

mcandre · 2022-03-24T23:31:38Z

Appreciate the snippet! Good to know. One reason to bake this functionality into rg itself, is that sort may have different syntax on Windows. And any sorting is most efficiently done with appropriate data structures as early as possible (e.g., "online" algorithm), rather than after the fact.

…

On Wed, Mar 23, 2022, 3:26 PM James Robey ***@***.***> wrote: Inspired by the earlier alias, I'm trying something like this. Function is named ag because old habits die hard 😅 function ag() { rg --files | rg ".*/.*$1.*" | sort | rg $1 } — Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABJRGFSUSKJF77H426E3LVBN5AJANCNFSM4CQYDALA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

This makes it possible to preprocess query arguments on the fly. One use case (which is already implemented in this commit) is the transformation of `-Gpattern` to `--iglob=**/*pattern*/**`, which makes it possible to easily restrict rg searches to files containing `pattern` in the path. ag's -g flag probably will never be implemented in rg: BurntSushi/ripgrep#91.

PyKoch · 2024-05-23T10:58:16Z

In case somebody wouldn't know the syntax for doing a search with the condition of excluding files with a certain name using the command line, here is an example to do so:
$ rg "from_str" -g "\!tags" -g "repos/*"
                    ^^^
As shown, you may need to escape ! with \, if wish to exclude files from search.

Please excuse the newbie question here:
I am trying to search all pdf files and want to exclude those that contain 'ms' in the file name.
This is what I entered:
rg --type pdf -i "velocity" --sort-files -g '\!ms' -g '*paper_3*' >> test_p3_no_ms.txt
Sadly, there are still files with 'ms' in the title included. Any help would be greatly appreciated.

BurntSushi · 2024-05-23T11:52:02Z

@PyKoch Please don't ask questions in old unrelated issues. This issue is a feature request for some other feature.

And when you do ask questions, please include a reproduction. Here's how you do it: you include all relevant details so that others can see what you're seeing. This means providing inputs, showing the outputs you see and the outputs you want to see. Basically, it comes down to "show, don't tell." Here, I'll show you.

First create an empty directory with some files:

$ mkdir rg-search-issue
$ cd rg-search-issue
$ touch msfoo fooms ms quux

And now run rg --files to show that it correctly finds all of the files I created above:

$ rg --files
quux
ms
fooms
msfoo

And now my attempt at filtering:

$ rg --files -g '\!ms'
$

If you did that, then folks helping you wouldn't have to guess at your problem.

The first thing to realize here is that ripgrep isn't printing any files. This seems different from what you report where there are files being printed. Since you didn't share any details about your environment, and you provided a command more complex than necessary to demonstrate your specific issue with filtering out things that contain ms, I'm not sure what's going on.

In any case, there are two issues here. Assuming you're on Unix, the first issue is that you're escaping ! in a single quoted value. A comment above said that ! needed to be escaped, but that was in a double quoted string. The second issue is that the glob ms doesn't match AAmsAA. The glob ms only matches ms. You need a wildcard to match around it. You seemingly did this for *paper_3*... So just do it for ms:

$ rg --files -g '!ms'
quux
fooms
msfoo
$ rg --files -g '!*ms*'
quux

In the future, please don't ask questions in old issues. There's an entire discussion forum open for that purpose.

BurntSushi closed this as completed Sep 25, 2016

BurntSushi mentioned this issue Dec 21, 2016

[QUESTION/SUGGESTION] Does/should ripgrep support ag/ack's -g flag for searching filenames? #284

Closed

YPCrumble mentioned this issue Dec 21, 2016

Update docs to explain use of -g and --files to search for paths. #285

Merged

BurntSushi mentioned this issue Sep 28, 2022

Include/exclude searched files with implicit wildcard or regex (ag -G) #2314

Open

Searching filenames (-g option in ag) #91

Searching filenames (-g option in ag) #91

Comments

Valloric commented Sep 25, 2016 • edited Loading

BurntSushi commented Sep 25, 2016

Valloric commented Sep 25, 2016

Valloric commented Sep 25, 2016 • edited Loading

BurntSushi commented Sep 25, 2016

gabrielmagno commented Sep 29, 2016 • edited Loading

BurntSushi commented Sep 29, 2016 • edited Loading

nateozem commented Dec 27, 2016

BurntSushi commented Dec 27, 2016 via email

h5rdly commented Dec 30, 2016

BurntSushi commented Dec 30, 2016

blueyed commented Jan 21, 2017

BurntSushi commented Jan 21, 2017

blueyed commented Jan 21, 2017

BurntSushi commented Jan 21, 2017 • edited Loading

blueyed commented Jan 21, 2017

BurntSushi commented Jan 21, 2017

blueyed commented Jan 21, 2017

BurntSushi commented Jan 21, 2017

blueyed commented Jan 21, 2017

Valloric commented Mar 2, 2017

mcandre commented Aug 16, 2017 • edited Loading

BurntSushi commented Aug 16, 2017

mcandre commented Aug 16, 2017 • edited Loading

okdana commented Aug 16, 2017

mcandre commented Aug 23, 2017

rosshadden commented Sep 19, 2017

BurntSushi commented Sep 19, 2017

borekb commented Aug 20, 2019

WhyNotHugo commented May 10, 2020

BurntSushi commented May 10, 2020

lamyergeier commented Jun 29, 2020 • edited Loading

BurntSushi commented Jun 29, 2020 • edited Loading

lamyergeier commented Jun 29, 2020 • edited Loading

jjjchens235 commented Oct 6, 2020 • edited Loading

AtomicNess123 commented Feb 7, 2021 • edited Loading

BurntSushi commented Feb 7, 2021

AtomicNess123 commented Feb 7, 2021

BurntSushi commented Feb 7, 2021

AtomicNess123 commented Feb 7, 2021

BurntSushi commented Feb 7, 2021

AtomicNess123 commented Feb 7, 2021

BurntSushi commented Feb 7, 2021

AtomicNess123 commented Feb 7, 2021

AtomicNess123 commented Feb 7, 2021

BurntSushi commented Feb 7, 2021

AtomicNess123 commented Feb 8, 2021

BurntSushi commented Feb 8, 2021

sergeevabc commented May 2, 2021 • edited Loading

BurntSushi commented May 2, 2021

AtomicNess123 commented Jul 27, 2021

chris-w-jarvis commented Aug 12, 2021

foucist commented Mar 23, 2022

mcandre commented Mar 24, 2022 via email

PyKoch commented May 23, 2024

BurntSushi commented May 23, 2024

Searching filenames (`-g` option in `ag`) #91

Searching filenames (`-g` option in `ag`) #91

Valloric commented Sep 25, 2016 •

edited

Loading

Valloric commented Sep 25, 2016 •

edited

Loading

gabrielmagno commented Sep 29, 2016 •

edited

Loading

BurntSushi commented Sep 29, 2016 •

edited

Loading

BurntSushi commented Jan 21, 2017 •

edited

Loading

mcandre commented Aug 16, 2017 •

edited

Loading

mcandre commented Aug 16, 2017 •

edited

Loading

lamyergeier commented Jun 29, 2020 •

edited

Loading

BurntSushi commented Jun 29, 2020 •

edited

Loading

lamyergeier commented Jun 29, 2020 •

edited

Loading

jjjchens235 commented Oct 6, 2020 •

edited

Loading

AtomicNess123 commented Feb 7, 2021 •

edited

Loading

sergeevabc commented May 2, 2021 •

edited

Loading