You’ve saved me tens if not hundreds of hours with ripgrep, and I’ve become a huge evangelist of it at my workplace. When I’m helping someone understand how to debug customer issues, the first thing I tell them is to install ripgrep. Truly a fantastic piece of software.
Sorry, how does ripgrep save you tens of hours? I get that it is faster than regular grep, but that doesn't really answer the question; I don't find myself stalled waiting for grep. The only reasonable explanation would be something ripgrep does that grep actually doesn't. I could try to guess, but have no confidence I would guess right.
I use ripgrep on git bash for Windows, and my team members act like I’ve got searching superpowers. Searching on windows is such a pain and this makes it easy. Thanks so much for making this fantastic tool!
I use ripgrep and "everything" all the time on windows to find files and where I put stuff :) . My filing system leaves something to be desired, as does my many idea test folders.
`ripgrep` is my favorite of the "new" linux utilities, it makes searching for a single string across all of my cloned repos extremely easy, and especially for diving into multiple versions of vendored dependencies.
`ripgrep` is my favorite of the "new" linux utilities
Yeah, but only when used together with fzf, the other favorite new cross-platform shell utility. I mean, after rg spits out a list you do want to narrow it down and then do something with the files in that list, right?
You should not have done this unless you want to further normalize the practice of namespace squatting. This is the same type of behavior leads to domain squatting. While arguably being slightly more benign in the sense of hedging against typosquatting, if everyone started going things like that, we'd quickly begin to run into namespace exhaustion problems as people started ballooning their package namespace footprint.
Before you do something like that, always ask yourself: "What if everyone else started doing this?"
If the result feels like a nightmare in the making, don't do it.
> Before you do something like that, always ask yourself: "What if everyone else started doing this?"
No, I don't think so. There is no universality implied in my comment or in the specific practice here. You can make value judgments based on specific circumstances. For example:
* How many people try 'cargo install rg' and have it do the wrong thing? I'd say "probably a lot."
* Is 'rg' on its own something that is a likely useful or desirable name on its own? No, I don't think so.
This doesn't have to mean that everyone should do it for every possible alias of every crate out there. You can say things like "yeah I think it makes sense to squat a name here to improve failure modes for folks."
Other than that, I have squatted a few names before. I don't see anything wrong with the practice in and of itself. It's when it gets abused that it starts to become a problem.
I've worked on various package management ecosystems for close to a decade now, and I wouldn't qualify this (if 'burntsushi had done it) as namespace squatting. It's clearly not an attempt to reserve a name for unspecified future use (or as a potential typosquatting target); it's the name of the binary installed by the crate and an obvious mistake for an installing user to make.
Even flat namespaces are virtually infinite; a couple of extra names that correct user error do not pose a serious exhaustion risk.
I'd like to note there are three perverse incentives that lead to abuses of public namespaces (that I am aware of - please tell me if I've missed any):
1.) The use of names as a speculative financial instrument (in all shades of grey, up to and including extortion for lapsed or stolen names)
2.) The use of names as vectors of attack, such as by exploiting typos or homographs (such as malicious packages)
3.) The reserving of names you don't have a sincere or immediate intention to use (hoarding/FOMO)
This isn't very much like the situation with domains, which is primarily a result of #1 (there is no market for crates.io names, as far as I'm aware). #3 is a problem to some degree on crates.io, my understanding is that they basically treat this as a human moderation problem. #2 is endemic to all package managers.
By putting a helpful instead of malicious package here, the community (and Richard Dodd in particular) are able to mitigate the hazard of #2 (unless this account is compromised or turns malicious - a better but imperfect situation). If a project called `rg` comes around, they can appeal to moderators to get this name, and probably succeed (as if this were a #3 problem).
This isn't a perfect way to do things by any means, but it seems like a decent balance of concerns to me.
I'm fully in support of exhausting namespaces in programming languages. It's really annoying that people keep making one-off projects with weird names that reinvent the wheel.
In CPAN, you create a module with a hierarchical name (Net::LDAP), and people inherit from it and extend the namespace to add new functionality (Net::LDAP::Batch). Finding a package that does what you want is [relatively] easy. Old code gets maintained rather than somebody reinventing it for the 72nd time with a hodge-podge of functionality.
This classic version of this in the Ruby ecosystem is "bundle"[1], which helpfully installs `bundler` for you. Of the 6.7 million downloads it has, I'm probably in there a dozen or so times.
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.
If a package manager is starting from zero, and wants to have a privileged namespace such that a short name has a canonical value, it would make sense for those packages to be able to include a list of strings which the package should also reserve.
That way "ripgrep" could include "rg", searching cargo for "rg" brings back "ripgrep", not a second package named "rg", and an install could tell the user the correct name for any attempt to install it.
This also covers typo-squats, so there would be no need for packages like "memap".
Obviously this represents a low-effort vector for massive squatting, so maintainers would need to be responsible for preventing that, and could add some typos themselves, being the ones which see the request for the mis-typed packages.
I use fzf with an text file which lists all files installed by a package with the package name. That way if I know the header name, I can get the package name. If I know the package name, I can get all its files.
A friend of mine in college installed this on my laptop when I had my back turned. For a month or so, I wondered why anyone thought this feature was a good idea, and why no one I knew who used MacOS seemed to complain about it.
Huh - the same author also has https://crates.io/crates/memap and memap2, which explicitly say that they're "squatting to prevent a malicious typo package".
Not sure how to feel about this... on an individual-package level, it seems a sensible enough idea, but if it becomes a widespread practice, the namespace could get really cluttered.
(I'm the author of ripgrep.)
You’ve saved me tens if not hundreds of hours with ripgrep, and I’ve become a huge evangelist of it at my workplace. When I’m helping someone understand how to debug customer issues, the first thing I tell them is to install ripgrep. Truly a fantastic piece of software.
EDIT: Found their email via git. Always forget about that one.
Yeah, but only when used together with fzf, the other favorite new cross-platform shell utility. I mean, after rg spits out a list you do want to narrow it down and then do something with the files in that list, right?
https://github.com/junegunn/fzf/blob/master/ADVANCED.md#ripg...
Before you do something like that, always ask yourself: "What if everyone else started doing this?"
If the result feels like a nightmare in the making, don't do it.
No, I don't think so. There is no universality implied in my comment or in the specific practice here. You can make value judgments based on specific circumstances. For example:
* How many people try 'cargo install rg' and have it do the wrong thing? I'd say "probably a lot."
* Is 'rg' on its own something that is a likely useful or desirable name on its own? No, I don't think so.
This doesn't have to mean that everyone should do it for every possible alias of every crate out there. You can say things like "yeah I think it makes sense to squat a name here to improve failure modes for folks."
Other than that, I have squatted a few names before. I don't see anything wrong with the practice in and of itself. It's when it gets abused that it starts to become a problem.
Even flat namespaces are virtually infinite; a couple of extra names that correct user error do not pose a serious exhaustion risk.
1.) The use of names as a speculative financial instrument (in all shades of grey, up to and including extortion for lapsed or stolen names)
2.) The use of names as vectors of attack, such as by exploiting typos or homographs (such as malicious packages)
3.) The reserving of names you don't have a sincere or immediate intention to use (hoarding/FOMO)
This isn't very much like the situation with domains, which is primarily a result of #1 (there is no market for crates.io names, as far as I'm aware). #3 is a problem to some degree on crates.io, my understanding is that they basically treat this as a human moderation problem. #2 is endemic to all package managers.
By putting a helpful instead of malicious package here, the community (and Richard Dodd in particular) are able to mitigate the hazard of #2 (unless this account is compromised or turns malicious - a better but imperfect situation). If a project called `rg` comes around, they can appeal to moderators to get this name, and probably succeed (as if this were a #3 problem).
This isn't a perfect way to do things by any means, but it seems like a decent balance of concerns to me.
Seems fine to me. Something like one tenth of packages reserving a second name? Not a big deal.
In CPAN, you create a module with a hierarchical name (Net::LDAP), and people inherit from it and extend the namespace to add new functionality (Net::LDAP::Batch). Finding a package that does what you want is [relatively] easy. Old code gets maintained rather than somebody reinventing it for the 72nd time with a hodge-podge of functionality.
[1]: https://rubygems.org/gems/bundle
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.
That way "ripgrep" could include "rg", searching cargo for "rg" brings back "ripgrep", not a second package named "rg", and an install could tell the user the correct name for any attempt to install it.
This also covers typo-squats, so there would be no need for packages like "memap".
Obviously this represents a low-effort vector for massive squatting, so maintainers would need to be responsible for preventing that, and could add some typos themselves, being the ones which see the request for the mis-typed packages.
https://wiki.archlinux.org/title/PKGBUILD#provides
Deleted Comment
Not sure how to feel about this... on an individual-package level, it seems a sensible enough idea, but if it becomes a widespread practice, the namespace could get really cluttered.
Namespaces are a solution or mitigation to some problem, but that problem is not malicious typo-squatting.
Crates.io is incredibly cluttered with namesquatting. It’s probably the worst package registry for it, even surpassing NPM.
Part of the problem is that they explicitly say name squatting isn’t against the rules.
Deleted Comment
This installs a library by some authors not affiliated with AWS.
Instead of: `pip install awscli`
Which is what you expect.