13

Currently I'm doing it by SSHing into a server, and executing Vim on the server. This has the benefit of not having to deal with cumbersome syntax of opening files from a remote server over SCP, and, more importantly, being able to really quickly navigate the server's filesystem. On the other hand, it has lag, which make editing kind of hard.

What's the canonical way of editing lots of remote files?

7
  • 6
    Exactly how you're doing it. Oct 23, 2013 at 19:11
  • If vim is exhibiting lag, this probably points to an issue with your network rather than your workflow.
    – Joseph R.
    Oct 23, 2013 at 19:20
  • ssh [email protected]; vim /etc/somefile - I log in, and then fire up Vim
    – jcora
    Oct 23, 2013 at 19:23
  • Actually it's with the network. When I press a key it has to send a packet from Europe to the US, where the Vim instance I'm using is actually running.
    – jcora
    Oct 23, 2013 at 19:24
  • You could also just do ssh [email protected] vim /etc/somefile (note the absence of ;).
    – terdon
    Oct 23, 2013 at 19:36

4 Answers 4

26

You can use SSHFS to mount a remote home in a local folder. Has the advantage of using the current infrastructure and low latency of local vim.

1
  • 1
    best way imo. not only low latency but only having to maintain one vimrc
    – exussum
    Oct 23, 2013 at 19:42
20

You can edit remotely with a local vim or gvim.

:e scp://[email protected]/~/myfiles/whatever.file

scp is a secure copy protocol. It authenticates the same way as ssh, so your ssh key needs to be available, etc. There are various other protocols supported (see :help netrw-externapp) but scp is probably the easiest if you are already using ssh to the same place.

You can browse directories this way, just make sure the path ends with a /. Otherwise vim turns it into a new file.

:w automatically writes the file via scp. If the write fails for some reason, you should notice, since they'll be a "shell returned 1" kind of thing in the status bar. However, beware: if you don't notice, vim doesn't know and that can have consequences -- for example, if you now quit, it won't warn you. It's particularly easy to miss this if you use :wa a lot ;| That's the only caveat I have.

For the official docs, see :help netrw.

5
  • +1 I was just about to write this. The netrw plugin (which is usually installed by default) has a wide variety of ways to read remote files. Oct 23, 2013 at 20:36
  • I was referring to this option when I said: "This has the benefit of not having to deal with cumbersome syntax of opening files from a remote server over SCP, and, more importantly, being able to really quickly navigate the server's filesystem" This way seems very limited to me.
    – jcora
    Oct 23, 2013 at 22:34
  • 1
    To be fair, your question originally did not mention "remote server over SCP", that was edited in later. Oct 24, 2013 at 0:15
  • @GregHewgill : Thanks for that note as I'm a bit baffled -- this is the most simple and straightforward method for general purposes (no offence to SSHFS!). If appending an URL to a filepath is relatively cumbersome, I'm curious as to how the task being performed actually requires someone sit down with an editor to do it...esp. since you can just up arrow the command. But to each their own.
    – goldilocks
    Oct 24, 2013 at 0:46
  • @GregHewgill yeah, I know, I wrote the question on my phone while moving so I left some stuff out unintentionally. goldilocks, I open and close files all the time. Navigate the filesystem too and open from there. Appending a URL+path was more cumbersome than just "being there".
    – jcora
    Oct 24, 2013 at 8:03
2

I'd use rsync. It transfers only what changed. Like so:

rsync -e ssh -va remoteuser@remotehost:remotedir .

then edit the files locally at your own leisure. Zero lag. You get to inspect all the files before you commit them:

rsync -e ssh -va . remoteuser@remotehost:remotedir

I'm assuming you first create your local dir and cd into that. You can also make it handle the removal of files, but be really careful with that, because executing that in the wrong directory could nuke an entire directory tree.

rsync -e ssh -va --delete . remoteuser@remotehost:remotedir

What I do is I run it in "dry mode" first, using the 'n' flag, like so:

rsync -e ssh -van --delete . remoteuser@remotehost:remotedir

It will report what it would have done, if it were for real. If I'm happy with the reported list, I run it again, and remove the 'n' flag.

rsync is very efficient. There are various other flags as well. It's quite sophisticated.

0

May be you named the most appropriate way - SSH way, but still depending on the very nature of the files edited, you could allocate a little partition, making it shared and put the files there, of course if the security policy allows this action. For this suggestion you might use NFS or Samba most easily, but still editing test file is a general conception in UNIX and may be you have to keep it the way you do it currently.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .