Live data from Hacker News

“You meant to install ripgrep”

crates.io

151–160 of 165 posts

Re: “You meant to install ripgrep”

#151
Hi - author of `rg` here :'). I've transferred over to BurntSushi which will give people a bit more assurance that `rg` won't become malware in the future.

I also squatted `memap` and `memap2` for the same reasons.

I wonder if there is an algorithmic way to decide when two crate names are 'near' each other. Then, if you added a crate with `cargo add` and there is another similarly-named crate with much higher usage, a warning could be emitted.

*EDIT* I know there's already https://en.wikipedia.org/wiki/Levenshtein_distance, but I wonder if there is a better measure that looks at e.g. keyboard layouts and likely typos. I'm sure there will have been research done on this.

Re: “You meant to install ripgrep”

#152

It would be nice if crates supported being signed with GPG or minisign or whatever. I can imagine for example, importing keys from only the authors that I think I can trust, and passing a flag to cargo that only allows using those packages for cargo install or cargo add. In this case I think just checking the top level crates signature (and not dependencies) would be enough to mitigate a lot of issues including typo…

'cargo crev' makes this kind of workflow possible: https://github.com/crev-dev/cargo-crev

Can't recommend `cargo crev` enough!!! The more people use it, the more powerful it becomes.

Re: “You meant to install ripgrep”

#153

Hi - author of `rg` here :'). I've transferred over to BurntSushi which will give people a bit more assurance that `rg` won't become malware in the future. I also squatted `memap` and `memap2` for the same reasons. I wonder if there is an algorithmic way to decide when two crate names are 'near' each other. Then, if you added a crate with `cargo add` and there is another similarly-named crate with much higher usage,…

Thank you! I've updated the crate to use dtolnay's suggestion (a compilation error), added a short README and created a repo for it with a small FAQ: https://github.com/BurntSushi/rg-cratesio-typosquat

Re: “You meant to install ripgrep”

#154
post #73

Earlier quoted context omitted.

I love that ripgrep honors .gitignore, but the fact that it skips hidden files is annoying because of questionable decisions from tool makers who insist their configuration files should be hidden files. It is especially infuriating when working with GitHub and GitLab configuration directories. On the other hand I never want ripgrep to enter the .git directory. I recently came up with this alias to make ripgrep do wha…

Yeah that alias is a good one, here are some other avenues: * The repo can add a `.ignore` or a `.rgignore` whitelisting things like `.github`. ripgrep will pick up that whitelist automatically and search `.github` even though it's hidden. But this relies on the repo adding ripgrep-specific config files, which is maybe not so realistic. (Or not universal enough to rely upon.) But it could work fine for repos under yo…

If I'm understanding this correctly, ripgrep parses multiple possible configuration files and is still one of the fastest tools I've ever used? That is amazing.

Re: “You meant to install ripgrep”

#155
post #154

Earlier quoted context omitted.

Yeah that alias is a good one, here are some other avenues: * The repo can add a `.ignore` or a `.rgignore` whitelisting things like `.github`. ripgrep will pick up that whitelist automatically and search `.github` even though it's hidden. But this relies on the repo adding ripgrep-specific config files, which is maybe not so realistic. (Or not universal enough to rely upon.) But it could work fine for repos under yo…

If I'm understanding this correctly, ripgrep parses multiple possible configuration files and is still one of the fastest tools I've ever used? That is amazing.

TL;DR - yes. :-)

There is a ripgrep "config file" (not mentioned in my previous comment), but there is only one and you have to set it via RIPGREP_CONFIG_PATH.

The things mentioned above are "ignore files," which are a sort of configuration for whitelisting and blacklisting files to search in a directory tree. And yes, you can splat them down into any directory, and if ripgrep enters that directory, it will read it and respect it. (Unless you tell it not to.)

