Как привести .vimrc, когда я SSH?


34

Моя работа состоит в том, чтобы использовать SSH для подключения к различным машинам, а затем использовать vim для редактирования файлов на этих машинах. Проблема в том, что я должен постоянно копировать мой файл .vimrc. Очень раздражает открывать vim и не иметь никаких настроек. Можно ли перенести мои настройки vim с собой с машины на машину, не копируя ее везде вручную?


@ duffbeer703: да, как set background=darkили set background=lightчто-то, чего не касается ни один дистрибутив Linux и которое совершенно незаметно для пользователя. </ sarcasm>
Хуберт Карио

Пока не прочитав ответы, я чувствую, что это теоретически возможно, так как ssh-agent и x-term могут быть перенесены, но с другой стороны, они специально обрабатываются ssh, и я предполагаю, что есть несколько обходных путей для обработки сумасшедших крайних случаев ,
trysis

Ответы:


24

Я чувствую твою боль. У меня все мои ~ / .* rc файлы находятся под контролем версий (Subversion), отлично работает с тех пор, как я начал в 1998 году, используя CVS. Один из способов сделать это - проверить все ваши rc-файлы, например, когда вы находитесь в вашем домашнем каталоге:

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.

Таким образом, файлы конфигурации также будут синхронизироваться и обновляться на разных компьютерах при запуске svn update.


3
Я думаю, это так же хорошо, как и получается. Хитрость в том, что мне нужно настроить репозиторий на машине, доступной со всех других машин. С безопасной топологией сети это не всегда легко.
Апреч

Я начал делать это недавно, это удивительно. Я не знаю, как я выжил без этого.
Ричо

5
Возможно, используйте git или какую-либо другую распределенную систему контроля версий. В этом случае достаточно иметь доступ к машине, на которой проверяются файлы конфигурации.
Птман

44

Вместо того, чтобы выводить .vimrc на каждый сервер, с которым вам нужно поработать, почему бы не отредактировать удаленные файлы из вашего локального vim:

В vim / gvim запустите:

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

или запустите vim так:

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

Это открывает файл на месте (фактически копирует файл локально), а когда вы сохраняете, отсылает отредактированный файл обратно на сервер для вас.

Он запрашивает пароль ssh, но его можно упростить с помощью ключей ssh.

Как уже упоминали другие, единственным недостатком этого метода является то, что вы не получаете конкуренции путь / файл, как при работе непосредственно на компьютере.

Для получения дополнительной информации, проверьте следующий учебник .


+1 для подсказки scp: //, но я думаю, что это решение может быть немного громоздким, если вам нужно копировать путь каждый раз, когда вы редактируете файл.
Chmeee

1
Да, это слишком громоздко. Мне приходится много ходить по удаленным машинам, чтобы найти нужные мне файлы, и часто приходится редактировать с привилегией sudo.
Апреч

+1 это работает очень хорошо для меня. спасибо :)
Дарра Энрайт

Есть случаи , когда вам необходимо войти в главный сервер (login.example.com) , а затем оттуда входа на локальный сервер (top.secret.example.com)
PUK

Это хорошо работает, если вы смонтируете удаленную файловую структуру в локальный каталог, например, с помощью fusermount.
Рет

18

Вы можете создать скрипт bash, который будет автоматически копировать его при каждом входе в систему, например:

#!/usr/bin/env bash

scp ~/.vimrc $1:
ssh $1

Вы можете назвать это ssh_vim, например. Это не идеальное решение, но решит вашу проблему.

Вы можете улучшить его, чтобы сначала проверить, есть ли там уже. Если вы не всегда запускаете ssh с одного и того же компьютера, вы можете изменить скрипт, чтобы получить файл из scp с другого компьютера.

EDIT1

В связи с этим вы также можете смонтировать файловую систему удаленного компьютера с помощью sshfs. Таким образом, вы получаете выгоду от своей среды и инструментов (не только .vimrc), и у вас есть завершение оболочки (которого у вас нет с использованием scp: //).

EDIT2

Я только что узнал, что вы можете получить исходный файл .vimrc, используя scp: //, вот так:

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

Это работает из командной строки vim, но на данный момент я не знаю, как это автоматизировать. Кажется, он не работает ни с ключом -u, ни с .vimrc, ни с $ VIMINIT.

EDIT3

Я нашел это! Вы можете сделать это, чтобы запустить vim с помощью .vimrc, взятого из вашей ссылки:

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

Опция '-c' выполняет команду сразу после запуска vim.

Вы можете создать псевдоним в выбранной вами оболочке, чтобы не печатать. В bash это было бы так:

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

2
Это работает только если компьютер вы ssh'ing в может подключить обратно к компьютеру , вы ssh'ing с . Это не всегда так, например, если ваш компьютер находится за NAT.
trysis

11

Если вы используете аутентификацию с открытым ключом, вы можете использовать это в ~/.ssh/config:

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

Мне это нравится больше, чем предложенный выше трюк со скриптом, поскольку он не мешает вызову sshкоманды (при указании дополнительных параметров и т. Д.)


это лучшее. Для меня я должен был изменить , %u@%n:чтобы %r@%n:потому , что SSH имя пользователя отличается от имени пользователя моего лэптопа
Моше

4

Пара решений:

1) Создайте общий ресурс NFS для своей домашней папки и отобразите его в нескольких местах.

2) Создайте небольшой скрипт для отправки вашего .vimrc на сервер, к которому вы подключаетесь, с помощью файла идентификатора / ключа. Это может выглядеть примерно так (псевдокод):

connectString = arg0  #username@ipaddress

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

1
Ключи SSH решат проблему с паролем открытого текста.
LiraNuna

Какой инструмент вы бы использовали для создания общего ресурса NFS?
Вади М.

@LiraNuna - кажется, вы поймали меня до того, как у меня появился момент, и я отредактировал свой пост. @Wadih - NFSD обычно устанавливается в nix-системах по умолчанию. Вы также можете монтировать NFS-ресурсы по умолчанию (обычно).
Мошен

1
Совместное использование NFS является хорошей идеей, но, скорее всего, оно будет иметь ограниченные возможности для развертывания таких вещей, особенно в
защищенных от огня

Вы правы, Эрикслав. Я сделал предположение, что это были несколько машин в одной сети.
Мошен

4

Точно такой же ответ, как и у sunny256, но вместо SubVersion используйте git.

Держите одну основную ветвь с файлами, общими для всех компьютеров, и по одной ветке для каждого нового компьютера.

Таким образом, вы можете иметь почти одинаковые файлы на большинстве компьютеров, и при этом не запутаться.


+1 Небольшой вопрос: интересно, лучше ли использовать внешние определения для общих файлов в Subversion? Таким образом, вы можете получить их в одном месте и доставить в любую ветку
Евгений Ярмаш

3

Я знаю, что это старый поток, но я могу использовать sshfs, который монтирует файловую систему поверх fuse. Локальный vim выполняет все редактирование, поэтому нет причин копировать .vimrc.

У этого есть недостаток, что другой терминал должен быть открыт для любых команд, которые должны быть запущены на удаленном сервере, но для редактирования я считаю этот способ лучшим.

Он также имеет дополнительные преимущества использования системного буфера обмена.


2

Я использую https://github.com/andsens/homeshick для управления своими точечными файлами и их хранения на github.

Homeshick написан на 100% bash и помогает вам управлять "замками", которые являются просто git-репозиториями, содержащими каталог / home /. В нем есть команды для перемещения существующих точечных файлов в репозиторий и замены их символическими ссылками. И поставить символическую ссылку на все файлы в репозитории в ваш домашний каталог на новом компьютере.

Таким образом, общая идея заключается в том, чтобы хранить ваши точечные файлы в системе управления версиями и ссылаться на них с реального пути. Таким образом, репо не нужно начинать с домашнего каталога и содержать тонну файлов, которые вы никогда не захотите добавить.


Можете ли вы добавить информацию по ссылке? Это улучшит ответ и предоставит информацию, если ссылка не работает.
Дэйв М

1
Я объяснил некоторые операции и рассуждения. Я не видел смысла в копировании документации.
Аарон Макмиллин,

1

Если вы похожи на меня и у вас много машин разработки (в том числе и виртуальных) по разным причинам, вы можете комбинировать ssh-ключи, умный bash_profile и RCS по вашему выбору.

Во-вторых, я бы использовал nfs / samaba / sshfs. Одним из недостатков является то, что если у вас нет доступа к сети все время, то вы не можете получить доступ к тому, что вам нужно (полет, нет Wi-Fi, брандмауэры, проблемы с маршрутизацией и т. Д.). Машины, которые я синхронизирую, не все доступны одновременно, но я хочу поделиться информацией между ними.

Вот как я это сделал, позаимствовав много идей из Интернета.

.bash_profile может иметь что-то вроде этого

$HOME/bin/shell_ssh_agent

Я получил это из нескольких мест, но не могу найти ссылку на это сейчас. Файл 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

Теперь при первом входе вы настраиваете ключи. Выйдите и войдите, и это просто облегчит жизнь.

Поместите все свои сценарии в RCS, это упрощает синхронизацию машин для разработки. Я использую Git. Аутентификация с помощью git осуществляется через ssh, поэтому здесь также помогают ключи ssh. Обратите внимание, что в этот момент вы могли бы использовать что-то вроде NFS. Я все еще был бы поклонником RCS по причине, которую я упоминаю ниже.

Вариант использования

  1. войти в систему первый раз, ключи получить настройки
  2. если RCS не настроен, проверьте ваши личные сценарии (и обновите / объедините при необходимости, это может даже быть частью вашего .bash_profile, если вы этого хотите)
  3. редактировать vimrc, специальные скрипты и т. д. и фиксировать их
  4. при входе в систему на других машинах выполните обновление / слияние / оформление заказа. Это держит все в синхронизации; т.е. больше не нужно копировать файлы, которые вы иногда топаете и не хотите.
  5. В качестве дополнительной выгоды вы получаете мощь RCS. Я иногда делаю неблагоприятные изменения в скриптах или конфигах и мне нужно откатиться и тому подобное.

Что-то, что я хочу попробовать дальше, это обернуть начальный логин / настройку в make-файл, который я копирую на новый компьютер. Затем make-файл может выполнить настройку ваших ключей, RCS и т. Д. Очевидно, что здесь есть некоторые издержки, но если вы настроите много машин, это:

  1. экономия времени
  2. проще синхронизировать конфигурации и личные сценарии машин разработки
  3. управление изменениями в скриптах и ​​конфигах.

1

Я использую make-файл со списком всех серверов, на которых я вхожу, и когда я делаю изменения на своем локальном компьютере, «make» запускается с использованием make-файла автоматически, который обновляет все серверы любыми изменениями или плагинами.


Похоже на причудливый способ сделать сценарий. Make отлично подходит при создании одного файла из другого, но я не хотел бы использовать его в ситуации, когда каждое правило является " .PHONY."
Энтони


1

Я написал для этого простой инструмент, который позволит вам изначально переносить файл .vimrc всякий раз, когда вы используете ssh. , используя нестандартные опции встроенной конфигурации SSHd.

Никакие дополнительные svn, scp, copy/pasteи т.д. не требуется.

Это простой, легкий и работает по умолчанию на всех конфигурациях сервера, которые я тестировал до сих пор.

https://github.com/gWOLF3/viSSHous


0

Используя переменную VIMINIT:

export VIMINIT='set number'

и перенаправить его на удаленный сервер:

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

легко использовать .bash_profiles или .bashrc

export VIMINIT='
set number
'

export LC_VIMINIT=$VIMINIT

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

Теперь попробуйте запустить vim на удаленном сервере, используя sshh для подключения:

sshh remoteuser@remoteserver

Если Вы хотите, Вы можете также перенести свои плагины на удаленный сервер:

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

У меня такая же ситуация, но это не просто " .vimrc". У меня также есть такие вещи, как

  • конфигурация, подсказки и функции bash,
  • файлы конфигурации и авторизации ssh,
  • Сценарии оболочки мне бы хотелось иметь под рукой.
  • конечно, мой vimrc, но также некоторые функции vim и файлы подсветки синтаксиса.

Мое решение (изначально начатое 30 лет назад с "dist"!) - установить ночной cron для минимальной домашней настройки rsync для всех машин, на которых я работаю, чтобы он обновлялся по ночам.

Таким образом, все остальные машины, с которыми я работаю, постоянно обновляются! Я могу просто добавить новый компьютер в список «учетных записей» и выполнить раздачу одного компьютера, чтобы запустить его.

Не нужно быть много, и вы можете начать с малого и сделать его более сложным, как вы идете. Как вы можете себе представить, через 30 лет моё распространение стало довольно сложным, поэтому я не буду здесь его размещать. Излишне говорить, что он также выполняет такие функции, как замена некоторых конфигураций для других в некоторых сетях, очистка дома (например, корзина, файлы кэша), проверка правильности разрешений для дома и т. Д.

ПРИМЕЧАНИЕ. Я разрешаю только ssh-вход без пароля с одного «домашнего» компьютера всем остальным, никогда больше не вернусь! Любой кросс SSH защищен паролем.


-1

Вы можете рассмотреть сценарий EXPECT, который позволяет вам задавать путь и среду (например, переменные EXRC) при нажатии определенной клавиши. Не должно быть слишком долго, прежде чем кто-то отправит подобный сценарий.

Когда число ваших серверных ферм превышает несколько десятков (если не считать тысяч), то что-то легко настроить вашу среду на «девственную» коробку - настоящая жизнь

Часто, когда я захожу в ящик, он впервые создает мой homedir!


Ожидайте, что это очень хрупкий способ сделать что-нибудь. Другая ОС, Архитектура или даже обновление, и оно может сломаться. Хорошо для чего-то маленького, но не расширяемого со временем.
Энтони

-1

Это было реализовано с помощью bash oneliner. Поскольку это делается с помощью Подстановки процессов, временные файлы не создаются.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.