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

Re: minor bug in network file edit.

Expand Messages
  • raf
    ... not to people who use rcp, scp or rsync :) ... i think an explanation would be sufficient. nobody s complained about the rcp behaviour and it s the same.
    Message 1 of 5 , Oct 31 12:28 AM
    • 0 Attachment
      Bram Moolenaar wrote:

      > Michael Beattie wrote:
      > > Wichert (debian maintainer of vim) suggested I mail you about this minor
      > > bug with network file editing:
      > >
      > > omnic@relativity:~> vim scp://aeon/var/www/index.html
      > >
      > > from vim:
      > > :!scp aeon:var/www/index.html /tmp/vAMUDV4L
      > > scp: var/www/index.html: No such file or directory
      > >
      > > 1 returned
      > > Error detected while processing function NetRead->NetGetFile:
      > > line 5:
      > > Can't open file /tmp/vAMUDV4L
      > >
      > > so:
      > >
      > > omnic@relativity:~> vim scp://aeon//var/www/index.html
      > >
      > > from vim:
      > > :!scp aeon:/var/www/index.html /tmp/vAW7yok9
      > >
      > > <html>....
      > >
      > > works fine.
      > >
      > > not sure how you'd go about this one... mandating absolute paths?
      > Well, at least you can get the file you want this way.
      > When using scp://, the path you give is relative to your login directory.
      > It's probably the same for rcp://. I think this is OK, because it makes it
      > easy to access your own files.
      > Accessing files with an absolute directory is used for ftp:// and http://.
      > Perhaps it's confusing that scp:// and rcp:// are different?

      not to people who use rcp, scp or rsync :)

      > Would it be sufficient to explain this in the docs, or do we really need to
      > change how it works?

      i think an explanation would be sufficient. nobody's complained about
      the rcp behaviour and it's the same. anyway, i thought everything after
      the : was protocol dependent anyway (at least everything after the 3rd / is).
      just because ftp and http uris look the same, doesn't mean all uris have to.

      i'm sure we'll get used to the scp://host/~/path but it's a mistake to think
      that rfc2396 requires it (i.e. just because there is such a thing as an
      absolute uri, that does not mean that what appears after the 3rd / in such
      an absolute uri must be an absolute unix path to a file on a disk somewhere -
      that is a misinterpretation of the rfc). i think this usage will be less
      intuitive to scp users than the current behaviour. ymmv.

    Your message has been successfully submitted and would be delivered to recipients shortly.