If there are a lot of files with a lot of patterns, indeed, that can wind up taking a chunk of time not only building the matchers for each config file, but for actually matching them against every path. Sometimes it takes longer than not ignoring files at all! But if your ignore files are permitting ripgrep to skip GBs of data that GNU grep wouldn't otherwise skip, well, that's going to be a huge win no matter how you slice it.

ripgrep does use multi-threading as well, and it makes sure every ignore file is parsed and built only once. All other threads can then share the one single matcher.

Re: “You meant to install ripgrep”

#157
post #110

Earlier quoted context omitted.

For malicious intents, yes. But, for legitimate reasons where you need to have an "rg" package with a completely different use case, owner namespaced packages might provide a uniform solution.

Again, I was only commenting on typo-squatting. Namespaces do absolutely nothing to mitigate the typo-squatting problem.

Got it. You're right.

Re: “You meant to install ripgrep”

#158
post #55
post #53

What is ripgrep? Edit: Because I'm on a Zoom call that will never end. "ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files." https://github.com/BurntSushi/ripgrep

A file searcher akin to grep, ack, or ag (aka the silver searcher) it's programmed in Rust so it is decently fast with good support for UTF-8. Unfortunately it defaults to parsing a git tree's gitignore file and skipping over files listed in it.

> Unfortunately it defaults to parsing a git tree's gitignore file and skipping over files listed in it.

That's a feature.

Like, it's the entire point of ripgrep. It's designed to search through the things a developer actually cares about searching through.

If you actually want to search everything, just use grep.

Re: “You meant to install ripgrep”

#159
post #146
post #145

Earlier quoted context omitted.

yeah but with less quirks and runs much faster. worth trying out

Uses regexes = has quirks.

Seems this comment was a bit subtle for some people.

Moving to a different set of quirks is not a step forward than continuing to use the ones you know. Regexes aren't de-facto standard; grep is different to egrep to perl to python to C++ to your text editor to whatever. It's a massive pain and annoying as fudge. You're a programmer you know this. A "superior" set of quirks may be better for new regex users but it is worse for everyone else who now has to know both grep (and all the other regex quirks) and ripgrep if they're going to use it. To get this done like I always have I now need to know something new. A new user doesn't care about the obsolete.

Faster? Well I have not yet experienced an issue with the speed of grep, that's my experience. I can imagine this could be compelling for uses I don't know about.

ripgrep may well be a better grep for some users. And that is Great, really! We should all try and make things better! Hurrah!

Refusing to describe how it is different and why you might like to install something non-standard (for which there could be compelling reasons) is just silly. Hyping anything at all in that context like that looks pretty bad.

The ratio of content-free hype (omg ripgrep is fantistic!) to an actual description on this thread or in the link or seemingly anywhere I clicked is pretty bad and constitutes a signal.

Re: “You meant to install ripgrep”

#160
post #159
post #146

Earlier quoted context omitted.

Uses regexes = has quirks.

Seems this comment was a bit subtle for some people. Moving to a different set of quirks is not a step forward than continuing to use the ones you know. Regexes aren't de-facto standard; grep is different to egrep to perl to python to C++ to your text editor to whatever. It's a massive pain and annoying as fudge. You're a programmer you know this. A "superior" set of quirks may be better for new regex users but it is…

It sounds like you looked everywhere except for ripgrep's README. It explains upsides and downsides. Has benchmarks (with links to more, including cases where grep takes minutes and ripgrep takes seconds). It also has a link to a FAQ addressing whether ripgrep can replace grep and explains a bit more context.

More to the point, the comment you were responding to said "yeah but with less quirks." It didn't say "no" quirks. So your comment ended up being a silly non-sequitur.

Your follow-up comment looks ever worse to be honest, and sounds like an argument for never building anything different at all.

And half your comment is whinging about hype. Really? Yeah people get excited about shit that helps them get stuff done more pleasantly and faster than before. Who would have thunk it. Some great mystery.

Your comments get a big thumbs down from me (author of ripgrep).

Post reply on HN