On Feb 13, 12:14 pm, Andy Wokula <[email protected]> wrote: > Am 12.02.2012 23:23, schrieb Bram Moolenaar: > > > > > Patch 7.3.443 > > Problem: MS-Windows: 'shcf' and 'shellxquote' defaults are not very good. > > Solution: Make a better guess when 'shell' is set to "cmd.exe". (Ben > > Fritz) > > Files: src/option.c, runtime/doc/options.txt > > cmd.exe's quotes handling is broken, Vim cannot fix it. > (just my opinion) >
Ugh, apparently so. I thought the documentation of cmd.exe was clear enough to prevent this sort of thing, but that's apparently irrelevant because cmd.exe doesn't follow it. > But a cmdline can be enclosed in parens (...) which would prevent removal of > quotes.http://www.microsoft.com/resources/documentation/windows/xp/all/prodd... > > I just found it, not sure how well that works. > > C:\>("C:\Program Files\abc.exe" "some arg with spaces") > > If it works ok, a note in the help would be sufficient ... > An interesting idea, using parenthesis. The page you reference says the parentheses are used "to group or nest multiple commands", so it's not really the intended purpose, but perhaps it will work. Also from the page you reference: "The ampersand (&), pipe (|), and parentheses ( ) are special characters that must be preceded by the escape character (^) or quotation marks when you pass them as arguments." Plugin authors should be correct in passing "A&B" to an external command, without quoting. cmd.exe is doing the incorrect thing here, I think. I think it best to try to get the command to work in the most common cases. So we have: shellxquote=\" and shellcmdflag=/s\ /c (new default) breaks passing arguments with & (and possibly |) unless the user knows to escape them with ^. shellxquote= and shellcmdflag=/c (previous default) breaks using programs with a space in the path and a space in the argument, unless the user knows to surround with parentheses (or quotes like shellxquote does). I'm not sure which use is more common. Either way, I agree adding a help note may allow users and plugin authors to work around the issue. Obviously the new value breaks backwards compatibility with plugins which currently pass '&' inside arguments to external programs, even if they have correctly quoted it. But, I've seen a few plugins in the past (including, if I recall correctly, Taglist, and also http://www.vim.org/scripts/script.php?script_id=2378) which fell victim to the problem fixed by this patch. It does look like using parentheses should allow the & character to be used properly inside quoted arguments without escaping, also if the paths or argument contains spaces. I wonder how the shell redirection might play into using parentheses. shellxquote includes the stuff added for redirection, whereas user- added parentheses will not. -- 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
