В своей работе мне приходится проводить чуть ли не все свое время в консоли, как в локальной, так и в удаленной. Нет, что вы, я не жалуюсь, даже наоборот — мне нравятся возможности автоматизации, которые предоставляют консольные инструменты, и работа в консоли вполне продуктивна.

Но если вы проводите за своим инструментом до 80% рабочего времени, то желательно убедиться, что вы не тратите время впустую и что работа доставляет вам удовольствие. В этой статье я бы хотел немного рассказать про те инструменты, которыми я лично пользуюсь каждый день, и про то, как они улучшают user experience (и, часто, продуктивность) при работе с консолью и с удаленными серверами в частности.

Проблемы ssh


При работе с удаленными серверами по ssh есть много вещей, которые могут фрустрировать, но основных проблем две, и первая из них принципиально неразрешима в рамках ssh:

  1. При высоком round-trip latency (>100 ms) пользовательский ввод появляется с ощутимой задержкой, а при использовании мобильного интернета с edge (latency 1000 ms) работа становится подобна пытке
  2. При временных проблемах (несколько минут) с доставкой пакетов, соединение может порваться с write failed: broken pipe, причем узнаете вы об этом только при попытке ввода или при использовании настроек вроде keepaliveinterval


Первая проблема неразрешима потому, что ssh by-design является просто транспортом для байтов, и существующие приложения на это поведение расчитывают. Поскольку ssh не пытается интерпретировать этот поток байтов, он не может осуществлять предиктивный ввод. Лично для меня именно эта проблема наиболее актуальна, поскольку мне приходится работать с серверами в европе и США, и во втором случае задержка составляет около 200 мс и является принципиально неустранимой, по крайней мере до изобретения квантовой коммуникации или чего-нибудь подобного. Вторая же проблема проявляется в наших условиях относительно редко, но всё же неприятно переустанавливать все соединения при сбоях сети (и перезапускать упавшие приложения, если они почему-то не были запущены в screen).



Решение — mosh (MObile SHell)


Решение указанных выше проблем весьма радикально — mosh ( mosh.mit.edu ) представляет из себя отдельную клиент-серверную систему, работающую по UDP и посылающую диффы экрана вместо подхода, используемого SSH, который передает байты «как есть». Изначальное соединение происходит по ssh, но ssh лишь запускает mosh-server и выходит после этого. Из-за этого подключение к серверу с использованием mosh происходит немного дольше, чем просто по SSH.

Для того, чтобы работать через mosh вместо ssh, нужно установить mosh-клиент к себе на компьютер и mosh-server на удаленный хост. В целом, не обязательно его устанавливать общесистемно — демон работает из-под пользователя, и при соединении можно указать бинарник сервера (пример: mosh --server /home/yuriy/bin/mosh-server my-server-hostname).

Поскольку mosh посылает диффы экрана по udp, он очень сильно отличается по своим свойствам от привычного ssh через tcp/ip:

Соединение никогда не рвется
Нет никакого «соединения». При восстановлении связности сети вы снова начинаете видеть текущее состояние консоли. Вы можете также менять способ подключения к серверу, например поменять wi-fi точку доступа, и все продолжит работать. Это особенно удобно при использовании VPN через мобильный интернет, который представляет из себя образец нестабильности.

Забудьте про возможность скроллить историю колесом мыши
Локальная прокрутка не будет работать, так как mosh рисует все в альтернативном экране, и показывает только разницу с предыдущим состоянием, не пересылая остальное. Для того, чтобы история сохранялась хоть куда-нибудь, необходимо использовать screen или tmux, о котором будет рассказано далее. С некоторым напильником все же можно заставить колесо мыши работать, но ощущения все равно будут «не те».

