And that can be fine! Or you might decide it as not worthwhile. To use the thing with "less" quirks you need to know _more_ quirks. This new thing has 3 /different/ quirks to perform the same task you already know. More quirks you have to learn is not less.
#RIPGREP COMMAND NOT FOUND FREE#
Feel free to abuse my competence or, you know, link it in the discussion? Actually I'll do it. I looked and didn't find it in the parent link. 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. Hyping anything at all in that context like that looks pretty bad.
#RIPGREP COMMAND NOT FOUND INSTALL#
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. And that is Great, really! We should all try and make things better! Hurrah! Ripgrep may well be a better grep for some users. I can imagine this could be compelling for uses I don't know about. A new user doesn't care about the obsolete.įaster? Well I have not yet experienced an issue with the speed of grep, that's my experience. To get this done like I always have I now need to know something new. 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. It's a massive pain and annoying as fudge. Regexes aren't de-facto standard grep is different to egrep to perl to python to C++ to your text editor to whatever. Moving to a different set of quirks is not a step forward than continuing to use the ones you know. Seems this comment was a bit subtle for some people. All other threads can then share the one single matcher.
Ripgrep does use multi-threading as well, and it makes sure every ignore file is parsed and built only once. 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. 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. And yes, you can splat them down into any directory, and if ripgrep enters that directory, it will read it and respect it. The things mentioned above are "ignore files," which are a sort of configuration for whitelisting and blacklisting files to search in a directory tree.
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. This isn't a perfect way to do things by any means, but it seems like a decent balance of concerns to me. 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). #2 is endemic to all package managers.īy 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). #3 is a problem to some degree on crates.io, my understanding is that they basically treat this as a human moderation problem. 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). 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):ġ.) The use of names as a speculative financial instrument (in all shades of grey, up to and including extortion for lapsed or stolen names)Ģ.) The use of names as vectors of attack, such as by exploiting typos or homographs (such as malicious packages)ģ.) The reserving of names you don't have a sincere or immediate intention to use (hoarding/FOMO)
0 kommentar(er)
