On Feb 13, 10:04 pm, Bram Moolenaar <b...@moolenaar.net> wrote:
> Ben Fritz wrote:
> > 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.
>
> Never trust Microsoft documentation, always verify it actually works
> that way. And then try it on different systems, they usually only think
> of the latest. I would like to support back to Windows XP.
>
For the record, I use the almost the same Vim config on Windows XP,
Windows XP 64-bit at work, and Windows Vista. I even have used & to
intentionally separate commands. I never used it in an argument,
though, I guess I never thought to take apart the MS documentation and
test each little piece to make sure it actually behaves as stated.
> > 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.
>
> If we set shellxquote to '(', we could use the closing ')'
> automatically. Does that solve most problems? Please try it out with
> the examples previously given.
>
> I do hope we can find a solution that doesn't break any existing
> scripts.
>
Yes, I hope so too. But I think it should work out-of-the-box with
most common commands, so I think some change or another is needed to
the defaults. I like the shellxquote=( idea.
> A command may intentionally use & and | to separate commands. Always
> escaping them will break this intentional use.
>
Yes, and this works (at least for the few uses I have in my vim
config) with the shellxquote=" from the patch. I wasn't suggesting
always escaping them. I thought maybe escaping them in shellescape()
would be a good idea, since shellescape() is for command arguments;
however (according to the documentation anyway) surrounding it with
quotes is supposed to work, so escaping again is redundant (and
doesn't work correctly under normal circumstances). Using the
paretheses to surround the entire command appears to allow the
surrounding quotes to work just fine. I think the problem might be
that the shell calling cmd /c is parsing the quotes before the shell
created by cmd /c, e.g. the command executed for:
cmd /c "echo "A&B""
is not:
echo "A&B"
in a new cmd.exe as intended but rather:
cmd /c "echo "A
followed by:
B""
in the same cmd.exe.
Using paretheses instead of quotes to surround the whole thing should
avoid the calling shell trying to be too smart.
--
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
