Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
6  
Exactly how you're doing it. –  Ignacio Vazquez-Abrams Oct 23 '13 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 '13 at 19:20
    
ssh root@myvps.com; vim /etc/somefile - I log in, and then fire up Vim –  jco Oct 23 '13 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. –  jco Oct 23 '13 at 19:24
    
You could also just do ssh root@myvps.com vim /etc/somefile (note the absence of ;). –  terdon Oct 23 '13 at 19:36

4 Answers 4

up vote 24 down vote accepted

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.

share|improve this answer
1  
best way imo. not only low latency but only having to maintain one vimrc –  exussum Oct 23 '13 at 19:42

You can edit remotely with a local vim or gvim.

:e scp://me@someplace.else/~/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.

share|improve this answer
    
+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. –  Greg Hewgill Oct 23 '13 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. –  jco Oct 23 '13 at 22:34
1  
To be fair, your question originally did not mention "remote server over SCP", that was edited in later. –  Greg Hewgill Oct 24 '13 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 '13 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". –  jco Oct 24 '13 at 8:03

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.