Re: Rgrep not working on vim 64-bit, win7

[Ben Fritz]

On Monday, April 15, 2013 8:41:54 AM UTC-5, Darek wrote:
>
> I have did some debugging and looks like the error appears on the
> system() call in grep.vim:407. If I copy-n-paste system()'s argument to cmd.exe - it works as expected. Looks like there is a bug with the system() function on 64-bit Windows with 64-bit vim.
>
> Did anyone encountered such behavior?
>

As noted in your vim_use thread, I doubt very much that it's a bug in system(). More likely it's a problem with your system path or use of 32-bit calls in a 64-bit application. We can't debug the command unless you tell us what it is.

[Yegappan Lakshmanan]

Hi,

On Mon, Apr 15, 2013 at 6:41 AM, Darek <dgad...@gmail.com> wrote:
> Hi,
>
> This question has already been posted to vim_use list, but since I suspect this to be a bug in vim (or in Windows ;) ), this is probably a more appropriate place for it.
>
> I experience a strange problem with 64-bit vim/gvim on 64-bit Windows 7.
>
> When I use Rgrep on 32-bit vim build everything works perfectly fine:
> :Rgrep TODO *.cpp
> Quickfix opens with list of all my todos. The problem is when I use a
> 64-bit build of vim (I need it to have YouCompleteMe running):
> Error detected while processing function
> <SNR>61_RunGrepRecursive..<SNR>61_RunGrepCmd:
> line 1:
> E484: Can't open file C:\Users\<MyUser>\AppData\Local\Temp\VIo2E04.tmp
>
> The temporary file is not there, the location is accessible (since it
> works for 32-bit version). I have also tried to change temp location
> to:
> let $TMP='C:/tmp'
> but the result was always the same - the error.
>
> I have tried Haroogan's builds
> (https://bitbucket.org/Haroogan/64-bit-vim-builds-for-windows-64-bit/wiki/Home)
> and also compiled my own from hg a couple of hours ago with VS2012.
> Both have Rgrep unusable.

>
> I have did some debugging and looks like the error appears on the
> system() call in grep.vim:407. If I copy-n-paste system()'s argument to cmd.exe - it works as expected. Looks like there is a bug with the system() function on 64-bit Windows with 64-bit vim.
>
> Did anyone encountered such behavior?
>

This problem is caused by the shell command line quote escape
character in MS-Windows.
I have a fix for this issue. I will update the grep plugin and release
a new version.

- Yegappan

[Dariusz Gadomski]

Great! I would love to give it a try. Looking forward to trying your
fix, I will keep monitoring grep.vim page on vim.org. Thanks.

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Dariusz Gadomski]

Hi

On Mon, Apr 15, 2013 at 6:07 PM, Yegappan Lakshmanan
<yega...@gmail.com> wrote:
>
>

> This problem is caused by the shell command line quote escape
> character in MS-Windows.
> I have a fix for this issue. I will update the grep plugin and release
> a new version.
>
> - Yegappan

I was trying to analyze this problem further and what I found out that
actually vim calls something like this underneath:
cmd /c (C:\msys\bin\find.exe C:\dev\<my-project> -type d ( -name .SVN ) -prune
-o -type f ( -name *.cpp ) -exec c:\msys\bin\grep.exe -s -n -- TODO {} ;)

When I tried to paste it directly to cmd.exe I got:
-prune was unexpected at this time.
So no std output was generated and the process terminated with an error
on stderr - hence no tmp file created.
I think those brackets around cmd /c call conflict with brackets that make
a part of find call itself. When I replace the outer brackets with quotation
marks:
cmd /c "C:\msys\bin\find.exe C:\dev\<my-project> -type d ( -name .SVN )
-prune -o -type f ( -name *.cpp ) -exec c:\msys\bin\grep.exe -s -n --
TODO {} ;"
I get no error and expected output is printed.

So my guess is either:
- a different method is needed in the find call to group the conditions
(does find even allow a different way of grouping?) or
- inner brackets need somehow be escaped in the call or
- vim system() call needs to be fixed to handle brackets in the argument string.

Maybe is there another way to fix it or at least provide a temporary
work-around?

I would appreciate any hints that would enable me to use Rgrep until this
problem gets fixed.

Thanks!
Darek

[Ben Fritz]

There were several 7.3 patches in a row (I think in the 400s) handling default shell escaping in Windows. I don't see your Vim version in this thread, do you have those?

If so, what values do you have for the following options?