При высокой latency включается предиктивное echo
Если вы, к примеру, используете SSH через EDGE, то я вам очень не завидую :). В этом случае mosh умеет «понимать», в каком контексте он сейчас работает и в большинстве случаев способен адекватно отображать ваш ввод еще до того, как хоть что-то придет с сервера. На иллюстрации ниже «подчеркнутый» текст — это текст, введенный пользователем, но эхо (в большинстве случаев — просто введенный пользователем текст) с сервера еще не получено. Также, даже в случае не слишком высокой latency (например, 50мс, уже заметные на глаз), mosh старается показать пользовательский ввод мгновенно, если «уверен», что в данный момент с сервера просто возвращается введенный текст. Таким образом, в случае latency порядка 50-100 мс, работа в удаленной консоли становится практически неотличимой от локальной. За исключением возможности увидеть историю, как было упомянуто выше.



Все указанные вещи достигаются за счет того, что сервер тоже «рендерит» вывод из консоли и держит текущее состояние экрана у себя в памяти. В трекере mosh'а есть предложения уметь хранить еще и историю, чтобы можно было отказаться от дополнительной прослойки в виде screen/tmux, но пока что авторы ничего не сделали в этом направлении.

Давайте теперь перейдем к тому, что такое tmux и чем он лучше screen:

Проблемы screen


К сожалению, я не большой знаток screen, поэтому из проблем я бы мог назвать только две — отсутствие поддержки разделения экрана по вертикали (вместо горизонтального по умолчанию) и медленное развитие в целом из-за очень старой кодовой базы. Удобство использования у screen тоже оставляло желать лучшего. Поддержку разделения по вертикали запилили в новой версии screen 4.2, но к тому моменту я лично уже перестал им пользоваться. В целом, screen по-прежнему является стандартом де-факто, как и ssh, и нельзя его списывать со счетов.

Что такое tmux и его преимущества перед screen


Если вы никогда не слышали о терминальных мультиплексорах (Terminal MUltipleXor), то предыдущий абзац вам вряд ли будет понятен. Поэтому, расскажу немного про то, что это такое:

Представьте себе ситуацию, что вы хотите запустить какую-то длительную операцию по ssh, и у вас отваливается соединение. Или вы не хотите ждать ее завершения, потому что эта команда представляет из себя «while true; do run-daemon; done». По умолчанию, интерактивные сессии посылают сигнал SIGHUP всем процессам из этой сессии при отключении, и процессы завершаются.

Эту проблему можно решать по-разному, например использовать команду nohup, которая перенаправляет вывод в файлы и игнорирует SIGHUP. Но более интересным решением является использование терминальных мультиплексоров, например screen или tmux. При первом запуске обычно стартует новая сессия, в которой вы можете работать, и эта сессия не привязана жестко к вашему ssh-соединению. Вы можете отключиться, например закрыв вкладку с ssh-подключением, или нажав «Ctrl+B D» (то есть, сначала нажать Ctrl+B, а затем отпустить Ctrl и нажать D), и все запущенные внутри tmux приложения останутся нетронутыми. Вы можете потом подключиться к этой сессии обратно, введя «tmux attach» или screen с кучей флажков, например "-rD".



В целом, tmux выглядит более user-friendly и поддерживает из коробки довольно интересные вещи:

  1. Вышеупомянутое разделение экрана по вертикали, например с помощью Ctrl+B :split-vertical. К сожалению, новую версию screen с поддержкой такого разделения экрана все еще можно встретить не везде.
  2. Возможность подключиться к существующей сессии несколько раз — tmux attach подключит вас к существующей сессии, не «выкидывая» других подключенных пользователей
  3. Перемотка истории с помощью колеса мыши заданием опции mouse-mode on
  4. Отсутствие необходимости запускать «script» при попытке подключиться к screen другого пользователя через sudo


Скорее всего, все указанные выше вещи можно сделать и в рамках screen, просто tmux изначально спроектирован более простым для пользователя и имеет больше фич. Если вы вдруг пользуетесь iterm2, то в нем есть встроенная поддержка интеграции с tmux, что тоже может быть аргументом в его пользу.

Ну и напоследок поговорим про fish — friendly interactive shell

Недостатки bash


