However, if it is wrapped in quotes, the default settings of
shellxquote on win32 do not work. This command will not do what is
intended, for example:
cmd /c "C:\some path\some program.exe" "an argument"
If you set shellxquote to \" it does work. The command passed looks
funny, but is actually desired:
cmd /c ""C:\some path\some program.exe" "an argument""
I think that shellxquote should default to \" on Windows always. I
know of no case where it fails.
The reason for this behavior:
From the help for cmd in Windows:
> If /C or /K is specified, then the remainder of the command line after
> the switch is processed as a command line, where the following logic is
> used to process quote (") characters:
>
> 1. If all of the following conditions are met, then quote characters
> on the command line are preserved:
>
> - no /S switch
> - exactly two quote characters
> - no special characters between the two quote characters,
> where special is one of: &<>()@^|
> - there are one or more whitespace characters between the
> the two quote characters
> - the string between the two quote characters is the name
> of an executable file.
>
> 2. Otherwise, old behavior is to see if the first character is
> a quote character and if so, strip the leading character and
> remove the last quote character on the command line, preserving
> any text after the last quote character."
Both values of shellxquote, in this case, will fall into category 2.
Thus, the current default actually executes the command:
C:\some path\some program.exe" "an argument
Whereas, setting shellxquote to \" will execute:
"C:\some path\some program.exe" "an argument"
This is the desired command.
Normal commands would still work, for example, the command:
echo "abc def"
becomes:
cmd /c "echo "abc def""
which executes:
echo "abc def"
Again, just as desired.
This might not always work, because I think some versions of cmd.exe
will strip the _closing_ quote instead of the _last_ quote. For the
best possible compatibility, it is probably a good idea to also
default shellcmdflag to "/s\ /c" instead of just "/c" in the same
situation that "/c" currently applies. This will force the 2nd quote
behavior given in the quoted cmd help.
I had some trouble reproducing the problem. When both 'shellquote' and
'shellxquote' are emtpy and 'shell' is cmd.exe, this works fine:
:echo system('"e:/mksnt/echo.exe" foo bar')
I finally figured out a way to break it:
:echo system('"e:/mksnt/echo.exe" "foo bar"')
The double quote at the end is essential.
It appears cmd.exe strips the first and last double quote and tries to
execute e:/mksnt/echo.exe" "foo . Setting 'shellxquote' to a double
quote indeed helps to fix this.
Now the question is what will break if we change the default for
'shellxquote'. I'm not sure about that.
--
If Microsoft would build a car...
... The airbag system would ask "are you SURE?" before deploying.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
I am the one who supplied the code to Yegappan to create the ctags_cmd file.
This is not just affecting Vim, it seems cmd.exe will not execute
commands with more than 1 set of double quotes. I guess you are
saying above, you can by simply doubling up the first and the last.
Gee, I wish I had figured that our earlier. I have had to do the old
cmd file for several different projects (unrelated to Vim).
Dave
[...]
The problem here appears to be that the plugin assumes a sh like
'shell'. Escaping double quotes with a backslash doesn't work for
cmd.exe, it sees backslashes as path separators..
--
Some of the well know MS-Windows errors:
ESLEEP Operator fell asleep
ENOERR No error yet
EDOLLAR OS too expensive
EWINDOWS MS-Windows loaded, system in danger
To avoid passing a path with spaces in it, use the "short form" of the
path, such as %:p:8 (this works only on Windows -- on Unix you can just
backslash-escape the spaces).
This will convert the path so that "Program Files" becomes PROGRA~1, "My
Documents" MYDOCU~1 and, I think, "Copy of startup.m" COPYOF~1.M -- the
same directories and files will be accessed, but without the need for
quoting the path.
Best regards,
Tony.
--
Information Center, n.:
A room staffed by professional computer people whose job it is
to tell you why you cannot have the information you require.
I think this should only be done for cmd.exe, not for command.com. So
the check should not be "'shell' not matching sh" but "'shell' matching
cmd".
> I personally think that the current defaults break in enough cases
> that we should change them as suggested in this thread, but I can see
> the argument for keeping the current values to prevent plugins like
> taglist that escape quotes with backslashes depending on the value of
> shellxquote. Plugin developers may have assumed (as done in the
> taglist plugin) that if the cmd.exe shell is used, shellxquote will
> _not_ be equal to a " character. Thus, setting shellxquote to \"
> causes code to execute that is not intended to run at all for the
> cmd.exe shell.
Yes there is a risk. It's hard to tell what might break.
--
hundred-and-one symptoms of being an internet addict:
205. You're constantly yelling at your spouse, family, roommate, whatever,
for using the phone for stupid things...like talking.
This may work in a lot of cases, but it is not a good general solution. Firstly, not all filesystems generate short filenames. FAT32 and NTFS are capable of generating short filenames. Secondly, on NTFS at least, you can disable short filenames. I always disable it on my machines (there is some perf gain from doing so). Thirdly, NTFS probably won't support short filenames forever. Short filenames are already considered deprecated. In a future release of Windows, possibly the one after Windows 7, expect short filename support to disappear completely.
Craig