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
Possible path-separator issues on windows when invoked from git-bash #1278
Comments
Please show the output with You might also try using the |
@BurntSushi thanks for the reply. (I think Here's debug; I'll attach the .gitignore too. One thing I notice -- and I don't know what I'm looking for sorry -- is that there's no message about turning a glob into a regex for either jfm or dbmdl.
|
.gitignore:
|
I missed this initially. Could you unpack this a bit more? What is the behavioral difference between git-bash and cmd/powershell in this case? |
Aah, sorry -- git-bash is mingw64, so a bash-shell on windows (with all the path-sep differences that can entail) The difference is that on git-bash the two locked files are accessed, causing a soft error, and an exit status of 2. On cmd/powershell the files are ignored as expected. (oh, I've just re-read my "not a problem" statement by the way: that's because I can still scroll through the expected output, and a couple of "could not access" messages aren't an issue. It was on Emacs that I first discovered this, because helm-ag checks for a "success" status, so there it's a problem because it won't display any results. That might not have been too clear, sorry) |
I see. So just to be clear, this sounds like a bug in helm-ag. Aside from whether or not ripgrep should be tripping over the files in this specific example, it doesn't make sense to me that a text editor plugin would completely hide all results if just one error occurs. ripgrep obviously doesn't do that, so text editor plugins that aim to support ripgrep shouldn't either. If helm-ag started out with ag, then that might explain things, since I doubt ag gets its exit status codes correct. But still, this is helm-ag's problem.
Okay. This is definitely the most interesting part of this bug report. I see now why you're talking about path separators now. Let's try to be good detectives and forget about possible answers, and first just follow the evidence. Assuming the debug output above was from git-bash, I think the next bit of information should be to show the debug output when in cmd/powershell. Please make sure to show the command your are running. :) Thanks for your patience in helping me debug this! |
No, thanks for your patience and responsiveness! And yeah, as I said initially, it's a fairly specific set of circumstances. I can patch helm-ag to check for exit status of 0 or 2, and run with Here's the output from powershell;
|
I think I'm personally stumped on what's causing this without being able to reproduce it myself. Do you know of an easier way to reproduce this issue without needing to setup a Visual Studio project? Basically, it doesn't make sense to me that git bash would result in a file access error, but cmd/PowerShell wouldn't. My mental model says that the shell environment shouldn't have anything to do with how ignore rules are processed or how files are accessed. But that appears to be wrong? Not sure. |
Ok, I did a quick bit of testing (I'm not a windows-native sorry!); powershell can be used to easily lock a file: $file = [System.io.File]::Open('c:\path\to\file', 'Open', 'Read', 'None')
# to release when finished:
# $file.Close() I'll see if I can put together a simple test gist or something. (The other thing at the back of my mind is why the same thing happens from within Emacs, which off the top of my head suggests it might be something to do with environment settings... actually, it does still use "/" as path-separator even on windows, so that's probably consistent with that theory) |
Thanks. If you can manage to get a concise reproduction, then I'll definitely investigate further.
Same. It's the blind leading the blind. :-) |
Ok, here we go: https://gist.github.com/markhepburn/e138c1954a6a7e78be41c5101f1a8bfe So, clone that and then you can run
With debug output:
|
(In case it didn't get mentioned / wasn't obvious, "git-bash" is the bash prompt that ships with the standard git-for-windows distro: https://gitforwindows.org/ It's using mingw64 I believe) |
What version of ripgrep are you using?
ripgrep 11.0.0 (rev d7f57d9)
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)
How did you install ripgrep?
Github binary release.
What operating system are you using ripgrep on?
Windows 10 (1809)
Describe your question, feature request, or bug.
My root problem is that rg is encountering errors on files locked by Visual Studio, yet ignored in .gitignore, and thus returning an exit status of 2. My motivation even noticing this is I'm using it through Emacs where helm-ag checks for an exit-status of 0; git-bash has the same behaviour although it's not really a problem there. Cmd and powershell work as expected.
So I am assuming it is to do with path-handling, although the Emacs case surprises me as I expected that to be "native" (\ as a separator).
If this is a bug, what are the steps to reproduce the behavior?
I have a Visual Studio solution, including a sqlproject. The SQL project contains files called schema.jfm and schema.dbmdl. With the solution open in Visual Studio, those files are apparently locked.
.gitignore (at the project root) contains
git check-ignore
confirms that both should be ignored.If this is a bug, what is the actual behavior?
From git-bash, I get the following output (note, --quiet is just to show the issue):
The same issue occurs if run from the RDSS.Schema containing directory.
I have also tried using both
--path-separator "//"
and--path-separator "\\"
which seem to have no effect (although embarrassingly I only found those options and related issues as I was about to submit :))If this is a bug, what is the expected behavior?
Arguably it isn't even a bug; it's inconvenient, but I appreciate it's a corner case. I haven't tried to determine how rg handles ignoring, and if its even its fault or whether git itself is invoked, etc.
The text was updated successfully, but these errors were encountered: