On 2/22/07, Thomas Michael Engelke <[EMAIL PROTECTED]> wrote:
2007/2/21, Yakov Lerner <[EMAIL PROTECTED]>: > On 2/21/07, Thomas Michael Engelke <[EMAIL PROTECTED]> wrote: > > I'm using vim7 from my Total Commander under Windows XP with the > > following command line: > > > > vim70\gvim.exe --remote-tab-silent <filename> > > > > Whenever I try to open a file from a UNC path (e.g. > > \\Cd-server\HKR_304B\install.inf ), I get the attached message, > > roughly translated as > > > > Directory \CD-server\HKR_304B could not be found in 'cdpath'
The incorrect interpretation of backslashes looks to me like a bug in windows' gvim.exe. gvim.exe definitely could double backslashes itself (if it needs it for its internal purposes), and not require the unsuspecting user to do it. Doubling backslashes is something we do when programming in vimscript inside vimscript strings, but not for arguments that come from cmd.exe commandline. Looks like something that could be fixed in gvim.exe. Yakov
> > > > I'm not sure if this is a problem of vim. Trying the same on a random > > command line (cmd.exe) using absolute path to vim and UNC for the > > file, I get the file opened with no contents and vim claims, it's a > > new file. vim also hickups away one "\" and claims the final path is > > \Cd-server\HKR_304B\install.inf. It would save the file now to > > <localharddisc>:\Cd-server\HKR_304B\install.inf, which is hardly what > > I tried to do :) > > 1. What happens if you double every backspace ? Like > \\Cd-server\\HKR_304B\\install.inf ? Ha! This works! Now the problem may be, how to tell the starting application to escape every backslash. I reckon this might not be possible. Hm. Strange though: passing vim "\" or "\\" does the same error message. I reckon from the original error message that only the double backslash is a problem, which vim interpretes as only the first ones are missing, all other are right there in the message. Maybe anyone can elaborate on that? Thank you. -- GPG-Key: tengelke.de/thomas_michael_engelke.asc
