Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ripgrep 15.0

github.com

Post reply on HN
Print view View original

111–119 of 119 posts

Re: Ripgrep 15.0

#111

Post by account42 »

cormacrelf wrote: post #86
burntsushi wrote: post #50

Earlier quoted context omitted.

> My only complaint is there are a couple of characters that the -F (treat as literal) option seems to still treat as a special character needing some kind of escape - though I don't remember which ones now. If you have an example, I can try to explain for that specific case. But `-F/--fixed-strings` will 100% turn off any regex features in the pattern and instead will be treated as a simple literal. Where you might…

How about -F -regexthatlookslikeaflag? Verbatim, that errors out as the command line parsing tries to interpret it as a flag. If you don’t have -F, then you can escape the leading hyphen with a backslash in a single quoted string: '\-regex…', but then you don’t get fixed string search. And -F '\-regex…' is a fixed string search for “backslash hyphen r e g e x”. The only way is to manually escape the regex and not use…

The convention is use use -- to denote the end of options in command-line tools - anything after that is parsed as a normal argument even if it starts with a dash. If rg doesn't support that it should.

Re: Ripgrep 15.0

#112

Post by burntsushi »

account42 wrote: post #111
cormacrelf wrote: post #86

Earlier quoted context omitted.

How about -F -regexthatlookslikeaflag? Verbatim, that errors out as the command line parsing tries to interpret it as a flag. If you don’t have -F, then you can escape the leading hyphen with a backslash in a single quoted string: '\-regex…', but then you don’t get fixed string search. And -F '\-regex…' is a fixed string search for “backslash hyphen r e g e x”. The only way is to manually escape the regex and not use…

The convention is use use -- to denote the end of options in command-line tools - anything after that is parsed as a normal argument even if it starts with a dash. If rg doesn't support that it should.

It has since day 1. And you can use the `-e/--regexp` flag too, just like grep.

Re: Ripgrep 15.0

#113

Post by burntsushi »

sshine wrote: post #110
burntsushi wrote: post #93

Earlier quoted context omitted.

Whether smart case is enabled by default (as ag does) could easily go either way. Notably,.I think having it disabled by default is a better UX. But ripgrep does have a --smart-case flag, which you can add to an alias or a ripgrep config file. It also works more consistently than ag's smart case feature, which has bugs. See my other comments about perf difference. And ag has several very critical bugs. And it's unmai…

I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. Maybe there are similar directories that people prefer included by default. Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it.

> I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden.

As has been suggested elsewhere in this thread, have you considered `echo '!/.github/' > .ignore` in the root of your repository? That's what ripgrep's repo itself does: https://github.com/BurntSushi/ripgrep/blob/d47663b1b4548e4fa...

There have been some requests to whitelist certain directories by default. And it will absolutely never happen. It makes the semantics too complicated and even more surprising. Today, I can just say, "ripgrep respects gitignore, ignores hidden files and binary files." But if I started whitelisting specific things, that description would no longer be correct. I'd have to add them as exceptions when explaining ripgrep's default heuristics.

Plus, whitelisting a directory is extremely easy and simple. People seem to think `.ignore` files are only for ignoring. But they're not. They also let you un-ignore things without having to touch the CLI command.

> Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it.

I do use semver in ripgrep. That is, if I make a breaking change, then I bump the major version. Regardless, big breaking changes that aren't exceptionally well motivated are basically off the table. semver allows breaking changes to be made, but it works best in the context of libraries. For ripgrep, that has direct end users, semver doesn't really help much. Users will just experience their scripts breaking. Or commands they used to use, now don't work any more or do something different.

Re: Ripgrep 15.0

#114

Post by kccqzy »

burntsushi wrote: post #63
kccqzy wrote: post #62

I discovered and started using the silver searcher (ag) before ripgrep existed. I don't feel a strong need to switch for marginally faster search but with different command-line switches. Am I missing some killer feature here?

Fewer bugs? And perf depends on your haystack size. If you have lots of data to search, it's not hard to witness a 10x difference: https://news.ycombinator.com/item?id=45629904 As for features that ripgrep has that ag doesn't: * Much better Unicode support. (ag's is virtually non-existent.) * Pluggable preprocessors with --pre. * Jujutsu support. * ripgrep can automatically search UTF-16 data. * ripgrep has PCRE2 sup…

Thanks! I'm giving rg a try. Right now the only issue I'm facing is that rg's -g flag is less expressive than ag's -G flag. The latter allows specifying a regular expression for the file name to search in. The rg's version only uses globs. This means it's a bit more typing for common cases and a bit less flexible.

Re: Ripgrep 15.0

#115

Post by atonse »

restlake wrote: post #77
atonse wrote: post #51

rg is a tool that feels like magic. when in reality, like most things that feel like magic, it’s a result of exceptionally good engineering and dedication to improvement, and actually takes advantage of the incredible hardware we all use daily. It’s also smithing that’s unleashed the ability of agents to explore and reason about code faster than waiting for some sort of “lsp-like” standard we probably would’ve had to…

genuinely curious what smithing means in this context!

Sorry haha when I realized my typo it was too late and HN didn’t let me edit it. I hoped nobody would misread it.

Re: Ripgrep 15.0

#117

Post by rurban »

burntsushi wrote: post #101
rurban wrote: post #98

Earlier quoted context omitted.

But unicode support is still nuclear. In unicode you can write the same graphemes in many different ways. And if you go to non-unicode supported language specifics, like ue standing for ü, where the ü can be written in two different ways, with marks and directly, neither ripgrep nor ugrep will help find those substrings. Also the many Arabic subtleties, where there are not only mark combinations, but also more beauti…

Idk what "still nuclear" means. And yes, ripgrep doesn't do any kind of Unicode normalization. Few tools do. But that doesn't mean what I said was wrong. ripgrep has a whole host of Unicode features that ag doesn't have.

Nuclear is nuclear, not unclear.

Read https://www.unicode.org/reports/tr10/#Searching what unicode has to say about string search, in opposition of the usual byte search grep tools.

Re: Ripgrep 15.0

#118

Post by mlrtime »

burntsushi wrote: post #30
opan wrote: post #19

Earlier quoted context omitted.

This is pretty much flipped from my experience, so I'm curious if you could expand on this. I use grep a lot to filter command output or maybe search all my txt file notes at once when I can't remember which file contained something. I use rg rarely, one example in recent memory is searching the source code for the game Barony to try to find some lesser-known console commands or behaviors (like what all drops a parti…

`some-command | grep pattern` and `some-command | rg pattern` both work fine. You can chain `rg` commands in a shell pipeline just like you do `grep`. What the GP is suggesting is that their most common use case for grep is recursive search. That's what ripgrep does by default. With `grep`, you need the non-POSIX `-r` flag. The other bit that the GP didn't mention but is critical to ripgrep's default behavior is that…

Thank you for providing this tool to the community... I'm a old timer and haven't moved away from grep -R , grep -E, etc...

However one thing that I find annoying with grep more recently is grepping through fs with lots of container layers or files that are unreadable... easy enough to make a bash function for 'find . -type f -name | xargs grep'. Does rg solve these issues for you? Thanks!

Post reply on HN