Честно говоря, сложно сказать, какие у баша достоинства. Самое большое достоинство баша состоит в том, что это самый распространенный шелл и что он стоит по умолчанию в большинстве дистрибутивах линукса, mac os x и даже cygwin. Также, bash является posix-совместимым, что означает, что можно заменить /bin/sh на /bin/bash в системе и «ничего не сломается». Однако интерактивные возможности баша находятся далеко позади другого распространенного конкурента в лице zsh, в баше даже нет правого prompt'а. Большинство возможностей как в bash, так и в zsh, выключены по умолчанию. Чтобы воспользоваться всеми фичами этих шеллов, нужно либо потратить значительное количество времени на их настройку, либо использовать готовые решения, например oh-my-zsh.

Интерактивный шелл 21 века — fish


Достаточно один раз увидеть, как работает fish (friendly interactive shell), и вы уже не захотите пользоваться ничем другим :). В целом, fish — это именно интерактивный шелл, не POSIX-совместимый. То есть, скрипты, написанные для /bin/sh или /bin/bash с его помощью выполнять нельзя. Синтаксис шелла немного отличается от обычного, см. примеры ниже.

Основные фичи:

  • Авто-дополнение для команд из истории и для имен файлов прямо по мере ввода, в режиме реального времени
  • Поставляется «с батарейками» — из коробки есть умное авто-дополнение для большинства команд, есть git_prompt и прочее
  • Наличие левого и правого prompt'ов, правильное вычисление их размеров, prompt задается функцией, а не строкой из PS1
  • Автоматическая история для директорий — Alt+Shift+стрелки налево-направо позволяют прозрачно возвращаться к предыдущей директории и обратно
  • «Исправленный» синтаксис, никаких больше do, then, fi, esac, $?, бэктиков (`cmd`) и множества других вещей — с адекватными подсказками — это делает fish не-POSIX шеллом, что, в общем-то, достоинством не является
  • Поддержка аббревиатур — к примеру, создав аббревиатуру «st -> git status», вы будете «вводить» «git status», как только ввели «st» — таким образом будет работать авто-дополнение и окружающие люди не будут пугаться ваших непонятных сокращений
  • Улучшенное авто-дополнение по <tab> — показываются не только сами подсказки, но и их тип (например, для git checkout показываются отдельно ветки и теги )


Есть также просто мелкие приятные улучшения:

  • prompt отображается нормально и не портится, даже если вывод программы не оканчивается переводом строки
  • подчёркивание правильных путей до файлов
  • показ красным некорректных команд — вы можете понять, что вы ввели неправильное имя команды, не нажимая Enter
  • возможность легко перенаправить stderr в pipe с помощью синтаксиса вида 2>| или ^|
  • все есть функция, нет алиасов, и для функций поддерживается autoload — при загрузке fish не считывает все доступные функции в память, а также позволяет менять код функций «на лету» без необходимости перечитывания полного конфига
  • локальная переменная CMD_DURATION — время исполнения последней команды, в миллисекундах
  • сокращенный путь до текущей директории по умолчанию — берутся первые буквы каждого из компонентов пути, кроме последней директории (например, /usr/local/bin/ -> /u/l/bin/)


Пример правого prompt'а с использованием CMD_DURATION и git_prompt:

$ cat ~/.config/fish/functions/fish_right_prompt.fish
function fish_right_prompt
	if test $status = 0
		echo -n (set_color green)
	else
		echo -n (set_color red)
	end

	echo $CMD_DURATION (set_color normal)ms (set_color yellow) (__fish_git_prompt "%s") (set_color normal)
end


Обратите внимание на синтаксис if-выражений — он больше похож на python, чем на shell. Выражения в скобках означает «вставить результат выполнения команды» — в bash это записывается как $(...), в fish первый символ доллара не требуется.

Вот, как это выглядит:



В правом приглашении показывается время выполнения команды в миллисекундах, зеленым цветом, если команда выполнена успешно, и красным, если произошла ошибка. Желтым цветом показывается текущая ветка, если есть.

Интеграция mosh, tmux и fish, выводы


При использовании tmux и fish вместе, возможны 2 проблемы, обе которых немного неприятны, но легко решаемы:

