Comment importer .vimrc quand je suis SSH?


34

Mon travail implique généralement l'utilisation de SSH pour se connecter à différentes machines, puis l'utilisation de vim pour éditer des fichiers sur ces machines. Le problème est que je dois constamment copier mon fichier .vimrc. C'est très ennuyant d'ouvrir vim et de ne pas avoir de paramètres. Est-il possible de transporter mes paramètres vim avec moi d'une machine à l'autre sans la copier manuellement partout?


@ duffbeer703: oui, comme set background=darkou set background=lightquelque chose qui ne touche aucune distribution Linux et qui est complètement discret pour l'utilisateur. </ sarcasm>
Hubert Kario Le

Sans avoir encore lu les réponses, je pense que c'est théoriquement possible, car ssh-agent et x-term peuvent être transférés, mais d'un autre côté, ceux-ci sont spécifiquement gérés par ssh et je suppose qu'il existe de nombreuses solutions de contournement pour gérer des cas délirants. .
Trysis

Réponses:


24

Je ressens ta douleur. J'ai tous mes fichiers ~ /.* rc sous contrôle de version (Subversion), fonctionne très bien depuis mes débuts en 1998, en utilisant CVS. Une façon de le faire est de vérifier tous vos fichiers rc comme ceci lorsque vous vous trouvez dans votre répertoire personnel:

svn co svn+ssh://user@host/path/to/repo/trunk/home/user .
A    .signature
A    .vimrc
A    .bashrc
A    .screenrc
A    .psqlrc
[...]
Checked out revision 7645.

De cette façon, les fichiers de configuration seront également synchronisés et mis à jour sur les différents ordinateurs lorsque vous exécuterez svn update.


3
Je suppose que c'est aussi bon que possible. L'astuce est que je dois configurer un référentiel sur une machine accessible depuis toutes les autres machines. Avec une topologie de réseau sécurisée, ce n'est pas toujours facile.
Apreche

J'ai commencé à faire ça récemment, c'est incroyable. Je ne sais pas comment j'ai survécu sans elle.
richo

5
Utilisez peut-être git ou un autre système de contrôle de version distribué. Dans ce cas, il suffit d'avoir accès à une machine sur laquelle les fichiers de configuration sont extraits.
ptman

44

Au lieu d'apporter .vimrc à chaque serveur sur lequel vous devez travailler, pourquoi ne pas modifier les fichiers distants à partir de votre vim local:

Dans vim / gvim, exécutez:

:e scp://remoteuser@server.tld//path/to/document

ou lancez vim comme ceci:

vim scp://remoteuser@server.tld//path/to/document

Cela ouvre parfaitement le fichier (il copie en fait le fichier localement) et, lorsque vous enregistrez, il renvoie le fichier modifié au serveur pour vous.

Il demande un mot de passe ssh, mais celui-ci peut être simplifié via les clés ssh.

Comme d'autres l'ont mentionné, le seul inconvénient de cette méthode est que vous n'obtenez pas la concurrence chemin / fichier comme vous le feriez lorsque vous travaillez directement sur la machine.

Pour plus d'informations, consultez le tutoriel suivant .


+1 pour le scp: // indice, mais je pense que cette solution pourrait être un peu lourde si vous devez copier le chemin chaque fois que vous modifiez un fichier.
Chmeee

1
Ouais, c'est trop lourd. Je dois faire beaucoup de recherches sur les machines distantes pour trouver les fichiers que je veux et je dois souvent les modifier avec le privilège sudo.
Avril

+1 cela fonctionne vraiment bien pour moi. merci :)
Darragh Enright

Dans certains cas, vous devez vous connecter à un serveur principal (login.example.com), puis vous connecter à un serveur local (top.secret.example.com)
puk

Cela fonctionne bien si vous montez la structure de fichier distante dans votre répertoire local, par exemple avec fusermount.
relancer le

18

Vous pouvez créer un script bash pour le copier automatiquement à chaque fois que vous vous connectez, comme ceci:

#!/usr/bin/env bash

scp ~/.vimrc $1:
ssh $1

Vous pouvez l'appeler ssh_vim, par exemple. Ce n'est pas une solution idéale mais résoudra votre problème.

Vous pouvez l'améliorer pour vérifier d'abord s'il y en a déjà une. Si vous n'exécutez pas toujours ssh à partir du même ordinateur, vous pouvez modifier le script pour obtenir le fichier à partir de scp à partir d'un autre ordinateur.

EDIT1

Sur une note connexe, vous pouvez également monter le système de fichiers de la machine distante avec sshfs. De cette façon, vous bénéficiez de votre environnement et de vos outils (pas seulement .vimrc) et vous avez un complément au shell (que vous n'avez pas en utilisant scp: //).

EDIT2

Je viens de découvrir que vous pouvez source votre fichier .vimrc en utilisant scp: //, comme ceci:

:source scp://you@your_computer//yourpath/.vimrc

Cela fonctionne à partir de la ligne de commande vim mais pour le moment je ne sais pas comment l’automatiser. Il ne semble pas fonctionner avec le commutateur '-u' ni dans le fichier .vimrc ni avec $ VIMINIT.

EDIT3

Je l'ai trouvé! Vous pouvez le faire pour démarrer vim avec un .vimrc tiré de votre hôte de référence:

vim -c ':source scp://you@your_computer//yourpath/.vimrc'

L'option '-c' exécute la commande juste après le lancement de vim.

Vous pouvez créer un alias dans votre shell de choix pour éviter de taper. En bash ce serait comme ça:

alias vim="vim -c ':source scp://you@your_computer//yourpath/.vimrc'"

2
Cela ne fonctionne que si l'ordinateur que vous ssh'ing en peut se connecter à l'ordinateur que vous ssh'ing de . Ce n'est pas toujours le cas, par exemple si votre ordinateur est sous NAT.
Trysis

11

Si vous utilisez l'authentification par clé publique, vous pouvez l'utiliser dans vos ~/.ssh/config:

Host *
   PermitLocalCommand yes
   LocalCommand bash -c 'scp -P %p %d/.vimrc %u@%n: &>/dev/null &'

Je l’aime mieux que l’astuce de script suggérée ci-dessus car cela ne gêne pas l’appel de la sshcommande (lors de la spécification de paramètres supplémentaires, etc.)


c'est le meilleur. Pour moi , je devais changer %u@%n:pour %r@%n:que le nom d' utilisateur ssh diffère de nom d'utilisateur de mon ordinateur portable
Moshe

4

Quelques solutions:

1) Créez un partage NFS pour votre dossier personnel et mappez-le à plusieurs endroits.

2) Créez un petit script pour pousser votre fichier .vimrc sur le serveur auquel vous vous connectez avec un fichier identité / clé. Cela pourrait ressembler à quelque chose comme ça (pseudocode):

connectString = arg0  #username@ipaddress

scp -i ~/.ssh/indentity connectString:~/ ~/.vimrc
ssh -i ~/.ssh/indentity connectString

1
Les clés SSH résoudront le problème du mot de passe en texte clair.
LiraNuna

quel outil utiliseriez-vous pour créer un partage NFS?
Wadih M.

@LiraNuna - vous semblez m'avoir attrapé avant mon moment de duh et l'édition de mon post. @Wadih - NFSD est généralement installé sur les systèmes 'nix par défaut. Vous pouvez également monter des partages NFS par défaut (généralement).
Moshen

1
Le partage NFS est une bonne idée , mais probablement courir dans la capacité limitée de déployer de telles choses, en particulier dans des environnements ou des endroits où vous ne firewalled souhaitez modifier les serveurs de production ( en particulier avec NFS)
ericslaw

Vous êtes correct ericslaw. J'ai supposé qu'il s'agissait de plusieurs machines au sein d'un même réseau.
Moshen

4

La même réponse que sunny256, mais utilisez git au lieu de SubVersion.

Conservez une branche principale avec les fichiers communs à tous les ordinateurs et créez une branche pour chaque nouvel ordinateur.

De cette façon, vous pouvez avoir presque les mêmes fichiers sur la plupart des ordinateurs, sans toutefois devenir trop confus.


+1 Une petite question: je me demande s'il est préférable d'utiliser des définitions externes pour les fichiers communs dans Subversion? De cette façon, vous pouvez les avoir dans un endroit et aller chercher dans n'importe quelle succursale
Eugene Yarmash

3

Je sais que c'est un vieux fil, mais je le fais en utilisant sshfs qui monte le système de fichiers par-dessus un fusible. Le vim local effectue toutes les modifications, il n’ya donc aucune raison de copier .vimrc.

Cela a l'inconvénient qu'un autre terminal devra être ouvert pour toutes les commandes qui doivent être exécutées sur le serveur distant, mais pour l'édition, je trouve le meilleur.

Il a également l'avantage supplémentaire de pouvoir utiliser le presse-papiers du système.


2

J'utilise https://github.com/andsens/homeshick pour gérer mes fichiers de points et les stocker sur github.

Homeshick est écrit en 100% bash et vous aide à gérer les "châteaux" qui ne sont que des dépôts git contenant un répertoire / home /. Il a des commandes pour déplacer les fichiers de points existants dans le référentiel et les remplacer par des liens symboliques. Et créer un lien symbolique vers tous les fichiers du référentiel vers votre répertoire personnel sur une nouvelle machine.

Donc, l’idée générale est de garder vos fichiers de points dans un système de contrôle de version, et de créer un lien symbolique entre eux depuis le chemin réel. Ainsi, votre référant n'aura pas besoin de démarrer à partir de votre répertoire personnel et de contenir une tonne de fichiers que vous ne souhaitez jamais ajouter.


Pouvez-vous ajouter des informations à partir du lien? Cela améliorerait la réponse et fournirait des informations si le lien était rompu.
Dave M

1
J'ai expliqué une partie de l'opération et du raisonnement. Je n'ai pas vu l'intérêt de copier la documentation.
Aaron McMillin

1

Si vous êtes comme moi et que vous avez de nombreuses machines de développement (également des machines virtuelles) pour différentes raisons, vous pouvez combiner des clés ssh, un bash_profile intelligent et un RCS de votre choix.

Je seconderais en utilisant nfs / samaba / sshfs. Un inconvénient est que si vous n'avez pas accès au réseau tout le temps, vous ne pouvez pas accéder à ce dont vous avez besoin (voler, pas de wifi, pare-feu, problèmes de routage, etc.). Les machines que je synchronise ne sont pas toutes accessibles en même temps, mais je souhaite partager des informations entre elles.

Voici comment je me suis engagé à emprunter de nombreuses idées sur Internet.

.bash_profile pourrait avoir quelque chose comme ça

$HOME/bin/shell_ssh_agent

Je l'ai reçu de plusieurs endroits mais je ne trouve pas de lien vers celui-ci pour le moment. Le fichier shell_ssh_agent:

#!/bin/bash

SSH_ENV=$HOME/.ssh/environment

#echo "starting"

function start_agent {
    #echo "reaping agents"
    killall ssh-agent
    #echo "Initialising new SSH agent..."
    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > ${SSH_ENV}
    #echo succeeded
    chmod 600 ${SSH_ENV}
    . ${SSH_ENV}
    /usr/bin/ssh-add;
}

# Source SSH settings, if applicable

if [ -f "${SSH_ENV}" ]; then
    . ${SSH_ENV}
    #echo "sourced ssh env"
    ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent > /dev/null || { start_agent; }
else
    start_agent;
fi

Maintenant, lors de la première connexion, vous configurez vos clés. Déconnectez-vous et entrez, cela simplifie la vie.

Mettez tous vos scripts dans un RCS, cela facilite la synchronisation des machines de développement. J'utilise git. L'authentification avec git se fait via ssh, donc les touches ssh aident ici aussi. Notez à ce stade que vous auriez pu utiliser quelque chose comme nfs. Je serais toujours fan d'un RCS pour une raison que je mentionne ci-dessous.

Le cas d'utilisation est

  1. se connecter pour la première fois, les clés sont configurées
  2. Si RCS n'est pas configuré, vérifiez vos scripts personnels (et mettez à jour / fusionz si nécessaire, cela pourrait même faire partie de votre .bash_profile si vous le vouliez)
  3. éditez vimrc, des scripts spéciaux, etc. et validez-les
  4. lorsque vous êtes connecté à d'autres machines, effectuez une mise à jour / fusion / achat. Cela permet de tout synchroniser. c.-à-d. plus de copie de fichiers sur lesquels vous piétiniez parfois et que vous ne vouliez pas.
  5. en contrepartie, vous bénéficiez de la puissance d'un RCS. Je fais parfois des changements défavorables à des scripts ou des configs et ai besoin de revenir en arrière et autres.

Une chose que je veux essayer ensuite est de regrouper la connexion / configuration initiale dans un fichier Make que je copie sur la nouvelle machine. Le fichier makefile peut ensuite effectuer le travail de configuration de vos clés, de votre RCS, etc. Bien entendu, il y a des frais généraux, mais si vous configurez de nombreuses machines, il s’agit:

  1. un gain de temps
  2. plus facile de synchroniser les configurations et les scripts personnels des machines de développement
  3. gestion des modifications des scripts et des configs.

1

J'utilise un fichier makefile contenant une liste de tous les serveurs auxquels je me connecte et, lorsque je modifie ma machine locale, "make" est exécuté à l'aide du fichier makefile qui met automatiquement à jour tous les serveurs avec les modifications ou les plugins.


Cela ressemble plus à une manière élégante de faire un script. Make is great en construisant un fichier à partir d'un autre, mais je ne voudrais pas l'utiliser dans une situation où chaque règle est un " .PHONY."
anthony

1

