Comment transporter le fichier .vimrc lors de la connexion SSH?

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

Gardez 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 pour autant devenir trop confus.

Je sais que c'est un ancien fil de discussion, mais la façon dont je le fais est en utilisant sshfs qui monte le système de fichiers via fuse. Le vim local effectue toutes les modifications, donc il n'est pas nécessaire de copier le fichier .vimrc partout.

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 que c'est la meilleure façon de procéder.

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

Je utilise https://github.com/andsens/homeshick pour gérer mes dotfiles, et les stocke sur github.

Homeshick est écrit à 100% en bash, et vous aide à gérer des "châteaux" qui sont simplement des dépôts git contenant un répertoire /home/. Il propose des commandes pour déplacer les fichiers de configuration existants dans le dépôt et les remplacer par des liens symboliques. Et pour lier symboliquement tous les fichiers du dépôt dans votre répertoire personnel sur une nouvelle machine.

Alors l'idée générale est de garder vos fichiers de configuration dans un système de contrôle de version, et de créer des liens symboliques vers eux depuis le chemin réel. De cette façon, votre dépôt n'a pas besoin de démarrer à partir de votre répertoire personnel et de contenir une tonne de fichiers que vous ne voulez jamais ajouter.

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

Je recommande également l'utilisation de nfs/samaba/sshfs. Un inconvénient est que si vous n'avez pas toujours accès au réseau, vous ne pouvez pas accéder à ce dont vous avez besoin (en vol, sans wifi, pare-feu, problèmes de routage, etc). Les machines que je garde synchronisées ne sont pas toutes accessibles en même temps mais je souhaite partager des informations entre elles.

Voici comment j'ai procédé en empruntant de nombreuses idées sur Internet.

Le fichier .bash_profile pourrait ressembler à ceci

$HOME/bin/shell_ssh_agent

J'ai trouvé cela à différents endroits mais je ne trouve pas de lien vers le moment. Le fichier shell_ssh_agent :

#!/bin/bash

SSH_ENV=$HOME/.ssh/environment

#echo "démarrage"

function start_agent {
    #echo "réapport d'agents"
    killall ssh-agent
    #echo "Initialisation d'un nouvel agent SSH..."
    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > ${SSH_ENV}
    #echo réussi
    chmod 600 ${SSH_ENV}
    . ${SSH_ENV}
    /usr/bin/ssh-add;
}

# Source des paramètres SSH, si applicable

if [ -f "${SSH_ENV}" ]; then
    . ${SSH_ENV}
    #echo "source de l'environnement ssh"
    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 reconnectez-vous et cela facilitera la vie.

Placez 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 clés ssh sont également utiles ici. Notez qu'à ce stade, vous auriez pu utiliser quelque chose comme nfs. Je reste néanmoins partisan d'un RCS pour une raison que je mentionne ci-dessous.

Le cas d'utilisation est

1. connexion première fois, les clés sont configurées
2. si un RCS n'est pas configuré, vérifiez vos scripts personnels (et mettez à jour/fusionnez si nécessaire, cela pourrait même faire partie de votre .bash_profile si vous le souhaitez)
3. modifier vimrc, scripts spéciaux, etc. et les valider
4. lorsque vous êtes connecté à d'autres machines, effectuez une mise à jour/fusion/checkout. Cela permet de tout synchroniser ; plus besoin de copier des fichiers que vous écrasez parfois et que vous ne vouliez pas écraser.
5. un avantage supplémentaire est que vous disposez de la puissance d'un RCS. Il m'arrive parfois de faire des changements indésirables dans des scripts ou configurations et de devoir revenir en arrière, etc.

Une chose que j'aimerais essayer ensuite est d'emballer la première connexion/configuration dans un makefile que je copie sur la nouvelle machine. Le makefile peut alors faire le travail de configuration de vos clés, RCS, etc. Bien sûr, il y a un certain surcoût ici mais si vous finissez par configurer beaucoup de machines, cela :

1. vous fait gagner du temps
2. facilite le maintien en synchronisation des configurations et scripts personnels des machines de développement
3. la gestion des modifications apportées aux scripts et configurations

J'utilise un makefile qui contient une liste de tous les serveurs auxquels je me connecte et lorsque je fais un changement sur ma machine locale, 'make' est exécuté automatiquement à l'aide du makefile, ce qui met à jour tous les serveurs avec les changements ou les plugins