Understanding the backlash parsing of ripgrep.

[DasOhmoff]

Hello, I am not really able to understand the ripgrep behaviour with backslashes.

For example, here I am trying to find lines that contain \:

As you can see, I seem to have to escape the backslashes inside the quotes.

After escaping the results are as follows:

So far so good, it is more or less understandable for me at the moment.

Now let me try to add the ) character for the search, just as you can see in the second line in the test.txt file in picture above. Here is what I type:

As you can see, he cannot find anything anymore, even though I only added \) at the end. Why can't he find anything anymore?

Even more confusing is the following:

I removed two backslashes from the string and now he finds \) and now he does not need \\ to be escaped to \\\\ anymore. Why?

If you compare these to searches you will notice what I mean:

One needs the backslash to be escaped to \\\\ and the other only needs it to be escaped to \\. Why?

Thank you very much for your help!
Best regards, Adam.

[BurntSushi]

As you can see, I seem to have to escape the backslashes inside the quotes.

It's because you have to escape the slash through two layers. The first is (presumably) your shell, where \\ needs to be used to express a \. The second is the regex language itself. Since \ is a special character, it needs to be escaped. Thus, you need to combine \\ twice to search a literal slash.

This is why almost all ripgrep examples involving this sort of thing use single quotes. On Unix, single quotes won't do any kind of interpolation and treat their contents literally. So you don't need to do any additional escaping. That is, on Unix, rg '\\' correctly searches for a \.

I'm not a Windows user, so I don't know what the equivalent syntax is. Does it have single quote syntax for literals?

You might also consider using the -F/--fixed-strings flag, which causes ripgrep to interpret the pattern as a literal string and not a regex. So rg -F '\' would search for a \. Presumably, in your environment, rg -F "\\" would do the same.

Given those rules, I would expect rg "\\)" to be the correct way to escape a ). Therefore, to search for \), you'd need \\\\\\) (that's four backslashes for the literal \, followed by two backslashes to escape the )). I note in your example that you have only five backslashes total, where as I think you would need six.

As for rg "\\\)" matching \), that is indeed interesting. To me that implies that Windows is perhaps doing interpolation in some cases and not others. In this case, it looks like it's treating the first two backslashes literally, which then makes it ways to the regex engine as a single literal \.

I think your possible solutions to make this more sensible are:

1. Find a way to provide literal arguments on Windows. Looking at this stackoverflow question though, that may be possible. This appears to be a giant pit on Windows.
2. Use the -F flag for cases where you just want to search a literal and don't need any regex features. This will remove one layer of escaping. Then all you'll need to do is handle whatever escaping Windows requires.
3. Use something other than Window's cmd shell. (Maybe WSL?)

Please keep in mind that I am not a Windows user. Most of what I'm saying here is mostly just guesswork based on your examples. Responses from more knowledgeable Windows users would be most welcome.

[DasOhmoff]

Thank you very much for you answer.
I can see that this is a complete mess, but unfortunately I have to work with windows and have no other option at the moment :/ .
I noticed some other things while working on this problem.
I posted my problem on stackoverflow, maybe someone will be able to help me out there.
Until then, I will have to wait for now.

[BurntSushi]

Looks like a good question! I'd be happy to attach a bounty to it. (I think I have to wait two days first though.)

[DasOhmoff]

Hey, I already got a response. Looks like this question was already answered here: https://stackoverflow.com/questions/9287812/backslash-and-quote-in-command-line-arguments . Looks like this is a complete mess but I will have to live with this unfortunately :/ . Well, nothing I can do about it. Anyway, thanks for having helped me to find the answer! I really appropriate it :)