Comment importer .vimrc quand je suis SSH?

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?

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.

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://[email protected]//path/to/document

ou lancez vim comme ceci:

vim scp://[email protected]//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 .

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'"

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.)

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

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.

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.

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.

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.

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.

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.

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

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
}

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.

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!

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