4 ms·
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-d
by vessenes 1y ago
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.
- sshine 1y agoI switched to `ack` in 2017 because it handles recursive searches better. I didn't bother switching to `ag` when it came around because of having to retrain. But eventually I did switch to `rg` because it just has so many conveniences. I even switched to `fd` recently instead of `find` because it's easier and less typing for common use-cases. I've been using the terminal since 1997, so I'm happy I can still learn new things and use improved commands.
- dotancohen 1y agoSell me on fd. I occasionally use find, mostly with the -name or -iname flags.
- rkomorn 1y agoIt feels nearly instant by comparison to find. That's been enough for me.
- lawn 1y agoYou don't have to type -name for the 1000th time.
- dotancohen 1y agoThanks. For other people, on Ubuntu install the `fd-find` package. The executable is named `fdfind` (no dash).
- ahartmetz 1y agoIn my case, I am still using ag because rg doesn't seem to be better enough to switch. What's the big deal with rg vs ag? I had a similar thing with bash vs zsh before I learned about oh-my-zsh. Nushell also seems attractive these days... the good stuff from PowerShell in a POSIX-like shell.
- burntsushi 1y agoripgrep is a lot faster (which you might only notice on larger haystacks), has many fewer bugs and is maintained.
- ahartmetz 1y agoag is plenty fast (gigabytes in a fraction of a second) for me - I'd switch in a heartbeat if that wasn't so. Any bugs, hm, I guess I just haven't run into them. Thanks for the reply though! I realize who replied here ;)
- burntsushi 1y agoLook at ag's issue tracker. There are some very critical bugs. You might be impacted by them and not even know it. As for perf, it's not hard to witness a 10x improvement that you'll actually feel. On my checkout of the Linux kernel: $ (time rg -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l real 0.114 user 0.547 sys 0.543 maxmem 29 MB faults 0 444 $ (time ag -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l real 0.949 user 6.618 sys 0.805 maxmem 65 MB faults 0 444 Or even basic queries can have a pretty big difference. In my checkout of the Chromium repository: $ (time rg Openbox) | wc -l real 0.296 user 1.349 sys 1.950 maxmem 71 MB faults 0 11 $ (time ag Openbox) | wc -l real 1.528 user 1.849 sys 8.285 maxmem 29 MB faults 0 11 Or even more basic. You might search a file that is "too big" for ag: $ time ag '^\w{42}$' full.txt ERR: Skipping full.txt: pcre_exec() can't handle files larger than 2147483647 bytes.
- 1y ago
- dotancohen 1y agoThrough I use rg to initiate searches, my muscle memory keeps using grep after pipes.
- kstrauser 1y agoHeh, I realized the same for myself the other day. I’ve been deliberately making myself go back and change it to rg to try to replace the muscle memory.
- WJW 1y agoHuh I hadn't even realized I did that. I think grep has the "filter in pipe" spot in my head while rg has the "search recursively in all files" spot.
- burntsushi 1y agoI did it too, even after I initially released ripgrep. At this point, I've mostly re-trained my muscle memory to use `rg` in pipelines. (Particularly because I was careful to make sure `rg` worked just like `grep` does in pipelines.) I also find that combining `-o/--only-matching` and `-r/--replace` has replaced many of my uses of `sed` and `awk`.