Re: netrw, winxp, and a problem...
Steve Hall wrote: Just assume all paths are Windows-hostile unless passed through such a wrapper. (I never see these errors on *nix, so I assume it's path related.) I'll try it! The unfortunate part is, I can't test it. Or rather, I can test to see if the wrapper introduces some new problem, but as I haven't been able to duplicate the problem others are having I can't do the test. Thank you! Chip Campbell
Re: netrw, winxp, and a problem...
From: Charles E Campbell Jr, May 25, 2006 9:52 AM Steve Hall wrote: Just assume all paths are Windows-hostile unless passed through such a wrapper. (I never see these errors on *nix, so I assume it's path related.) I'll try it! The unfortunate part is, I can't test it. Or rather, I can test to see if the wrapper introduces some new problem, but as I haven't been able to duplicate the problem others are having I can't do the test. Same thing I saw, I never could track down if the errant slashes were coming from tempname(), expand(), fnamemodify(), existing environment vars, ones Vim found (Vim contrives $HOME if it doesn't exist), etc. But the reports went away, so it seemed to fix it for us. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net
Re: netrw, winxp, and a problem...
A.J.Mechelynck wrote: Charles E Campbell Jr wrote: Hello, Tony! I've had several folks having a problem with WinXP and netrw. The problems seem to involve temporary files during attempts to use ftp; since temporary filenames are produced by tempname(), they're o/s dependent. Admittedly without having searched the source, I figure that these temporary files are in fact produced by the C function tmpnam() -- hmm, I did just do that search, and tmpnam() is used. Since that's a C-library function, these temporary files are presumably not only o/s dependent but compiler dependent. I generally compile my own vim using cygwin+gcc for Windows. I've never seen the problems these folks are having. So, last night I downloaded a copy of your compiled vim (7.0aa, perhaps patched to 213? - I don't recall exactly). I also installed my latest netrw, and used it in a dos (cmd.exe) window, and furthermore used vim -u NONE (also, set nocp and :so ..path-to-netrwPlugin.vim). I was hoping to finally see these problems, but I still was able to do remote browsing, readwrite and NreadNwrite without any problems. So, have you had any issues with remote browsing/ftp with netrw? Do you have any suspicions as to what the problem might be? What compiler do you use? Thank you, Chip Campbell Sorry, Dr. Chip, I can't help you there so I'm referring you to the vim-dev list: 1. As a rule, I don't edit over ftp, I edit my files locally and, when I'm satisfied with the result, I upload them with any available ftp client. If I want to make sure that my files look all right, I browse them with my favourite web browser (both locally with file: and remotely with http: or ftp; ) In essence, that's what netrw supports. Creation and opening of a temporary zero-length file with a unique name in a given directory is a well-documented system call on Dos-like systems; I wouldn't expect it to be compiler-dependent since the OS explicitly provides it. (I'm not familiar with specific Windows calls but there is a Dos system call for it since Dos 3 or maybe earlier.) I believe that cygwin does it differently, but even so, there's a possible compiler dependency concerning which directory the temporary file is made. If it works OK with your latest version of netrw, then maybe the trouble is that the version of netrw distributed with Vim 7.0 is _not_ the latest one? The latest is v100j, which I've just uploaded to my website. The distributed version is, alas, always likely to not be the latest one, except for a short window of time... Thank you, Chip Campbell
Re: netrw, winxp, and a problem...
On Wed, 2006-05-24 at 12:04 -0400, Charles E Campbell Jr wrote: A.J.Mechelynck wrote: Charles E Campbell Jr wrote: I've had several folks having a problem with WinXP and netrw. The problems seem to involve temporary files during attempts to use ftp; since temporary filenames are produced by tempname(), they're o/s dependent. [snip] Sorry, Dr. Chip, I can't help you there so I'm referring you to the vim-dev list: I might be completely off the trail here, but this sounds suspiciously like my age old problem of using Vim-generated paths for Windows calls via system(), tempname() or the like. No matter how hard I've tried to maintain a Windows path in a var, it somehow always ends up with an escaped space or a forward slash. (It seems use of fnamemodify() or expand() resets them.) So a long time ago I gave up trying to keep slashes and backslashes straight in my variables in favor of a wrapper approach: let tmp = myvar system call prep if has(win32) remove trailing slash (Win95) let tmp = substitute(tmp, '\(\\\|/\)$', '', 'g') remove escaped spaces let tmp = substitute(tmp, '\ ', ' ', 'g') convert slashes to backslashes let tmp = substitute(tmp, '/', '\', 'g') endif set noshellslash call system(mkdir . '' . tmp . '') set shellslash Just assume all paths are Windows-hostile unless passed through such a wrapper. (I never see these errors on *nix, so I assume it's path related.) Unfortunately, it is difficult to make such a strategy reasonably modular since you want to maintain the space between the command, options and the final path-filename argument. Abstracting the path through one more function ends up confusing me more than just duplicating the wrapper where needed. You guys are both old pros, but I've been bushwhacked by this one so many times I figured I'd encourage you to take one more gander. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net
Re: netrw, winxp, and a problem...
Charles E Campbell Jr wrote: Hello, Tony! I've had several folks having a problem with WinXP and netrw. The problems seem to involve temporary files during attempts to use ftp; since temporary filenames are produced by tempname(), they're o/s dependent. Admittedly without having searched the source, I figure that these temporary files are in fact produced by the C function tmpnam() -- hmm, I did just do that search, and tmpnam() is used. Since that's a C-library function, these temporary files are presumably not only o/s dependent but compiler dependent. I generally compile my own vim using cygwin+gcc for Windows. I've never seen the problems these folks are having. So, last night I downloaded a copy of your compiled vim (7.0aa, perhaps patched to 213? - I don't recall exactly). I also installed my latest netrw, and used it in a dos (cmd.exe) window, and furthermore used vim -u NONE (also, set nocp and :so ..path-to-netrwPlugin.vim). I was hoping to finally see these problems, but I still was able to do remote browsing, readwrite and NreadNwrite without any problems. So, have you had any issues with remote browsing/ftp with netrw? Do you have any suspicions as to what the problem might be? What compiler do you use? Thank you, Chip Campbell Sorry, Dr. Chip, I can't help you there so I'm referring you to the vim-dev list: 1. As a rule, I don't edit over ftp, I edit my files locally and, when I'm satisfied with the result, I upload them with any available ftp client. If I want to make sure that my files look all right, I browse them with my favourite web browser (both locally with file: and remotely with http: or ftp; ) 2. At the moment, my Windows computer is in the Netherlands for repairs (which will cost me almost 250 € including postage and handling), I'm on Linux at the moment. This also explains why my Vim builds for Windows have been temporarily discontinued -- no ETA when (if ever) I'll be able to resume them. About the computer I use: my (now broken-down) Windows computer was a laptop with WinXP 5.1.2600 SP2 and the same vim gvim as those I used to distribute; I compiled my latest Vim versions for native-Windows using Cygwin gcc and src/Make_cyg.mak. Before that I had used Borland BCC32 but it proved inadequate for UTF-8 operation (even if only the data, not the filenames, were in UTF-8). My current computer is a desktop with Novell-SuSE Linux Professional 9.3 and (currently) gvim 7.0.017, huge version for GTK+2 and static perl, ruby and TCL, compiled with gcc 3.3.5 20050117 (prerelease) (SuSE Linux). I don't feel that this vim executable is good enough for public distribution but I will readily help other Unix Vimmers to compile their own if they need help: it's even easier than on Windows. (For Windows, there is a HowTo on my web site.) Creation and opening of a temporary zero-length file with a unique name in a given directory is a well-documented system call on Dos-like systems; I wouldn't expect it to be compiler-dependent since the OS explicitly provides it. (I'm not familiar with specific Windows calls but there is a Dos system call for it since Dos 3 or maybe earlier.) If it works OK with your latest version of netrw, then maybe the trouble is that the version of netrw distributed with Vim 7.0 is _not_ the latest one? The 7.0 release version I have here consists of: $VIMRUNTIME/plugin/netrwPlugin.vim dated Oct. 27, 2005 $VIMRUNTIME/autoload/netrw.vim, version 98 dated May 02, 2006 $VIMRUNTIME/autoload/netrwFileHandlers.vim, version 8 dated May 01, 2006 $VIMRUNTIME/autoload/netrwSettings.vim, version 6 dated Mar 22, 2006. I got my sources and runtimes over FTP (all 3 archives, unix+extra+lang -- so even patches for modules I don't need won't complain -- and 17 patches). For Vim 7.0aa, I used to download the snapshot zipfiles whenever I noticed a new one -- until my laptop ceased to work. Best regards, Tony.
