VimCommander: работаем с удалённой системой по ssh

    Прелюдия


    Пользовался я ViM'ом и был доволен. Как-то раз узнал, что он ко всей его могучести умеет быть небольшим проводником по файловой системе (прим. достаточно выполнить vim .). Позже раскопал, что гораздо удобнее это делать добавив плагин NERD_Tree — он действительно удобен и я был бы рад если бы на его основе был сделан VimCommander, однако Leandro (автор VimCommander) пошёл другим путём и старался подражать MidnightCommander. Ну что ж, надо обучить VC работать с удаленными системами по ssh, решил я, ведь его старший брат (mc) вполне неплохо делает это. Примерно с такими мыслями я открыл shell и набрал vim ~/.vim/plugin/vimcommander.vim.

    Идеи


    Реализовывать такой функционал на чистом ssh клиенте ни какого желания и возможностей у меня не было, но тут вспомнилась мне одна утилита — sshfs

    Мысли как всегда шли у меня не от проектирования к реализации, а наоборот (а что поделать)…
    Первое что пришлось придумать, а вернее собрать из имеющегося опыта, так это синтаксис команды и как её удобнее вызывать. Работа через sshfs дала удобство в том, что мне не пришлось парсить файл ~/.ssh/config на тот случай если у пользователя там есть алиасы, утилита как ей и положено всё делает сама.
    Синтаксис для ввода адреса был выбран незамысловатый: [IdentityFile,][UserName@]HostName[:Port]. Конечно, некоторых усилий стоило проверить и распарсить строку для подключения, что бы наиболее грамотно скормить её sshfs (зачем нам лишние ошибки?).

    Вызывать всё это добро было решено более-менее по аналогии с MC клавишей F9 (надо всё-таки сохранить идеологию автора VimCommander, который взял все горячии клавиши именно от туда). Богатое меню там, конечно, не вылезет, но моя функция вызовется :-). И задаст пару вопросов. Какие тут вопросы можно было подумать? Однако они тут играют весьма важную роль.

    Логика работы


    Первое, что надо понять — подключение само не отваливается, при закрытии VimCommander и даже всех копий ViM'а (в MC все разорвётся при выходе). Как результат получаем первый вопрос от мастера: What are you want to do (mount/dismount/abort) sshfs? [mda]:. И так, всё, что смонтировали надо отключать самим (перезагрузка машины, конечно, спасёт отца русской демократиирешит проблему, но часто ли вы ребутите свою машину?).
    Тут вдадимся немного в архитектуру: всё, что в данный момент примонтировано, записано в файл /tmp/ssh_dir.list. Точки для монтирования, кстати, создаются там же — в /tmp/, с рандомным именем (спасибо /dev/urandom). Получается, что вы можете поработать с удалённой системой, выйти из ViM и через некоторые время вернуться к работе, и не монтировать удалённую систему заново.
    Вопрос о размонтировании также не умудрён: Choose which mount point you want to dismont: /tmp/CEc6CgFeRE0U(192.168.0.1);/tmp/4BEK8QqtWqWT(habrahabr.ru). Надо просто указать порядковый номер больше не интересующего хоста.

    обмен картинками Xmages.net

    Изменённый текст скрипта vimcommander.vim прилагается (внутри есть еще небольшие изменения других функций, так что кому надо могут взять только описанную функцию (откатится на интересующий commit), остальные изменения, когда их подкопится опишу отдельно).

    Чего не хватает


    1. Мб стоило бы добавить функцию размонтировать всё.
    2. Возможно, не помешает список смонтированных хостов, хотя его можно увидеть через dismount.
    3. Так же код и «приглашения» далеки от совершенства…

    P.S. есть и другие вещи которых мне не хватает в VimCommander, будет время состряпаю и их.

    Главное — наслаждаться работой в ViM.




    Все изменения были залиты по просьбе Leandro Penz (автора VimCommander) на GitHub, надеюсь, что он смержит их со своей веткой.
    Мой форк: github.com/Alukardd/vimcommander
    Основной проект: github.com/lpenz/vimcommander
    Страничка скрипта: www.vim.org/scripts/script.php?script_id=808

    UPD: Провёл небольшой рефакторинг кода, заодно исправил пару багов.
    Так же небольшое примечание: sshfs работает по sftp протоколу, поэтому на серверной стороне он должен быть активен.

    Комментарии 10

      –3
      Гиковско
        +2
        А вы можете объяснить, в чем смысл использования текстового редактора в качестве файлового менеджера? Я без претензий и подколов, просто интересно понять ход ТруЪнердомыслительного процесса. Жаст фо фан?
          0
          Сам сабжем не пользовался, но полагаю, что профит в удобной навигации по hjkl и виме щаместо мцедит.
            0
            Согласен с вами, тут явно «just for fan» = автор так и написал «Главное — наслаждаться работой в ViM». Ну вот нравится ему vim и все тут :)
            За себя скажу — что использую с этой же целью MC — он по ssh многое умеет: и каталоги читать; и файлы — копировать, стирать, переименовывать; и редактировать в нужном вам редакторе(меня mcedit устраивает, но никто не запрещает vim запускать). Еще Midnight Commander использует стандартные ssh и scp без монтирования sshfs через fuse — последнее не очень хорошо работает на нестабильных каналах.

            п.с:
            А автор молодец — просто делает то что ему нравится и кому то его детище обязательно пригодится :)
              0
              Сам сабжем не пользовался, но думаю это делается для того, что бы консолидировать свою работу на одном приложении.
                0
                И это тоже, намного удобнее держать открытой одну вкладку терминала и в ней ViM с кучей табов, чем несколько вкладок и в каждой по ViM'у.
                  +1
                  Имхо, упор на одно мощное и расширяемое приложение в повседневной работе — это круто, удобно, эффективно!

                  Как я это вижу (гипотетическое «приложение Z»):
                  * в основе мощный редактор и файловый менеджер (две панели — это must have)
                  * имеем свой «мультиплексор терминалов», или же умеем обоюдоостро встраиваться во внешний мультиплексор с той же идеологией
                  * имеем must-have интеграцию с ком.строкой, и фичи (часть от мультиплексора терминалов, часть наподобие «выполнить команду прямо из редактора, а ее stdout подать сюда же в текст» и т.д.)
                  * любой доп. функционал сводится или к потенциально глубоко проникающему в «Z» вызову ком. строки, либо к «панели/списку/дереву» файлового менеджера, либо к редактируемому тексту с доп. нагрузкой (или ко всем ним одновременно).
                  * выстраиваем единую систему шорткатов / аккордов / макросов / скриптов потенциально неограниченной сложности

                  В результате мы получаем вещь, перекрывающую 90% потребностей разработчика / сисопа /…
                  и из которой можно практически не вылезать.

                  Критериям «приложения Z» удовлетворяют:
                  *nix: ViM с наворотами / Emacs с наворотами / mc с наворотами (+ screen и прочие радости по вкусу)
                  Win: Far Manager + ConEmu + FarNet + еще навороты + порты coreutils из MinGW +… (все FOSS, кстати)

                  Считаю, что парадигму «приложения Z» следует развивать и продвигать в массы, ибо скорость и эфективность работы возрастают неимоверно, а довольно нетривиальные задачи (которые под виндами, скажем, порождают монстров шароваростроения, а под никсами — коллекции не менее нетривиальных скриптов) решаются интуитивно.

                  А детско-бухгалтерские интерфейсы — детям и бухгалтерам!
                  0
                  А извиняюсь)))
                  Я стёр старую прелюдию…
                  Если вкратце, то на работе приходится(приходилось) пользоваться mc, а мне он не нравится, а вот ViM я люблю…
                  0
                  Есть же Vifm
                    0
                    Vifm это не ViM и даже ни его продолжение, а отдельное приложение с горячими клавишами как в ViM, причем степень их полноты и соответствия не является очевидным фактом.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое