Comment suis-je censé éditer des fichiers sur un réseau avec Vim?

13

Actuellement, je le fais en SSHing sur un serveur et en exécutant Vim sur le serveur. Cela a l'avantage de ne pas avoir à gérer une syntaxe lourde d'ouverture de fichiers à partir d'un serveur distant via SCP et, plus important encore, de pouvoir naviguer très rapidement dans le système de fichiers du serveur. D'un autre côté, il a un décalage, ce qui rend l'édition difficile.

Quelle est la manière canonique d'éditer de nombreux fichiers distants?

networking files vim

— jcora
source

6

Exactement comment vous le faites.

— Ignacio Vazquez-Abrams

Si vimprésente un retard, cela indique probablement un problème avec votre réseau plutôt que votre flux de travail.

— Joseph R.

ssh root@myvps.com; vim / etc / somefile - Je me connecte, puis

— lance

En fait, c'est avec le réseau. Lorsque j'appuie sur une touche, elle doit envoyer un paquet de l'Europe aux États-Unis, où l'instance Vim que j'utilise est en cours d'exécution.

— jcora

Vous pouvez aussi simplement faire ssh root@myvps.com vim /etc/somefile(noter l'absence de ;).

— terdon

26

Vous pouvez utiliser SSHFS pour monter une maison distante dans un dossier local. A l'avantage d'utiliser l'infrastructure actuelle et la faible latence du vim local.

— Mircea Vutcovici
source

1

meilleure façon imo. non seulement une faible latence, mais seulement avoir à maintenir un vimrc

— exussum

20

Vous pouvez éditer à distance avec un vim ou un gvim local.

:e scp://me@someplace.else/~/myfiles/whatever.file

scpest un protocole de copie sécurisée . Il s'authentifie de la même manière que ssh, donc votre clé ssh doit être disponible, etc. Il existe différents autres protocoles supportés (voir :help netrw-externapp) mais scp est probablement le plus simple si vous utilisez déjà ssh au même endroit.

Vous pouvez parcourir les répertoires de cette façon, assurez-vous simplement que le chemin se termine par un /. Sinon, vim le transforme en un nouveau fichier.

:wécrit automatiquement le fichier via scp. Si l'écriture échoue pour une raison quelconque, vous devriez le remarquer, car ce sera une sorte de "shell retourné 1" dans la barre d'état. Cependant, méfiez-vous: si vous ne le remarquez pas , vim ne sait pas et cela peut avoir des conséquences - par exemple, si vous quittez maintenant, cela ne vous avertira pas. Il est particulièrement facile de rater cela si vous en utilisez :wabeaucoup. | C'est la seule mise en garde que j'ai.

Pour les documents officiels, voir :help netrw.

— boucle d'or
source

+1 J'étais sur le point d'écrire ceci. Le plugin netrw (qui est généralement installé par défaut) a une grande variété de façons de lire des fichiers distants.

— Greg Hewgill

Je faisais référence à cette option quand j'ai dit: "Cela a l'avantage de ne pas avoir à gérer une syntaxe lourde d'ouverture de fichiers à partir d'un serveur distant via SCP, et, plus important encore, de pouvoir naviguer très rapidement dans le système de fichiers du serveur" . me semble très limité.

— jcora

1

Pour être honnête, votre question ne mentionnait pas à l'origine "serveur distant sur SCP", qui a été modifié plus tard.

— Greg Hewgill

@GregHewgill: Merci pour cette note car je suis un peu déconcerté - c'est la méthode la plus simple et la plus directe à des fins générales (aucune infraction à SSHFS!). Si l'ajout d'une URL à un chemin de fichier est relativement lourd, je suis curieux de savoir comment la tâche en cours nécessite que quelqu'un s'assoie avec un éditeur pour le faire ... esp. puisque vous pouvez simplement flécher la commande vers le haut. Mais à chacun son sort.

— goldilocks

@GregHewgill ouais, je sais, j'ai écrit la question sur mon téléphone pendant que je bougeais donc j'ai laissé des trucs involontairement. goldilocks, j'ouvre et ferme des fichiers tout le temps. Naviguez également dans le système de fichiers et ouvrez-le à partir de là. Ajouter une URL + un chemin était plus lourd que simplement "être là".

— jcora

2

J'utiliserais rsync. Il ne transfère que ce qui a changé. Ainsi:

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

puis modifiez les fichiers localement à votre guise. Zéro décalage. Vous pouvez inspecter tous les fichiers avant de les valider:

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

Je suppose que vous créez d'abord votre répertoire local et cddans cela. Vous pouvez également lui faire gérer la suppression des fichiers, mais soyez très prudent avec cela, car l'exécution de cela dans le mauvais répertoire pourrait nuke toute une arborescence de répertoires.

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

Ce que je fais, c'est que je l'exécute en "mode sec" d'abord, en utilisant le drapeau 'n', comme ceci:

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

Il rendra compte de ce qu'il aurait fait, s'il avait été réel. Si je suis satisfait de la liste signalée, je l'exécute à nouveau et je supprime l'indicateur 'n'.

rsync est très efficace. Il existe également divers autres drapeaux. C'est assez sophistiqué.

— Mike
source

0

Peut-être que vous êtes nommé de la manière la plus appropriée - façon SSH, mais toujours en fonction de la nature même des fichiers modifiés, vous pouvez allouer une petite partition, la rendre partagée et y placer les fichiers, bien sûr si la politique de sécurité permet cette action. Pour cette suggestion, vous pouvez utiliser NFS ou Samba plus facilement, mais la modification du fichier de test est une conception générale sous UNIX et il se peut que vous deviez le conserver comme vous le faites actuellement.

— VVelev
source