Вывод из stderr «пропадает» — github.com/fish-shell/fish-shell/issues/2115 — решается запуском «fish 2>&1» вместо просто «fish»
По умолчанию tmux ставит переменную окружения $TERM в screen, хотя и поддерживает 256-цветный режим, поэтому нужно выставить переменную окружения «export TERM=screen-256color», чтобы получить обычный fish вместо fallback'а на 16-цветный режим

Также, при использовании правого prompt'а в fish, а также при разделении окон по вертикали в tmux, клиент для mosh может начать сдвигать правую границу при быстром вводе, что приводит к временным артефактам при рисовании. Это происходит из-за того, что mosh не понимает, что положение рамок, разделяющих панели в tmux, а также положение правого prompt'а в fish фиксировано, и сдвигает их при вводе направо, вместе с остальным текстом.

Итого: все перечисленные выше инструменты весьма новые, и пока что не отточены до такого же состояния, как обычная связка ssh+screen+bash, но со временем ситуация улучшается, разработчики учитывают feedback от пользователей и улучшают интеграцию с другими «новыми» инструментами.

В целом, связка mosh+tmux+fish для меня решила множество мелких (и не очень) проблем, связанных с работой в удаленной консоли, не создав при этом много новых. Большое количество мелких, но удобных и полезных фич каждого из описанных инструментов, как мне кажется, стоит того, чтобы их попробовать самому.

