Como trazer .vimrc quando eu SSH?

33

Meu trabalho tende a envolver o SSH para se conectar a várias máquinas e, em seguida, usar o vim para editar arquivos nessas máquinas. O problema é que eu tenho que copiar constantemente o meu arquivo .vimrc. É muito chato abrir o vim e não ter configurações. É possível transportar minhas configurações do vim comigo de uma máquina para outra, sem copiá-las manualmente em todos os lugares?

    
por Apreche 29.06.2009 / 20:56

14 respostas

22

Eu sinto sua dor. Eu tenho todos os meus arquivos ~ /.* rc sob controle de versão (Subversion), tem funcionado muito desde que comecei em 1998, usando o CVS. Uma maneira de fazer isso é checar todos os seus arquivos rc assim quando você estiver no seu diretório home:

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.

Dessa forma, os arquivos de configuração também serão sincronizados e atualizados nos vários computadores quando você executar o svn update.

    
por 29.06.2009 / 21:41
43

Em vez de trazer o .vimrc para cada servidor em que você precisa trabalhar, por que não editar os arquivos remotos do seu vim local:

No vim / gvim, execute:

:e scp://[email protected]//path/to/document

ou inicie o vim assim:

vim scp://[email protected]//path/to/document

Isso abre o arquivo de forma eficiente (na verdade, ele copia o arquivo localmente) e, quando você salva, ele envia o arquivo editado de volta ao servidor para você.

Ele pede uma senha ssh, mas isso pode ser simplificado via chaves ssh.

Como outros já mencionaram, a única desvantagem desse método é que você não obtém a competição caminho / arquivo como faria ao trabalhar diretamente na máquina.

Para mais informações, confira o seguinte tutorial .

    
por 29.06.2009 / 21:30
18

Você pode criar um script para copiá-lo automaticamente toda vez que fizer login, assim:

#!/usr/bin/env bash

scp ~/.vimrc $1:
ssh $1

Você pode chamá-lo de ssh_vim, por exemplo. Não é uma solução ideal, mas resolverá seu problema.

Você pode melhorá-lo para verificar primeiro se já existe. Se você não está sempre executando o ssh da mesma máquina, você pode mudar o script para obter o arquivo do scp de outra máquina.

EDIT1

Em uma nota relacionada, você também pode montar o sistema de arquivos da máquina remota com sshfs. Dessa forma você se beneficia de seu ambiente e ferramentas (não apenas .vimrc) e você tem o shell completion (que você não tem usando scp: //).

EDIT2

Acabei de descobrir que você pode criar seu arquivo .vimrc usando scp: //, assim:

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

Isso funciona na linha de comando do vim, mas no momento não sei como automatizá-lo. Não parece funcionar com o comutador '-u' nem com o .vimrc nem com o $ VIMINIT.

EDIT3

Eu encontrei! Você pode fazer isso para iniciar o vim com um .vimrc retirado do seu host de referência:

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

A opção '-c' executa o comando logo após o lançamento do vim.

Você pode criar um alias em seu shell de escolha para evitar a digitação. No bash seria assim:

alias vim="vim -c ':source scp://you@your_computer//yourpath/.vimrc'"
    
por 29.06.2009 / 21:24
7

Se você estiver usando a autenticação por chave pública, poderá usar isso em ~/.ssh/config :

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

Eu gosto mais do que o truque de script sugerido acima, já que ele não atrapalha a invocação do comando ssh (ao especificar parâmetros extras, etc.)

    
por 22.05.2015 / 15:18
4

Algumas soluções:

1) Crie um compartilhamento NFS para sua pasta pessoal e mapeie-o em vários locais.

2) Crie um script pequeno para enviar seu .vimrc para o servidor ao qual você está se conectando com um arquivo de identidade / chave. Poderia ser algo como isto (pseudocódigo):

connectString = arg0  #username@ipaddress

scp -i ~/.ssh/indentity connectString:~/ ~/.vimrc
ssh -i ~/.ssh/indentity connectString
    
por 29.06.2009 / 21:15
4

A mesma resposta exata que sunny256, mas use git ao invés de SubVersion.

Mantenha um ramo principal com os arquivos comuns a todos os computadores e tenha um ramo para cada novo computador.

Dessa forma, você pode ter quase os mesmos arquivos na maioria dos computadores e ainda não se confundir.

    
por 30.06.2009 / 07:10
3

Eu sei que este é um thread antigo, mas uma maneira que eu faço é usar o sshfs que monta o sistema de arquivos sobre o fusível. O vim local faz toda a edição, então não há razão para copiar .vimrc por aí.

Isso tem a desvantagem de que outro terminal terá que estar aberto para quaisquer comandos que precisem ser executados no servidor remoto, mas para edição eu acho assim o melhor.

Ele também tem o benefício adicional de poder usar a área de transferência do sistema.

    
por 25.06.2013 / 21:34
2

Estou usando o link para gerenciar meus dotfiles e armazená-los no github.

Homeshick é escrito em 100% bash e ajuda você a gerenciar "castles", que são apenas git repos que contêm um diretório / home /. Ele possui comandos para mover arquivos de ponto existentes para o repositório e substituí-los por links simbólicos. E para ligar simbolicamente todos os arquivos no repositório em seu diretório pessoal em uma nova máquina.

Portanto, a idéia geral é manter seus dotfiles em um sistema de controle de versão e criar links simbólicos para eles a partir do caminho real. Desta forma, o seu repo não precisa ser iniciado a partir do diretório home e conter uma tonelada de arquivos que você não deseja adicionar.

    
por 01.11.2013 / 16:12
1

Se você é como eu e tem muitas máquinas de desenvolvimento (Máquinas Virtuais também) por vários motivos, você pode combinar chaves ssh, um bash_profile inteligente e um RCS de sua escolha.

Eu ficaria em segundo usando nfs / samaba / sshfs. Uma desvantagem é que, se você não tiver acesso à rede o tempo todo, não poderá acessar o que precisa (voar, sem wifi, firewalls, problemas de roteamento etc.). As máquinas que eu mantenho em sincronia não são todas acessíveis ao mesmo tempo, mas eu quero compartilhar informações entre elas.

O seguinte é como eu fui emprestar muitas idéias da Internet.

.bash_profile poderia ter algo assim

$HOME/bin/shell_ssh_agent

Eu tenho isso em alguns lugares, mas não consigo encontrar um link para ele agora. O arquivo 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

Agora, no primeiro login, você configura suas chaves. Efetue logout e entrada e apenas facilite a vida.

Coloque todos os seus scripts em um RCS, o que facilita a sincronização das máquinas de desenvolvimento. Eu uso o git. Autenticação com git é via ssh so chaves ssh ajudam aqui também. Note que neste momento você poderia ter usado algo como nfs. Eu ainda seria um fã de um RCS por uma razão que menciono abaixo.

O caso de uso é

  1. faça o login pela primeira vez, as chaves são configuradas
  2. se o RCS não estiver configurado, verifique seus scripts pessoais (e atualize / mescle quando necessário, isso pode até fazer parte do seu .bash_profile se você quiser)
  3. edite o vimrc, scripts especiais, etc. e confirme-os
  4. quando conectado a outras máquinas, faça uma atualização / mesclagem / checkout. Isso mantém tudo em sincronia; ou seja, não há mais arquivos de cópia que às vezes você pisa e você não queria.
  5. como benefício secundário, você obtém o poder de um RCS. Às vezes, faço alterações desfavoráveis em scripts ou configurações e preciso reverter e assim por diante.

Algo que eu quero tentar agora é colocar o login / setup inicial em um makefile que eu copio para a nova máquina. O makefile pode então fazer o trabalho de configurar suas chaves, RCS, etc. Obviamente, há alguma sobrecarga aqui, mas se você acabar configurando muitas máquinas, isto é:

  1. uma poupança de tempo
  2. mais fácil manter as configurações e scripts pessoais das máquinas de desenvolvimento em sincronia
  3. gerenciamento de alterações em scripts e configurações.
por 29.06.2009 / 22:13
1

Eu uso um makefile que tem uma lista de todos os servidores que eu faço logon e quando faço uma alteração em minha máquina local, 'make' é executado usando o makefile automaticamente, que atualiza todos os servidores com quaisquer alterações ou qualquer plugins

    
por 28.01.2011 / 08:51
1

sshrc resolve o problema. Você coloca seu .vimrc em ~ / .sshrc.d / e depois adiciona export VIMINIT="let \$MYVIMRC='$SSHHOME/.sshrc.d/.vimrc' | source \$MYVIMRC" em '/.sshrc.

    
por 22.04.2015 / 23:34
0

Você pode considerar um script EXPECT que permite definir seu caminho e ambiente (como variáveis EXRC) ao pressionar um determinado pressionamento de tecla. Não deve demorar muito até que alguém ponha um script similar.

Quando seu número de farms de servidores é maior do que algumas dúzias (pense em milhares), ter algo facilmente configurado em seu ambiente em uma caixa 'virgem' é um verdadeiro salva-vidas

Muitas vezes, quando eu faço login em uma caixa, ele cria meu homedir pela primeira vez!

    
por 30.06.2009 / 03:21
0

Usando a variável VIMINIT:

export VIMINIT='set number'

e encaminhando para o servidor remoto:

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

é fácil usando .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'

Agora tente executar o vim no servidor remoto usando sshh para conexão:

sshh remoteuser@remoteserver

Se você quiser, pode levar seus plugins para o servidor remoto também:

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
}
    
por 12.07.2018 / 16:14
-1

Foi realizado com o seguinte bash oneliner. Como isso é feito com a Substituição do Processo, os arquivos temporários não são criados.

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

link

    
por 28.09.2018 / 04:50