Como trazer .vimrc quando eu SSH?


34

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


@ duffbeer703: sim, como set background=darkou set background=light, algo que nenhuma distribuição Linux toca e é completamente discreta para o usuário. </sarcasm>
Hubert Kario

Sem ter lido as respostas ainda, sinto que isso é teoricamente possível, pois ssh-agent e x-term podem ser transferidos, mas por outro lado, esses são tratados especificamente pelo ssh e presumo que haja várias soluções alternativas para lidar com casos extremosos .
trysis

Respostas:


24

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

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.


3
Eu acho que isso é tão bom quanto ele ganha. O truque é que eu tenho que configurar um repositório em uma máquina acessível a partir de todas as outras máquinas. Com uma topologia de rede segura, isso nem sempre é fácil.
Apreche 30/06/09

Comecei a fazer isso recentemente, é incrível. Não sei como sobrevivi sem ele.
Richo

5
Talvez use git ou algum outro sistema de controle de versão distribuído. Nesse caso, é suficiente ter acesso a uma máquina na qual os arquivos de configuração são retirados.
precisa saber é

44

Em vez de trazer .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://remoteuser@server.tld//path/to/document

ou inicie o vim assim:

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

Isso abre o arquivo com perfeição no lugar (na verdade, ele copia o arquivo localmente) e, quando você salva, envia o arquivo editado de volta ao servidor para você.

Ele solicita uma senha ssh, mas isso pode ser simplificado através das teclas ssh.

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

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


+1 para a dica scp: //, mas acho que essa solução pode ser um pouco complicada se você precisar copiar o caminho sempre que editar um arquivo.
chmeee

1
Sim, isso é muito pesado. Eu tenho que vasculhar as máquinas remotas para encontrar os arquivos que eu quero, e muitas vezes tenho que editar com o privilégio sudo.
Apreche 30/06/09

+1 isso funciona muito bem para mim. Obrigado :)
Darragh Enright

Há casos em que você precisa para entrar em um servidor principal (login.example.com) depois de lá de login para um servidor local (top.secret.example.com)
puk

Funciona bem se você montar a estrutura de arquivos remotos no diretório local, por exemplo, com fusermount.
relet 03/07

18

Você pode criar um script bash para copiá-lo automaticamente toda vez que efetuar 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 aprimorá-lo para verificar primeiro se já existe. Se você não está sempre executando o ssh na mesma máquina, pode alterar 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 do seu ambiente e ferramentas (não apenas .vimrc) e possui a conclusão do shell (que você não tem usando o scp: //).

EDIT2

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

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

Isso funciona a partir da linha de comando do vim, mas no momento não sei como automatizá-lo. Parece não funcionar com a opção '-u' nem no .vimrc nem no $ 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 no shell de sua escolha para evitar digitar. No bash, seria assim:

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

2
Isso só funciona se o computador que está ssh'ing em pode ligar de volta para o computador que está ssh'ing partir . Isso nem sempre é o caso, por exemplo, se o seu computador estiver atrás do NAT.
trysis

11

Se você estiver usando autenticação de chave pública, poderá usá-lo em ~/.ssh/config:

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

Gosto mais do que o truque de script sugerido acima, pois não atrapalha a chamada do sshcomando (ao especificar parâmetros extras, etc.)


isso é o melhor. Para mim, eu tive que mudar %u@%n:para %r@%n:porque os difere ssh nome de usuário de nome de usuário do meu laptop
Moshe

4

Algumas soluções:

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

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

connectString = arg0  #username@ipaddress

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

1
As chaves ssh resolverão o problema da senha de texto sem formatação.
LiraNuna

qual ferramenta você usaria para criar um compartilhamento NFS?
29409 Wadih M.

@LiraNuna - parece que você me pegou antes do meu 'duh' momento e editou o meu post. @Wadih - NFSD geralmente é instalado nos sistemas 'nix por padrão. Você também pode montar compartilhamentos NFS por padrão (geralmente) também.
moshen

1
Compartilhamento NFS é uma boa idéia, mas provavelmente vai funcionar em capacidade limitada para implantar essas coisas, especialmente em ambientes protegidos por firewall ou locais onde você não deseja modificar servidores de produção (especialmente com NFS)
ericslaw

Você está correto. Eu assumi que eram várias máquinas em uma única rede.
moshen

4

Exatamente a mesma resposta que sunny256, mas use git em vez de SubVersion.

Mantenha uma ramificação principal com os arquivos comuns a todos os computadores e tenha uma ramificação para cada novo computador.

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


+1 Uma pequena pergunta: será que é melhor usar definições externas para os arquivos comuns no subversion? Dessa forma, você pode tê-los em um só lugar e buscar em qualquer ramo #
Eugene Yarmash

3

Eu sei que este é um thread antigo, mas uma maneira de fazê-lo é usando sshfs que monta o sistema de arquivos sobre o fusível. O vim local faz toda a edição, portanto não há motivo para copiar .vimrc.

Isso tem a desvantagem de que outro terminal precisará ser aberto para todos os comandos que precisam ser executados no servidor remoto, mas, para edição, acho o melhor assim.

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


2

Estou usando https://github.com/andsens/homeshick para gerenciar meus arquivos de ponto e armazená-los no github.

O Homeshick é escrito em 100% do bash e ajuda a gerenciar "castelos", que são apenas repositórios git que contêm um diretório / home /. Possui comandos para mover arquivos de ponto existentes para o repositório e substituí-los por links simbólicos. E para vincular todos os arquivos no repositório ao diretório inicial em uma nova máquina.

Portanto, a idéia geral é manter seus arquivos de ponto em um sistema de controle de versão e vincular-lhes o caminho real. Dessa forma, seu repositório não precisa iniciar no diretório inicial e conter uma tonelada de arquivos que você nunca deseja adicionar.


Você pode adicionar algumas informações a partir do link? Isso melhoraria a resposta e forneceria informações se o link quebrar.
Dave M

1
Expliquei algumas das operações e raciocínio. Não vi valor ao copiar a documentação.
Aaron McMillin

1

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

Gostaria 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 (vôo, sem wifi, firewalls, problemas de roteamento etc.). As máquinas que eu mantenho sincronizadas não são acessíveis ao mesmo tempo, mas quero compartilhar informações entre elas.

A seguir, é como eu pedi muitas idéias da Internet.

.bash_profile poderia ter algo parecido com isto

$HOME/bin/shell_ssh_agent

Consegui 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. Saia e entre e isso tornou a vida mais fácil.

Coloque todos os seus scripts em um RCS, para facilitar a sincronização das máquinas de desenvolvimento. Eu uso git. A autenticação com o git é via ssh, então as teclas ssh também ajudam aqui. Observe que, nesse ponto, você poderia ter usado algo como o nfs. Eu ainda seria 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 os comprometa
  4. quando conectado a outras máquinas, faça uma atualização / mesclagem / checkout. Isso mantém tudo sincronizado; ou seja, não há mais cópia de arquivos que às vezes você pisa e não quer.
  5. Como benefício colateral, 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 coisas assim.

Algo que eu quero tentar a seguir é agrupar o login / configuração inicial em um makefile que copio para a nova máquina. O makefile pode fazer o trabalho de configurar suas chaves, RCS, etc. Obviamente, existem algumas despesas gerais aqui, mas se você acabar configurando muitas máquinas, é isso:

  1. uma economia de tempo
  2. É mais fácil manter sincronizadas as configurações e os scripts pessoais das máquinas de desenvolvimento
  3. gerenciamento de alterações em scripts e configurações.

1

Eu uso um makefile que possui uma lista de todos os servidores nos quais efetuo logon e, quando faço uma alteração na máquina local, 'make' é executado usando o makefile automaticamente, que atualiza todos os servidores com alterações ou plugins


Parece mais uma maneira elegante de fazer um script. O Make é ótimo ao criar um arquivo a partir de outro, mas eu não gostaria de usá-lo em uma situação em que todas as regras sejam " .PHONY."
anthony

1

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


1

Eu escrevi uma ferramenta simples para isso que permitirá que você transporte nativamente seu arquivo .vimrc sempre que você ssh , usando as opções de configuração internas do SSHd de uma maneira não padrão.

Sem adicional svn, scp, copy/paste, etc necessário.

É simples, leve e funciona por padrão em todas as configurações de servidor que testei até agora.

https://github.com/gWOLF3/viSSHous


0

Usando a variável VIMINIT:

export VIMINIT='set number'

e encaminhá-lo 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, também pode levar seus plugins para o servidor remoto:

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

Eu tenho a mesma situação, mas não é apenas " .vimrc". Eu também tenho coisas como

  • configuração, solicitação e funções do bash,
  • arquivos de configuração e autorização ssh,
  • scripts de shell que eu gosto de ter à mão.
  • é claro meu vimrc, mas também algumas funções do vim e arquivos de destaque de sintaxe.

Minha solução (iniciada há 30 anos com "dist" originalmente!) É configurar um cron noturno para sincronizar uma configuração inicial mínima para todas as máquinas em que trabalho, para que seja atualizada todas as noites.

Dessa forma, todas as outras máquinas com as quais trabalho são mantidas atualizadas! Posso apenas adicionar uma nova máquina à lista de 'contas' e fazer uma distribuição de máquina única para iniciá-la.

Não precisa ser muito, e você pode começar pequeno e torná-lo mais complexo à medida que avança. Como você pode imaginar, após 30 anos, minha distribuição agora é bastante complexa, então não vou colocá-la aqui. Escusado será dizer que também faz coisas como trocar algumas configurações por outras em algumas redes, limpeza doméstica (EG: lixo, arquivos de cache), garantir que as permissões domésticas estejam todas corretas e assim por diante.

NOTA Só permito o login ssh sem senha de uma máquina 'doméstica' para todo o resto, nunca mais! Qualquer cross ssh é protegido por senha.


-1

Você pode considerar um script EXPECT que permite definir seu caminho e ambiente (como variáveis ​​EXRC) ao pressionar uma certa tecla. Não deve demorar muito para que alguém poste um script semelhante.

Quando seus farms de servidores somam mais de algumas dezenas (pense em milhares), ter algo facilmente configurando seu ambiente em uma caixa 'virgem' é um verdadeiro salva-vidas

Muitas vezes, quando faço login em uma caixa, ele cria minha casa pela primeira vez!


Esperar é uma maneira muito frágil de fazer qualquer coisa. Um SO diferente, arquitetura ou até mesmo uma atualização, e pode quebrar. Aprovação para algo pequeno, mas não expansível com o passar do tempo.
anthony

-1

Foi realizado com o seguinte bash oneliner. Como é feito com a Substituição de 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)'

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.