Комментарии (55)


  1. Delphinum
    27.09.2015 15:07
    +6

    Достаточно один раз увидеть, как работает fish, и вы уже не захотите пользоваться ничем другим

    Пробовал перебраться на него, для чего перевел все что у меня есть на fish и пользовал около полугода. В результате вернулся на bash. Особенно раздражала вставка спецсимвола по «Ctrl+стрелка влево» вместо перехода на слово назад.


    1. nwalker
      27.09.2015 16:01
      +1

      У вас с терминалом что-то не то. Или у fish-а. УМВР из коробки.

      Проблемы были разве что по SSH через putty, но там со всем были проблемы.


      1. SamDark
        27.09.2015 16:10
        +1

        Что такое «УМВР»?


        1. youROCK
          27.09.2015 16:14
          +5

          «У меня все работает»


        1. walkman7
          27.09.2015 16:15

          http://lurkmore.to/УМВР



      1. Delphinum
        27.09.2015 22:29
        +2

        Не знаю в чем были проблемы, не стал разбираться, вернулся на старый и добрый.


  1. Magistr_AVSH
    27.09.2015 15:13

    В чем плюсы и минусы zsh и fish? Не так давно переехал с bash на zsh и конечно жизнь облегчилась капитально, но в чем плюсы fish по сравнению с zsh?


    1. youROCK
      27.09.2015 15:18
      +4

      Не могу сказать, чем fish лучше zsh, и лучше ли вообще. Скорее, fish интересен тем, что все его фичи включены по умолчанию и работают «из коробки», тогда как zsh нужно настраивать, чтобы излечь из его пользу. Но в техническом плане zsh, скорее всего, намного превосходит fish, по крайней мере пока.


      1. nazarpc
        27.09.2015 15:26

        Поддерживаю. Просто поставил — и стало существенно удобнее, такая себе более удобная замена в состоянии «из коробки».


      1. ZyXI
        27.09.2015 21:16
        +18

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

        С zsh вы можете взять и настроить практически всё — есть и аналог fish autosuggestions, и подсветка синтаксиса?. Universal variables вроде нету, но написать несложно: с моим же zpython такое можно устроить минут за десять (хотя у каждого способа будут свои ограничения).

        Помимо настраиваемости есть ряд уникальных возможностей: zsh единственная известная мне оболочка, для которой вы можете писать дополнения на C, при этом не включая их в репозиторий zsh. ZLE (Zsh Line Editor) имеет хуки на каждый чих, которые собственно и позволяют делать fish autosuggestions и zsh-syntax-highlighting. Для второго помимо хуков нужна и собственно поддержка подсветки. Также здесь вы вполне можете написать свой vi-mode с другим набором режимов.

        Ещё: если в случае с zsh автодополнение наверняка будет либо для zsh, либо для bash (zsh умеет использовать скрипты автодополнения от конкурента), то в случае с fish автодополнение либо будет в стандартной поставке, либо его не будет вовсе. Оболочка недостаточно популярна, чтобы для неё писали скрипты, а варианта zsh нету.

        А первая причина, по которой я не рекомендовал бы fish — категорическая скудость возможностей. Нет встроенной математики (писать (math {expr}) слишком долго, а исполняться оно будет через bc и, как минимум, два дополнительных процесса: собственно сам bc и echo). Process substitution работает только в одну сторону, да и тот есть эквивалент =(command) от zsh?. Про 100500 возможностей globbing из zsh я даже и не говорю: zsh может полностью заменить find вместе с несколькими другими программами (но find всё же быстрее), fish не имеет даже [{char1}{char2}]: только *, **, ? и {a,b}.

        И относительно «технических» вещей: fish имеет привычку кормить терминал огромным количеством разного мусора, который что?то там меняет (курсор, подсветка, собственно ввод пользователя, …). Пользователю на это всё равно, но если вам нужно устроить функциональное тестирование вашего приглашения ко вводу, то fish доставит на порядок больше проблем, чем любая другая оболочка. В частности, остальные оболочки работают быстрее (т.е. я могу поставить sleep поменьше, чтобы получить воспроизводимый результат).

        ? Правда, здесь вам лучше написать подсветку синтаксиса для pygments и использовать мой zsh-pygments-highlighting, т.к. zsh-syntax-highlighting, во?первых, медленный (написан на zsh, мой использует pygments), во?вторых, некорректный во многих случаях. А моё дополнение быстрое и, в принципе, дописано (хотя официально и считается «technical preview»), но без подсветки именно zsh скриптов в pygments не особо полезно.

        ? Для тех, кто не в курсе: =(command) отправляет вывод command во временный файл, который удаляется по завершению процесса, получившего =(command) в качестве аргумента, zsh?специфичная возможность. >(command), который есть в bash и zsh использует pipe. Разница в том, что первый вариант ждёт завершения команды, а второй нет, но не поддерживает seek (т.к. использует pipe) и может быть зарублен некоторыми излишне параноидальными процессами (которые закрывают все неизвестные им дескрипторы).


        1. ZyXI
          27.09.2015 22:38

          В ? >(command) следует читать как <(command). >(command) у fish вообще нет: github.com/fish-shell/fish-shell/issues/1786.


          1. Crandel
            28.09.2015 10:42
            -10

            Меня как веб-разработчика, полностью устраивают возможности fish из-коробки. У меня нету ни одного скрипта на bash, для этого есть python. Я не утверждаю, что fish лучше zsh в каком либо плане. Я просто утверждаю, что мне его достаточно, мне не нужно ничего из выше перечисленного. Поэтому утверждение, что fish ненужен меня жутко бесят. Хватит навязывать всем свое мнение, не нравиться — никто не заставляет читать. Я для себя нашел кучу интерестных возможностей из этой статьи и очень благодарен автору за это.


            1. ZyXI
              28.09.2015 13:47
              +6

              Вы вообще о чём? Я не говорил, что fish не нужен. Я только описал несколько вполне конкретных преимуществ zsh и сказал, почему я не буду рекомендовать fish. Если вас устраивают недостатки fish, то отговаривать вас от его использования я не буду. Но и молчать об их присутствии тоже.


        1. svlasov
          28.09.2015 13:18

          Где почитать про =(command)? Тут ничего не нашел подобного.


          1. ZyXI
            28.09.2015 13:43
            +3

            man zshexpn, секция PROCESS SUBSTITUTION. HTML?версию я никогда не использовал.


      1. lybin
        28.09.2015 02:53

        Я просто ставлю за одно с zsh grml-zsh-config ничего не настраиваю, все устраивает :)


    1. rutaka_n
      28.09.2015 11:57
      -1

      fish многопоточный, а zsh нет, по крайней мере так было когда я их пробовал. На моем raspberry pi fish рабоатл без задержек zsh лагал. Может, конечно я такой один, но тем не менее.


  1. DmitryKoterov
    27.09.2015 16:21

    По поводу mosh — вещь, конечно, хорошая, но убивают две вещи:
    1. Когда нажимаешь backspace и latency высокое, он начинает затирать строку приглашения! А потом назад отскакивает. Буэ. Так по умолчанию, но, может, отключается?
    2. Капитально перестают работать нетривиальные клавиши (особенно в сочетании с tmux-ом): разные сочетания с home-end-pgup-pgdn, клавиши типа F5 или Shift+F5 и т.д. Из-за этого пользоваться, к примеру, midnight commander-ом не представляется возможным (через простой tmux mc все-таки удается приручить разными сочетаниями настроек iTerm и обучением mc, но tmux+mosh — никак).

    Вот бы просто кто сделал то же самое, что mosh, но только на 100% пропуская все клавиши на сервер и выводя все обратно, так же в точности, как ssh делает. Решал бы ровно одну проблему — проблему реконнектов. И было бы тогда счастье.

    А еще у mosh в зависимостях перл зачем-то.


    1. youROCK
      27.09.2015 16:24

      Насколько я знаю, Дим, такие решения для ssh есть (я имею в виду auto-reconnect). А по поводу сочетаний клавиш — скажу честно, у меня с ними при работе через mosh проблем не было, но, может, я что-то не так делаю (пользуюсь обычным terminal.app).


    1. youROCK
      27.09.2015 16:25

      А проблема со стиранием промпта примерно такая же, как с уезжающим правым промптом и границами панелей в тмуксе — мош просто не знает, что это «декоративные элементы», а не редактируемый текст


    1. ctrlok
      29.09.2015 15:16

      кстати, новый iTerm поддержвиает tmux attach и подменяет собой tmux на любом удаленном сервере.


  1. amarao
    27.09.2015 16:24
    +1

    До тех пор, пока в fish'е не приделают команду export, он не является совместимым шеллом и к использованию не рекомендуется. Куча копипастов рассчитывает на export и брать в рассчёт одинокого отщепенца никто не будет.


    1. youROCK
      27.09.2015 16:51

      В версии 2.2 есть команда export


      1. amarao
        27.09.2015 17:40
        +1

        Сдались-таки?

        Но в sid'е 2.1, а бегать ради шелла самому что-то городить я не буду.


        1. hmage
          28.09.2015 15:52
          -3

          1. amarao
            28.09.2015 16:10
            +5

            Костыли для того, чтобы не делать на совесть.


  1. kstep
    27.09.2015 16:26

    Как старый пользователь zsh, не могу не упомянуть zsh-syntax-highlighting (есть в репозиториях арчика), который добавляет подсветку синтаксиса в командную строку zsh, наподобие fish.


  1. boblenin
    27.09.2015 18:00
    +3

    Как-то радикально очень менять ssh на mosh.
    1) Как у него с безопасностью?
    2) Умеет ли он всякие штуки типа тунелирования и передачи файлов?

    Как уже сказано в статье в принципе screen помогает в ситуациях с нестабильным коннектом, по крайней мере я именно им и пользуюсь обычно.


    1. youROCK
      27.09.2015 18:04
      +1

      С безопасностью — с помощью ssh они авторизуются и создают ключ для клиента, который передается по ssh сервером. После этого этот ключ используется для последующего шифрования трафика. Пока что не слышал историй, чтобы кто-то взломал канал передачи моша. Про тоннели и ssh-agent я не написал, но они сейчас не поддерживаются, но разработчики обещают запилить.


      1. ValdikSS
        28.09.2015 00:02

        Еще он не умеет IPv6, но поддержку уже сделали и скоро добавят.


        1. zed_0xff
          28.09.2015 11:39

          уже полгода использую вот этот форк github.com/rinne/mosh
          там и ipv6 и ssh-agent отлично работают из коробки


    1. lybin
      28.09.2015 03:05

      С безопасностью у него: вроде безопасно :) Штука не на столько популярна как ssh, на сколько знаю, исследований на безопасность не проводилось, кроме самих авторов. Так что риск есть.
      Тунелировать или передавать файлы имхо не зачем ему, он создан для комфортной работы в консоли при больших latency, а для остального есть старый добрый ssh.


    1. ksimute
      29.09.2015 17:41

      1. норм — цитата из FAQ

      What is Mosh's security track record so far?

      Mosh 1.0 was released in March 2012. As of the release of Mosh 1.2.5 in July 2015, as far as the developers are aware:

      In the last three years, no security vulnerabilities of any kind (major or minor) have been reported in Mosh.
      No major security vulnerabilities have ever been reported in Mosh. We define major security vulnerabilities to include privilege escalation, remote code execution, denial-of-service by a third party, etc.
      Two denial-of-service issues were discovered and fixed in releases in 2012. One issue allowed a mosh-server to cause the mosh-client to spend excess CPU (CVE-2012-2385, fixed in Mosh 1.2.1, released May 2012). Another issue allowed the server host to cause the mosh-client to send UDP datagrams to an incorrect address, foiling its attempt to connect (fixed in Mosh 1.2.2, released July 2012).

      из недостатков mosh scrolback не поддерживается +
      Он не работает если сервер за snat, если не натятся 60000-61000 порты что собственно логично :) но часто не поправимо.


  1. electronauts
    27.09.2015 18:39
    +1

    Простите, а для чего нужен правый prompt?


    1. youROCK
      27.09.2015 21:02
      +1

      Правый промпт прячется, когда не хватает места для ввода команды, поэтому там можно показывать второстепенную информацию, например текущее время, ветку гита, и при этом промпт не будет «прыгать» и менять положение в зависимости от той же длины имени ветки


      1. youROCK
        27.09.2015 21:03

        К сожалению, fish так не умеет (пока что?), но вот zsh умеет отрисовывать правый промпт асинхронно, позволяя запускать там тяжелые задачи вроде git status


  1. schors
    27.09.2015 20:30

    Меня смущает несколько вещей:
    1. Удаленная работа впрямую. Я не против. Сам работаю. Но вся статья прямо о постоянной и прямо вот интерактивной. Но это ведь частные редкие случаи. Есть же всякий git, ansible и всё такое
    2. Какие-то странные притязания к shell. Программы писать? Не на /bin/sh? Если не на /bin/sh, то зачем вообще извращаться и писать на shell? Сам факт существования 120 оболочек меня всегда удивлял.


    1. youROCK
      27.09.2015 20:54

      1. Так я и не админ :). Консоль обычно нужна для устранения проблем или для дебага на продакшене. На наших масштабах проблемы на отдельных серверах бывают весьма часто и требуется именно ручное вмешательство хирурга.
      2. Не очень понял, если честно :). Скрипты fish'а предполагается исполнять в контексте текущей сессии, а не использовать вместо /bin/sh. Не posix-совместимый шел может иногда создавать проблемы, когда какая-нибудь программа (например, плагин к виму) начинает звать $SHELL -c… вместо /bin/sh -c ..., и все ломается


      1. ZyXI
        27.09.2015 21:29

        Так просто не ставьте SHELL=…/fish, сама fish эту переменную не выставляет. Плагины к Vim не имеют привычки такое делать, а вот сам Vim вполне — он берёт свою настройку &shell из $SHELL и использует её всегда, когда нужно запустить любой внешний процесс. Нормальные дополнения знают, что &shell может быть разный (а пользователь может и сам выставить set shell=…/fish, потому как использует ! и/или :shell и не хочет видеть другую оболочку) и пишут с минимумом предположений (см. github.com/neovim/neovim/issues/2292#issuecomment-140504677 по поводу того, какие предположения, по моему мнению, допустимы: с fish всё будет также хорошо работать, пока вы не выходите за эти рамки).


  1. centur
    28.09.2015 04:36
    -10

    А мне одному кажется что шелл 21 века должен быть сделан на основе Slack\Hipchat бота и с интеграцией в тот же Hubot? Особенно если вы упираете на интерактивность работы.

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

    Может я конечно не очень много работаю в шелле, но в винде я бы точно избавился от всей дребедени типа CMD\Powershell и миллионов способов сделать их юзабельными…


  1. matiouchkine
    28.09.2015 11:52

    https://github.com/skwp/dotfiles :: конкурент oh-my-zsh, более подходящий под определение «из коробки». Вот уж с него точно никуда уходить не хочется.


    1. kstep
      28.09.2015 17:54

      А вот у меня очень старый конфиг, и прикручивать всякие oh-my-zsh мне уже не с руки: github.com/kstep/zsh-config.


    1. mpetrunin
      05.10.2015 11:23

      Долго время сидел на skwp (перейдя туда по совету Акиты). Но так и не смог привыкнуть к их набору умолчаний. Во-первых, они долгое время были ориентированы на Mac OS, поэтому некоторые вещи на Linux работали странно. Во-вторых, их умолчания сильно отличались от моих привычек, и я так и не смог перестроиться.

      В результате, вернулся на свой собственный vimfiles, а также на zsh + oh-my-zsh (с собственным набором плагинов). skwp dotfiles использую только как список «чего б такого интересного к своему конфигу прикрутить».


  1. xtender
    28.09.2015 23:43

    Еще бы раскрыть тему терминалов с горизонтальным скроллом и отдельно с «бесконечным»


    1. youROCK
      29.09.2015 09:44

      Вы сейчас про «less -S» говорите :)?


      1. xtender
        29.09.2015 10:07

        Нет, именно про терминалы, как например software.jessies.org/terminator
        То есть, чтобы я мог установить ширину терминала шире размера экрана, скажем, раза в три(при нормальном шрифте) и у терминала появлялся горизонтальный скролл.
        Например, так:


        1. max_rip
          08.10.2015 09:54

          Помнится я искал решение для windows, часто сижу в putty и иногда надо что-то мониторить, хочется развернуть окно шире чем ширина монитора, но система не дает. Может, что-то поменялось в 10, но в 7 так делать нельзя. Зато в иксах все прекрасно )), это касается отдельных окон.


          1. xtender
            08.10.2015 12:39

            не совсем понял: имеется ввиду растянуть именно окно шире? или все-таки дать возможность расширить внутренное содержимое с горизонтальным скроллом?


          1. xtender
            08.10.2015 12:55

            кстати, у меня два монитора — и putty и MobaXTerm растягиваются спокойно на оба монитора, но у них нет горизонтального скролла, поэтому если установить например «stty cols 1500» — строки будут переноситься.
            А в console2 это нормльно работает(правда конфиг надо править вручную, т.к. гуи не дают туда вбить большие значения)


  1. xvilka
    29.09.2015 10:47

    Я бы еще добавил, что консоль 21 века еще и поддерживает True Color (16 миллионов цветов в ?RGB формате) gist.github.com/XVilka/8346728


  1. ksimute
    29.09.2015 17:34

    Может кому-нибуль пригодится про mosh+tmux (мне жизнь упростило):

    добавил в .profile

    mm_f () {
    mosh $1 — tmux new-session -A -s ksimute-mosh
    }

    alias mm=mm_f

    сединяюсь с серверами
    mm server.name
    сразу подключаюсь к прошлой сессии, если она была, если нет — создается новая.

    Единственный недостаток tmux к которому вроде как решения нет — копирование мышкой нескольких страниц при скролинге. :(
    т.е. невозможно сделать
    cat filename
    мышкой отскролиться на пару страниц и откопировать в клипбоард.


  1. truezemez
    29.09.2015 18:50

    Перешел с чистого tmux на byobu и всем советую.


    1. Dreyk
      01.10.2015 00:33

      в чем профит?


      1. truezemez
        01.10.2015 10:23

        Удобнее. Посмотрите видео на сайте.