Loading ...
Sorry, an error occurred while loading the content.

Re: netrw, winxp, and a problem...

Expand Messages
  • Charles E Campbell Jr
    ... In essence, that s what netrw supports. ... I believe that cygwin does it differently, but even so, there s a possible compiler dependency concerning which
    Message 1 of 5 , May 24, 2006
    • 0 Attachment
      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, read&write and
      >> Nread&Nwrite 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
    • Steve Hall
      ... [snip] ... 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
      Message 2 of 5 , May 24, 2006
      • 0 Attachment
        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
      • Charles E Campbell Jr
        ... 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
        Message 3 of 5 , May 25, 2006
        • 0 Attachment
          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
        • Steve Hall
          From: Charles E Campbell Jr, May 25, 2006 9:52 AM ... Same thing I saw, I never could track down if the errant slashes were coming from tempname(), expand(),
          Message 4 of 5 , May 25, 2006
          • 0 Attachment
            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
          Your message has been successfully submitted and would be delivered to recipients shortly.