sshrc résout ce problème. Vous mettez votre fichier .vimrc dans ~ / .sshrc.d /, puis vous ajoutez export VIMINIT="let \$MYVIMRC='$SSHHOME/.sshrc.d/.vimrc' | source \$MYVIMRC"à `/.sshrc.


1

J'ai écrit un outil simple pour cela qui vous permettra de transporter nativement votre fichier .vimrc à chaque fois que vous ssh , en utilisant les options de configuration intégrées SSHd d'une manière non standard.

Pas plus svn, scp, copy/paste, etc. requis.

Il est simple, léger et fonctionne par défaut sur toutes les configurations de serveur que j'ai testées jusqu'à présent.

https://github.com/gWOLF3/viSSHous


0

Utilisation de la variable VIMINIT:

export VIMINIT='set number'

et le transférer sur le serveur distant:

ssh remoteuser@remoteserver -o SendEnv=LC_VIMINIT -t 'export VIMINIT=$LC_VIMINIT && bash'

est facile en utilisant .bash_profiles ou .bashrc

export VIMINIT='
set number
'

export LC_VIMINIT=$VIMINIT

sshh (){
ssh -o SendEnv=LC_VIMINIT $1 -t 'export VIMINIT=$LC_VIMINIT && bash'

Maintenant, essayez d’exécuter vim sur un serveur distant en utilisant sshh pour la connexion:

sshh remoteuser@remoteserver

Si vous le souhaitez, vous pouvez également transférer vos plugins sur un serveur distant:

export LC_VIMINIT="
set number
set nocompatible
filetype off
set rtp+=~/.[USER]_vim/bundle/Vundle.vim
call vundle#begin()
Plugin 'VundleVim/Vundle.vim'


set shell=/bin/bash
call vundle#end()
filetype plugin indent on
"

export VIMINIT=$LC_VIMINIT

sshh (){
        if [[ $1 ]]; then
                ssh-copy-id $1 &>/dev/null &&
                rsync -lzr --partial --del ~/.[USER]_vim ${1}: &&
                ssh -o SendEnv=LC_VIMINIT $1 -t 'export VIMINIT=$LC_VIMINIT && bash';
        else
                echo "Provide remote user@host";
        fi
}

0

J'ai la même situation, mais ce n'est pas juste " .vimrc". J'ai aussi des choses comme

  • configuration bash, invites et fonctions,
  • fichiers de configuration et d'autorisation ssh,
  • les scripts shell que j'aime bien avoir à portée de main.
  • bien sûr, mon vimrc, mais aussi certaines fonctions et la coloration syntaxique de vim.

Ma solution (démarrée il y a 30 ans avec "dist" à l'origine!) Consiste à configurer un cron nocturne pour rsync une configuration de maison minimale sur toutes les machines sur lesquelles je travaille, afin qu'elle soit mise à jour tous les soirs.

Ainsi, toutes les autres machines avec lesquelles je travaille sont mises à jour! Je peux simplement ajouter une nouvelle machine à la liste des «comptes» et faire une distribution sur une seule machine pour la démarrer.

Vous n’avez pas besoin d’être beaucoup, et vous pouvez commencer petit et le rendre plus complexe au fur et à mesure. Comme vous pouvez l’imaginer après 30 ans, ma distribution est maintenant assez complexe, je ne la mettrai donc pas ici. Inutile de dire que cela permet également d'échanger certaines configurations pour d'autres réseaux, de nettoyer la maison (par exemple, la corbeille, les fichiers de cache), de s'assurer que les autorisations de la maison sont correctes, etc.

NOTE J'autorise uniquement la connexion ssh sans mot de passe depuis une machine 'maison' à tous les autres, jamais de retour! Toute croix ssh est protégée par mot de passe.


-1

Vous pouvez envisager un script EXPECT qui vous permet de définir votre chemin et votre environnement (tels que les variables EXRC) lorsque vous appuyez sur une certaine touche. Ne devrait pas tarder avant que quelqu'un publie un script similaire.

Lorsque vos batteries de serveurs comptent plus de quelques dizaines (pensez-en des milliers), configurer quelque part facilement votre environnement sur une boîte vierge permet de sauver des vies.

Souvent, lorsque je me connecte à une boîte, mon homedir est créé pour la première fois!


Expect est une manière très fragile de faire quoi que ce soit. Un système d'exploitation, une architecture ou même une mise à niveau différents, et cela peut casser. OK pour quelque chose de petit, mais pas extensible avec le temps.
Anthony

-1

Il a été réalisé avec le bash oneliner suivant. Comme il est fait avec la substitution de processus, les fichiers temporaires ne sont pas créés.

ssh -t user@host '
bash --rcfile <(
    echo -e ' $(cat <(echo "function lvim() { vim -u <(echo "$(cat ~/.vimrc|base64)"|base64 -d) \$@ ; }") \
                    ~/dotfiles/{.bashrc,sh_function,sh_alias,bash_prompt} \
                    <(echo -e alias vim=lvim) | \
                    base64 
               ) ' \
    |base64 -d)'

https://gist.github.com/blacknon/a47083f3bbbd0374998bdf7e3b3396cc

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.