On Wednesday, April 24, 2013 1:55:57 AM UTC-5, Darek wrote:
> Hi
> 
> 
> 
> On Tue, Apr 23, 2013 at 5:14 PM, Ben Fritz <[email protected]> wrote:
> 
> > On Tuesday, April 23, 2013 8:58:20 AM UTC-5, Darek wrote:
> 
> >> Hi
> 
> >>
> 
> >>
> 
> >>
> 
> >> On Mon, Apr 15, 2013 at 6:07 PM, Yegappan Lakshmanan
> 
> >>
> 
> >> <[email protected]> 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.
> 
> >>
> 
> >
> 
> > 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.
> 
> >
> 
> 
> 
> 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.
> 
> 

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.

-- 
-- 
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Raspunde prin e-mail lui