HN Reader

Ripgrep has saved me so, so much time over the years. It's become an invaluable tool, something I install the moment I start up a new system. It's essential for navigating older codebases.

My only complaint is there are a couple of characters that the -F (treat as literal) option seems to still treat as a special character needing some kind of escape - though I don't remember which ones now.

Always glad to see it keep updating!

rg is a tool that feels like magic. when in reality, like most things that feel like magic, it’s a result of exceptionally good engineering and dedication to improvement, and actually takes advantage of the incredible hardware we all use daily.

It’s also smithing that’s unleashed the ability of agents to explore and reason about code faster than waiting for some sort of “lsp-like” standard we probably would’ve had to build instead over time.

the ripgrep codebase is ultimate “pour a drink, settle into your coziest chair, and read some high quality software” codebase. Just click around through it and marvel.

Just like fd, I actually enjoy using rg and like these new set of command line tools.

the one thing i'd love to see added is an "extension" flag, equivalent to -g but which treats the provided arg as an extension (so `rg -e c,h` instead of `rg -g '*.{c,h}'`). 99% of the time I use glob patterns it's to match on extension.

This week I wrote a small bash function that run ripgrep only on the files that are tracked by git:

    rgg() {
        readarray -d '' -t FILES < <(git ls-files -z)
        rg "${@}" "${FILES[@]}"
    }

It speeds up a lot on directories with many binary files and committed dot files. To search the dot files, -uu is needed, but that also tells ripgrep to search the binary files.

On repositories with hundreds of files, the git ls-files overhead a bit large.

Great tool, and incredibly easy to use. Started with it on Linux, and now use on 'doze too.

Probably the singular reason why I finally use regex as the first search option, rather than turning to it after bruting thru a search with standard wildcards.

ripgrep is one of the main reasons I got interested in rust. it worked so well, it piqued my interest that it was written in rust. many years later, very glad about that. been using `rg` daily since then as well!

I use ripgrep every single day of work. Whether it's in the command line or searching in vscode. Thanks burntsushi!

Every time I set up a new machine--work, personal, whatever--the first thing I do is set up my rust toolchain and the second is 'cargo install ripgrep'. I really enjoyed your talk at the Boston Rust meetup a few years back on finite state transducers. Thanks for these (among many more) contributions you've made both to software and my education as a programmer.

Recently, I found that the `—replace` option, and it’s quite nice. Along with `—type` and I felt like I missed out on nice features.

I’m happy reading releases notes more thoroughly to keep myself aware of new features.

Nice to see some better integration with jj!

rg is a first for me in that it's a CLI tool that an LLM taught me about -- it's a go-to tool for Claude and codex, and since I got most of my bash skills pre-dotcom-one-boom I'm historically just a grep user.

Anyway I'm trying to retrain the fingers these days, rg is super cool.

This is an aside, I was watching an oral history of Ken Thompson. I guess he was responsible for the naming of grep:

https://youtu.be/OmVHkL0IWk4

Has it caught up to ugrep in terms of backward compatibility and speed yet?

> Directories containing .jj are now treated as git repositories.

So glad to see this!

What is the right way to make ripgrep behave closer to `git grep`? Plain `rg` ignores files inside hidden folders like `.github`, `rg --hidden` will search `.github` but also search inside `.git`. I currently have this alias that I don't remember where I found: `rg --hidden --glob '!*/.git/*'`. Is there a better way?

I would prefer a solution that works from outside git repos, so no piping `git ls-files` into rg.

That's what I call quality software.

I discovered and started using the silver searcher (ag) before ripgrep existed. I don't feel a strong need to switch for marginally faster search but with different command-line switches. Am I missing some killer feature here?

I use ripgrep to search file listings from my collection of 500+ vintage Macintosh Magazine CD-ROMs (1 million files; 30 million unzipped. I'm no database programmer but I could get anywhere near the same ballpark of speed as ripgrep and regex is good enough for querying plain text files. https://news.ycombinator.com/item?id=43607153

Ive always found the silversearcher defaults (or perhaps -Q) to just work better. Any alias/config tips?

Amazing how much faster it tends to be than my indexed search in intellij.

If this wasn't written in Rust, would people care? I still use grep. Does that make me a bad person?

> new major version release that mostly has bug fixes, some minor performance improvements and minor new features.

It's sad that "bug fixes and performance improvements" has become a running joke as the explanation for software gavage, and this is even worse. "Fewer bugs and faster" is at least something most people want; "fewer bugs, faster, and random changes you didn't ask fork" is a lot less desirable.

For searching file contents, is there a way to start rg with no search string?

How does it compare to ack?