Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: slash vs backslash in matched filenames #275

Closed
ljantzen opened this issue Dec 8, 2016 · 12 comments
Closed

Windows: slash vs backslash in matched filenames #275

ljantzen opened this issue Dec 8, 2016 · 12 comments
Labels
question An issue that is lacking clarity on one or more points.

Comments

@ljantzen
Copy link

ljantzen commented Dec 8, 2016

I'm on 0.2.3.

I am using rg in git-bash shell on a win10 box. It works, but the filenames /directories it outputs follows the windows/dos standard, using the backslash character as directory separator. This makes it difficult to copy/paste the filename into other commands in the bash shell.

I could do something like

 rg -l SearchPattern | sed -e 's/\\/\//g'

but that loses the coloured output and context.

Is there a way to tell rg that I want slash as directory separator character?

@BurntSushi
Copy link
Owner

I doubt it. It shows paths as they are supposed to be shown for your particular platform. Why doesn't your Bash shell handle Windows paths?

@BurntSushi BurntSushi added the question An issue that is lacking clarity on one or more points. label Dec 8, 2016
@BurntSushi
Copy link
Owner

It's not clear to me what specific problem the OP is facing here and whether ripgrep is the one to blame. If there's more clarity that can be provided, please feel free to re-open!

@ljantzen
Copy link
Author

I agree that running bash on windows perhaps isn't the most common use-case, but it is pretty common at least around where I am ( .net appl dev using git ). I have installed msysgit, which is the most common git command line client on windows. It provides a pretty standard bash shell, where I can access the usual bash/unixy commands and run shell scripts. As a former unix/linux based developer converting to .net I find that is a tremendous productivity benefit. I live in bash, even when I'm on windows.

I was really excited when I found ripgrep. As a unix junkie, I find it really hits the sweet spot. It even works on windows on the command line. Yeah! Bash? No problem, it rips through the source code in no time. When ripgrep finds something interesting, I usually want to open the file to edit or take a closer look. But, bash uses forward slashes, whereas dos/windows uses backslash as the directory separator character. In bash the backslash is the escape character, and requires special handling. '\t' is the tab character. So now I need to copy and paste the direcory/filename and manually replace the backslashes with slashes before I can open the file in vim or whatever.

Cutting and pasting a standard windows directory name into a bash shell simply does not work as you would hope. Is that a missing feature of bash? I could argue that with the bash/unix maintainers, but I doubt I would make much headway in that discussion.

I would really appreciate a '-XUseUnixDirsep' option or something similar to force ripgrep to ouput src/test/apptest.cs instead of src\test\apptest.cs. Would you accept a pull request to that effect?

@BurntSushi
Copy link
Owner

Is ripgrep really the only tool with this problem? How do you deal with other tools that output paths using the separator defined by your platform?

I would really appreciate a '-XUseUnixDirsep' option or something similar to force ripgrep to ouput src/test/apptest.cs instead of src\test\apptest.cs. Would you accept a pull request to that effect?

Possibly... But it would have to be easy to maintain and not (measurably) impact the performance of ripgrep when used without the option enabled. (A branch in the code is fine, but an unconditional search-and-replace-and-allocate is not.) My guess is that the easiest place to implement this is in the printer. And if you're going to do it, you might as well permit the user to specify the path separator.

@BurntSushi BurntSushi reopened this Dec 12, 2016
@cormacrelf
Copy link

cormacrelf commented Dec 23, 2016

Is ripgrep really the only tool with this problem? How do you deal with other tools that output paths using the separator defined by your platform?

I use git-bash when I'm on Windows 10. I almost never use any tools that output or even accept backslashes, I just have most of the UNIX standard tools and use them as a total replacement for cmd. Ripgrep is the only tool I use day-to-day which doesn't prefer UNIX paths, and currently I just revert to grep -rl when I need to use paths. I would appreciate a flag that I can alias rg="rg --pathsep '/'" or similar.

@cormacrelf
Copy link

Thanks! Much appreciated.

@ljantzen
Copy link
Author

Yay! Thank you 👍

@ljantzen
Copy link
Author

As a follow-up note, I found this to be working, although in a slightly surprising fashion.

a.txt
1:XXX=1

subdir\b.txt
1:XXX=2
/c/dev/tmp/rg$ rg --path-separator % -i xxx
a.txt
1:XXX=1

subdir%b.txt
1:XXX=2
/c/dev/tmp/rg$ rg --path-separator \\ -i xxx
a.txt
1:XXX=1

subdir\b.txt
1:XXX=2
/c/dev/tmp/rg$ rg --path-separator ! -i xxx
a.txt
1:XXX=1

subdir!b.txt
1:XXX=2
/c/dev/tmp/rg$ rg --path-separator / -i xxx
A path separator must be exactly one byte, but the given separator is 16 bytes.
/c/dev/tmp/rg$ rg --path-separator \/ -i xxx
A path separator must be exactly one byte, but the given separator is 16 bytes.
/c/dev/tmp/rg$ rg --path-separator // -i xxx
a.txt
1:XXX=1

subdir/b.txt
1:XXX=2

@BurntSushi
Copy link
Owner

@ljantzen My guess is that it's unrelated to ripgrep. Are you in cygwin? Are you sure cygwin isn't trying to do some fancy path translation on / that's causing it to expand to something else?

@ljantzen
Copy link
Author

I agree, it probably is unrelated to ripgrep. I am using the bash shell that comes installed with git, 'Git Bash'. I just wanted to document this for others who might stumble on this as well. Thanks for an awesome tool 😄

@BatmanAoD
Copy link

Yeah, this definitely looks like a piece of Git-Bash "magic". Adding the sep argument itself to the error message, I get:

$> rg.exe --path-separator / 'pattern'
A path separator must be exactly one byte, but the given separator `C:/Program Files/Git/` is 21 bytes.

...which is...just awesome. 🙄

Anyway, // works great. Thanks!

@cha5on
Copy link

cha5on commented Jul 29, 2024

In case anyone else using bazel + git bash (msys) happens to stumble across this issue and is wondering why it doesn't work...

$ rg --path-separator // 'pattern'
A path separator must be exactly one byte, but the given separator is 2 bytes: //
In some shells on Windows '/' is automatically expanded. Use '//' instead.

...it's likely that you put export MSYS2_ARG_CONV_EXCL="//" or similar in your bashrc to avoid it getting turned into / when working with bazel. Here's an alias that unsets that and will work:

alias rg='MSYS2_ARG_CONV_EXCL="" rg --path-separator //'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question An issue that is lacking clarity on one or more points.
Projects
None yet
Development

No branches or pull requests

5 participants