Ben Fritz wrote:
> On Nov 6, 11:20 pm, Tony Mechelynck <[EMAIL PROTECTED]>
> wrote:
> > 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.
>
> Ah yes, this would be a reasonable solution in the general case. I
> have two issues with it, however:
>
> 1. It would require separate logic for Unix vs. Windows, whereas
> simply fixing the default value of shellxquote and shellcmdflag for
> Windows would allow the same logic to be used.
> 2. In the particular plugin I was working on, which highlights errors
> in MATLAB scripts using the mlint utility, system() is used to pass a
> file name to mlint. One of the checks that mlint does is to ensure
> that the file name is "formed from a legal MATLAB identifier." Using
> the short form of Windows path names, mlint will always return this
> error if the file name is longer than 8 characters (though
> incidentally, the file name is also invalid if it contains spaces, but
> theoretically the temporary directory it is stored in may have spaces
> in the path with no problems).
>
> So I think the better solution would be to fix the values of
> shellxquote and shellcmdflag, either by adding extra logic to the
> plugin, or by actually changing the defaults.
>
> For convienience, the suggested default values are:
>
> " for windows, always:
> set shellxquote=\"
> " for windows, when 'shell' does not contain "sh" somewhere:
> set shellcmdflag=/s\ /c
>
> This will place extra quotes around the entire command, and force the
> cmd.exe behavior that removes the first and last quote from the line
> if the first character is a quote.
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.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- 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 ///
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
