Please check screenshot(attached  ) and let me know what could be issue responsible for this behaviour.
Ask me if still not clear.
The messages are from the `grep` command shown in blue at the top of the window. Try running it at the command line after `cd`ing to the directory indicated.
Running the same grep binary from the command line produces the same warnings.
After reading http://mingw-users.1079350.n2.nabble.com/Building-GREP-td7582694.html and http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16444 it seems to be a grep issue which is unlikely to be fixed (according to #16444).
We could apply http://download.geany.org/snapshots/grep-2.25-win64_sameinode.patch which eliminates the warnings. This patch is from the first link. For testing, I just build grep-2.25 with the mentioned patch, the binary is at http://download.geany.org/snapshots/grep-2.25_sameinode_patch.exe (rename to grep.exe and copy it into bin/ in your Geany installation directory).
@ All: do we want to patch our self-compiled grep binary? The warnings are just warnings, i.e. grep still finds the desired results. Still the warnings can be quite annoying.
I just noticed my previous tests were wrong: the warnings are not just warnings, actually grep doesn't find matches in sub directories without the patch. With the patch, the warnings are gone and matches will be found properly.
So, we probably should apply it.
Hum… I don't know much about this, but it makes me wonder:
* I read in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16444 that *"in which a patch was installed that tries to work around some of the MinGW deficiency; unfortunately the patch broke a lot of things and was backed out. I'm not optimistic about a fix this time either."* Does the patch proposed here exhibit these breakage, whatever it is? Or does it misses some stuff? * what happens when actually encountering directory loops? It's probably very rare, especially on Windows, but still, we probably better have some way out. Can we stop Grep from inside Geany? (I'm afraid not currently) * It's probably a question showing my ignorance in how we do Windows, but how comes this is new? How comes it used to work? And if it did, can't we simply do like we used to? (I don't know, compiling on native Windows, or MSYS2, or whatever)
I'm not against a patch, I'm just trying to get the whole picture :)
- I read in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16444 that *"in which a patch was installed that tries to work around some of the MinGW deficiency; unfortunately the patch broke a lot of things and was backed out. I'm not optimistic about a fix this time either."* Does the patch proposed here exhibit these breakage, whatever it is? Or does it misses some stuff?
To be honest, I don't know. Also I don't know what exact breakage the quote refers to. I assume, but it's really just a guess, there were problems with the patch in combination with support of other platforms or so. On the other hand, while the inode handling part of the patch is easy enough, I'm not completely sure what impact making the directory enter/leave functions NO-OPs has. It seems to work fine after quick testing but it might also introduce bigger issues.
- what happens when actually encountering directory loops? It's probably very rare, especially on Windows, but still, we probably better have some way out. Can we stop Grep from inside Geany? (I'm afraid not currently)
Sorry, I wasn't clear enough about the real issue: it's not only the warning which shows up, grep actually doesn't find any matches in sub directories if `--recurse` is used. I just updated the commit message in the PR to reflect this. And yes, we cannot stop grep in case it ran into a real directory loop. But this is independent from the patch, as directory loop detection based on inodes simply doesn't work on Windows, or at the very least not with Mingw. To say it clearly, if there is a directory loop, the patched version will most probably run into it and loop forever. I don't know if this is possible at all and how, but I guess there is a risk. Without the patch, `--recurse` is unusable.
- It's probably a question showing my ignorance in how we do Windows, but how comes this is new? How comes it used to work? And if it did, can't we simply do like we used to? (I don't know, compiling on native Windows, or MSYS2, or whatever)
Before we distributed an older version of grep (from UnxUtils, grep 2.5) which was either not affected by this issue because it didn't have the inode checks or was already patched/modified for Windows. We updated the distributed version of grep because of issues #789 and #560.
Okay. Well, if you think it's fine, let's do it and see what happens. Better for it to work in most cases than not.
I'm not too sure if it is fine. But also tend to use the patch as without `--recurse` is broken completely, with the patch it works but with the risk of running into loops.
I'd first would like to get some feedback from @VIVEKLUCKY1848 and then probably merge it.
In the longer term, it would be great to unify FiF search with the other searches and using the same regex engine/syntax instead of relying on a different external tool for the one search type. Writing a recursive directory enumeration and matching files is pretty easy with GLib/GIO and it could also fix the bug where the open (unsaved) documents aren't searched properly.
Closed #1229 via #1301.
This should be fixed now in Geany 1.29 (released today). We merged #1301 and the Windows installer has a `grep` version from the MSYS2 project bundled which seems to work fine with non-ASCII files and paths.
github-comments@lists.geany.org