Консоль 21 века: mosh, tmux, fish

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

    Но если вы проводите за своим инструментом до 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 для меня решила множество мелких (и не очень) проблем, связанных с работой в удаленной консоли, не создав при этом много новых. Большое количество мелких, но удобных и полезных фич каждого из описанных инструментов, как мне кажется, стоит того, чтобы их попробовать самому.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 59

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

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

        Проблемы были разве что по SSH через putty, но там со всем были проблемы.
          +1
          Что такое «УМВР»?
          +2
          Не знаю в чем были проблемы, не стал разбираться, вернулся на старый и добрый.
        0
        В чем плюсы и минусы zsh и fish? Не так давно переехал с bash на zsh и конечно жизнь облегчилась капитально, но в чем плюсы fish по сравнению с zsh?
          +4
          Не могу сказать, чем fish лучше zsh, и лучше ли вообще. Скорее, fish интересен тем, что все его фичи включены по умолчанию и работают «из коробки», тогда как zsh нужно настраивать, чтобы излечь из его пользу. Но в техническом плане zsh, скорее всего, намного превосходит fish, по крайней мере пока.
            0
            Поддерживаю. Просто поставил — и стало существенно удобнее, такая себе более удобная замена в состоянии «из коробки».
              +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) и может быть зарублен некоторыми излишне параноидальными процессами (которые закрывают все неизвестные им дескрипторы).
                0
                В ² >(command) следует читать как <(command). >(command) у fish вообще нет: github.com/fish-shell/fish-shell/issues/1786.
                  –10
                  Меня как веб-разработчика, полностью устраивают возможности fish из-коробки. У меня нету ни одного скрипта на bash, для этого есть python. Я не утверждаю, что fish лучше zsh в каком либо плане. Я просто утверждаю, что мне его достаточно, мне не нужно ничего из выше перечисленного. Поэтому утверждение, что fish ненужен меня жутко бесят. Хватит навязывать всем свое мнение, не нравиться — никто не заставляет читать. Я для себя нашел кучу интерестных возможностей из этой статьи и очень благодарен автору за это.
                    +6
                    Вы вообще о чём? Я не говорил, что fish не нужен. Я только описал несколько вполне конкретных преимуществ zsh и сказал, почему я не буду рекомендовать fish. Если вас устраивают недостатки fish, то отговаривать вас от его использования я не буду. Но и молчать об их присутствии тоже.
                  0
                  Где почитать про =(command)? Тут ничего не нашел подобного.
                    +3
                    man zshexpn, секция PROCESS SUBSTITUTION. HTML‐версию я никогда не использовал.
                  0
                  Я просто ставлю за одно с zsh grml-zsh-config ничего не настраиваю, все устраивает :)
                  –1
                  fish многопоточный, а zsh нет, по крайней мере так было когда я их пробовал. На моем raspberry pi fish рабоатл без задержек zsh лагал. Может, конечно я такой один, но тем не менее.
                  0
                  По поводу 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 в зависимостях перл зачем-то.
                    0
                    Насколько я знаю, Дим, такие решения для ssh есть (я имею в виду auto-reconnect). А по поводу сочетаний клавиш — скажу честно, у меня с ними при работе через mosh проблем не было, но, может, я что-то не так делаю (пользуюсь обычным terminal.app).
                      0
                      А проблема со стиранием промпта примерно такая же, как с уезжающим правым промптом и границами панелей в тмуксе — мош просто не знает, что это «декоративные элементы», а не редактируемый текст
                        0
                        кстати, новый iTerm поддержвиает tmux attach и подменяет собой tmux на любом удаленном сервере.
                        +1
                        До тех пор, пока в fish'е не приделают команду export, он не является совместимым шеллом и к использованию не рекомендуется. Куча копипастов рассчитывает на export и брать в рассчёт одинокого отщепенца никто не будет.
                          0
                          В версии 2.2 есть команда export
                            +1
                            Сдались-таки?

                            Но в sid'е 2.1, а бегать ради шелла самому что-то городить я не буду.
                        0
                        Как старый пользователь zsh, не могу не упомянуть zsh-syntax-highlighting (есть в репозиториях арчика), который добавляет подсветку синтаксиса в командную строку zsh, наподобие fish.
                          +3
                          Как-то радикально очень менять ssh на mosh.
                          1) Как у него с безопасностью?
                          2) Умеет ли он всякие штуки типа тунелирования и передачи файлов?

                          Как уже сказано в статье в принципе screen помогает в ситуациях с нестабильным коннектом, по крайней мере я именно им и пользуюсь обычно.
                            +1
                            С безопасностью — с помощью ssh они авторизуются и создают ключ для клиента, который передается по ssh сервером. После этого этот ключ используется для последующего шифрования трафика. Пока что не слышал историй, чтобы кто-то взломал канал передачи моша. Про тоннели и ssh-agent я не написал, но они сейчас не поддерживаются, но разработчики обещают запилить.
                              0
                              Еще он не умеет IPv6, но поддержку уже сделали и скоро добавят.
                                0
                                уже полгода использую вот этот форк github.com/rinne/mosh
                                там и ipv6 и ssh-agent отлично работают из коробки
                              0
                              С безопасностью у него: вроде безопасно :) Штука не на столько популярна как ssh, на сколько знаю, исследований на безопасность не проводилось, кроме самих авторов. Так что риск есть.
                              Тунелировать или передавать файлы имхо не зачем ему, он создан для комфортной работы в консоли при больших latency, а для остального есть старый добрый ssh.
                              • UFO just landed and posted this here
                                +1
                                Простите, а для чего нужен правый prompt?
                                  +1
                                  Правый промпт прячется, когда не хватает места для ввода команды, поэтому там можно показывать второстепенную информацию, например текущее время, ветку гита, и при этом промпт не будет «прыгать» и менять положение в зависимости от той же длины имени ветки
                                    0
                                    К сожалению, fish так не умеет (пока что?), но вот zsh умеет отрисовывать правый промпт асинхронно, позволяя запускать там тяжелые задачи вроде git status
                                  0
                                  Меня смущает несколько вещей:
                                  1. Удаленная работа впрямую. Я не против. Сам работаю. Но вся статья прямо о постоянной и прямо вот интерактивной. Но это ведь частные редкие случаи. Есть же всякий git, ansible и всё такое
                                  2. Какие-то странные притязания к shell. Программы писать? Не на /bin/sh? Если не на /bin/sh, то зачем вообще извращаться и писать на shell? Сам факт существования 120 оболочек меня всегда удивлял.
                                    0
                                    1. Так я и не админ :). Консоль обычно нужна для устранения проблем или для дебага на продакшене. На наших масштабах проблемы на отдельных серверах бывают весьма часто и требуется именно ручное вмешательство хирурга.
                                    2. Не очень понял, если честно :). Скрипты fish'а предполагается исполнять в контексте текущей сессии, а не использовать вместо /bin/sh. Не posix-совместимый шел может иногда создавать проблемы, когда какая-нибудь программа (например, плагин к виму) начинает звать $SHELL -c… вместо /bin/sh -c ..., и все ломается
                                      0
                                      Так просто не ставьте SHELL=…/fish, сама fish эту переменную не выставляет. Плагины к Vim не имеют привычки такое делать, а вот сам Vim вполне — он берёт свою настройку &shell из $SHELL и использует её всегда, когда нужно запустить любой внешний процесс. Нормальные дополнения знают, что &shell может быть разный (а пользователь может и сам выставить set shell=…/fish, потому как использует ! и/или :shell и не хочет видеть другую оболочку) и пишут с минимумом предположений (см. github.com/neovim/neovim/issues/2292#issuecomment-140504677 по поводу того, какие предположения, по моему мнению, допустимы: с fish всё будет также хорошо работать, пока вы не выходите за эти рамки).
                                    –10
                                    А мне одному кажется что шелл 21 века должен быть сделан на основе Slack\Hipchat бота и с интеграцией в тот же Hubot? Особенно если вы упираете на интерактивность работы.

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

                                    Может я конечно не очень много работаю в шелле, но в винде я бы точно избавился от всей дребедени типа CMD\Powershell и миллионов способов сделать их юзабельными…
                                      0
                                      https://github.com/skwp/dotfiles :: конкурент oh-my-zsh, более подходящий под определение «из коробки». Вот уж с него точно никуда уходить не хочется.

                                        0
                                        А вот у меня очень старый конфиг, и прикручивать всякие oh-my-zsh мне уже не с руки: github.com/kstep/zsh-config.
                                          0
                                          Долго время сидел на skwp (перейдя туда по совету Акиты). Но так и не смог привыкнуть к их набору умолчаний. Во-первых, они долгое время были ориентированы на Mac OS, поэтому некоторые вещи на Linux работали странно. Во-вторых, их умолчания сильно отличались от моих привычек, и я так и не смог перестроиться.

                                          В результате, вернулся на свой собственный vimfiles, а также на zsh + oh-my-zsh (с собственным набором плагинов). skwp dotfiles использую только как список «чего б такого интересного к своему конфигу прикрутить».
                                          0
                                          Еще бы раскрыть тему терминалов с горизонтальным скроллом и отдельно с «бесконечным»
                                            0
                                            Вы сейчас про «less -S» говорите :)?
                                              0
                                              Нет, именно про терминалы, как например software.jessies.org/terminator
                                              То есть, чтобы я мог установить ширину терминала шире размера экрана, скажем, раза в три(при нормальном шрифте) и у терминала появлялся горизонтальный скролл.
                                              Например, так:
                                                0
                                                Помнится я искал решение для windows, часто сижу в putty и иногда надо что-то мониторить, хочется развернуть окно шире чем ширина монитора, но система не дает. Может, что-то поменялось в 10, но в 7 так делать нельзя. Зато в иксах все прекрасно )), это касается отдельных окон.
                                                  0
                                                  не совсем понял: имеется ввиду растянуть именно окно шире? или все-таки дать возможность расширить внутренное содержимое с горизонтальным скроллом?
                                                    0
                                                    кстати, у меня два монитора — и putty и MobaXTerm растягиваются спокойно на оба монитора, но у них нет горизонтального скролла, поэтому если установить например «stty cols 1500» — строки будут переноситься.
                                                    А в console2 это нормльно работает(правда конфиг надо править вручную, т.к. гуи не дают туда вбить большие значения)
                                              0
                                              Я бы еще добавил, что консоль 21 века еще и поддерживает True Color (16 миллионов цветов в ٌRGB формате) gist.github.com/XVilka/8346728
                                              • UFO just landed and posted this here
                                                  0
                                                  А вы не копируйте мышкой.

                                                  попробуйте так:

                                                  cat filename | xclip -selection c
                                                  • UFO just landed and posted this here
                                                  0
                                                  Перешел с чистого tmux на byobu и всем советую.
                                                    0
                                                    в чем профит?
                                                      0
                                                      Удобнее. Посмотрите видео на сайте.
                                                        0
                                                        Удобнее чем? byobu это просто темка над tmux (либо screen). Что вам дает byobu, чего нет в tmux?
                                                          0
                                                          Тем, что можно сразу пользоваться. Просто хорошо настроено из коробки. Хоткеи удобные и простые.
                                                          Мне лично, более по душе пришлось.

                                                  Only users with full accounts can post comments. Log in, please.