'shellxquote' (should usually be ( or "()
'shellquote' (should be empty)
'shellslash' (causes problems with shellescape() function when set)
'shellxescape' (should contain ( and ))
'shell' (should be cmd.exe or full path to it)
'shellcmdflag' (should be "/c" or "/c /s" or similar)

I remember parentheses being problematic, but I thought that problem was solved.

See http://vim.wikia.com/wiki/Execute_external_programs_asynchronously_under_Windows#Some_notes_on_cmd.exe_quoting which also has links to the vim_dev discussions on the patches.

If all your options look to be in order, you might be able to manually escape the () characters with '^' but I didn't think you needed to. You might also try "( instead of just ( as a shellxquote value. If neither of those work you can try " but I *know* that has problems in some common situations, which is why ( and "( were introduced.

[Yegappan Lakshmanan]

Hi,

The approach that works and used by the taglist plugin is to write the
command line
into a temporary .cmd file and execute it. The grep plugin also will use this
approach.

- Yegappan

[Yegappan Lakshmanan]

Hi,

On Tue, Apr 23, 2013 at 6:00 PM, Yegappan Lakshmanan

I have uploaded a new version of the grep plugin to the Vim online website.
You can try using the new version and let me know if you see any issues.

- Yegappan

[Dariusz Gadomski]

Hi

Great, the new version returns no error. Thanks!

However, the Quickfix list contains no filenames, only line numbers, so it's
impossible to jump directly from the quicklist to the place that grep found.
Is there a "-H" flag missing to grep or does the msys version of grep behave
differently?

I observe one more strange thing. If I run:
:Rgrep TODO
and give the directory to search and file extensions in subsequent prompts
it all works flawlessly, but if I run:
:Rgrep TODO *.cpp
the find command is expanded to:
(...) -type f ( -name -o -name *.cpp ) (...)
and returns no results. Providing more than one extension:
:Rgrep TODO *.cpp *.h
results with expanding to:
(...) -type f ( -name -o -name *.cpp -name *.h ) (...)
which still provides no results.

Is that behavior expected or is giving file extensions inline not supported?

Thanks,
Darek

[Dariusz Gadomski]

Hi

I have tried .761 and the yesterdays version from hg (reported as
.905). I guess the shellquote valeus are ok since the fix in new
grep.vim does the job.

Thanks,
Darek

[Ben Fritz]

It sounds like the issue is fixed for this plugin at least. But it sounded like Yegappan was going to bypass the shellquote settings entirely by writing to a script file and running it instead of running the command directly.

If you don't have any further problems it's certainly not worth fighting with Windows cmd.exe.

[Yegappan Lakshmanan]

Hi,

The problem in using the ":Rgrep <pattern> <filenames>" is fixed with the
latest version (1.11) of the Vim plugin.

- Yegappan

[lazureus]

Hi,
I'm encountering some similar problems as Dariusz have seen however on the 64-bit Ubuntu. Trying to run :Rgrep from VIM I get following error message :

Error detected while processing function

<SNR>19_RunGrepRecursive..<SNR>19_RunGrepCmd:
line 20:
E484: Can't open file /tmp/vAgZSwX/0

As I said I use 64-bit 13.10 Ubuntu with freshly cloned grep plugin from the :

https://github.com/yegappan/grep

Plugin is cloned into the bundle directory because I use pathogen plugin. I was wonder maybe you could help me with my problem, I'd really appreciate your help.

[John Beckett]

lazureus wrote:
> I'm encountering some similar problems as Dariusz have seen
> however on the 64-bit Ubuntu. Trying to run :Rgrep from VIM
> I get following error message :
>
> Error detected while processing function
>
> <SNR>19_RunGrepRecursive..<SNR>19_RunGrepCmd:
> line 20:
> E484: Can't open file /tmp/vAgZSwX/0

You said it's a new version, but check the comments at the top
of the .vim file. Does it say 1.11 as per Yegappan's advice?

The above error can happen when a file name is not properly
escaped.

John

[lazureus]

Yes I got the newest version 1.11. I've cloned this from the GitHub and I think that this mirror is simultaneously updated with sources from the vim.org web page. To be sure I've updated all submodules in my .vim directory.

[John Beckett]

It looks like the wiki has had the answer since March 2013:
http://vim.wikia.com/wiki/Script:311

That is linked in the top line at:
http://www.vim.org/scripts/script.php?script_id=311

I have not used the plugin, but what is written at the above
looks exactly what is needed to fix the error quoted earlier.

John

[lazureus]

I found the reason of the problems, the problem was that in my .vimrc I added settings as follows:

let Grep_Shell_Quoute_Char = "'"
let Grep_Shell_Escape_Char = "'"

This was causing that :Rgrep, right now everything is just fine. However I don't understand why it causes problems, maybe you can explain me this?

[Yegappan Lakshmanan]

Hi,

You have set both the quote and escape characters to single quote (').
For Unix, the shell escape character should be set to backslash. The plugin
sets these variables by default to the correct values. You don't need to change
this in your .vimrc file.

- Yegappan

[lazureus]

I see, thanks a lot for your help, I really appreciate it.