181–190 of 198 posts
Earlier quoted context omitted.
As I have overloaded my rg with a customized rg alias, I can't pipe multiple rg calls. Otherwise it would look like this: # rg nokogiri | rg linux :11:Gemfile.lock:647: nokogiri (1.15.5-x86_64-linux) But that is a me problem. The workaround is of course just to pipe into grep instead.
Or `\rg`, which will use the command directly and skip your alias.
Still losing the coloring but you can't have everything.
I switched from from ripgrep to ugrep and never looked back. It's just as fast, but also comes with fuzzy matching (which is super useful), a TUI (useful for code reviews), and can also search in PDFs, archives, etc. The optional Google search syntax also very convenient. https://ugrep.com
Earlier quoted context omitted.
I find the built-in commands rough. "curl https://jrock.us " to see if my website is up used to involve opening Internet Explorer to accept some sort of agreement. Now it just flashes the terminal, moves the cursor to the far right hand side of the screen, and blinks for a while. I like the Linux version of curl better...
Ironically, windows 10+ comes with real curl installed, to use it type curl.exe instead
As it turns out, the reason that "curl ..." doesn't work is because it pops up a window below all of my other windows saying that certificate revocation information is unavailable, and would I like to proceed. After that it does download my web page!
Semi off-topic, I've coded a ncurses-frontend to navigate and filter grep-like results which might be of interest to some of you: https://github.com/gquere/ngp2
What's interesting is that ripgrep now also powers VS Code search with a Node.js wrapper. https://www.npmjs.com/package/@vscode/ripgrep
...which is awesome if you can request/install VS Code but not ripgrep. You can find the rg binary in the VS installation (at least, I can on Windows at my place of employment).
Earlier quoted context omitted.
I don’t think there’s been a point to using `git grep` since ack started parsing gitignore. As far as I’m concerned the use case of `git grep` is to search into non-checked-out trees (by giving it a tree-ish). And it’s not super great at that, because it searches a static tree-ish, so pickaxe filters are generally more useful (though they’re slow). Once again mercurial has/had more useful defaults, `hg grep` searches…
Small clarification: ack did not and does not respect your gitignore files. I just tried it myself, and indeed it doesn't. And this is consistent with the feature chart maintained by the author of ack: https://beyondgrep.com/feature-comparison/ One practical result of this is that it will mean `ack` will be quite slow when searching typical checkouts of Node.js or Rust projects, because it won't automatically ignore…
I can't think of a single time I've used grep where I thought "I wish this was faster".
Even if the answer is instant, you have a 50% performance improvement in your search just from typing "rg" instead of "grep"! From my perspective it's a no brainer. I don't HAVE a grep (because I don't have a Unix) so when I install a grep, any grep, reaching for rg is natural. It's modern and maintained. I have no scripts anywhere that might expect grep to be called "grep". Of course if you already have a grep (e.g.…
I imagine a lot of devs have grep preinstalled. In fact, where is grep not installed, now that WSL exists?
And this may still be true in 2023, but the problem is that most of the parallelized grep replacements (e.g. ripgrep, ag, etc.) are SO much faster than grep that the much small speed differences between them doesn't provide much of a basis for differentiating them. I use ag (typically from inside Emacs) on a 900k LOC codebase and it is effectively instantaneous (on a 16 core Ryzen Threadripper 2950X). I just don't ha…