Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Достаточно один раз увидеть, как работает fish, и вы уже не захотите пользоваться ничем другим
Пробовал перебраться на него, для чего перевел все что у меня есть на fish и пользовал около полугода. В результате вернулся на bash. Особенно раздражала вставка спецсимвола по «Ctrl+стрелка влево» вместо перехода на слово назад.
В чем плюсы и минусы zsh и fish? Не так давно переехал с bash на zsh и конечно жизнь облегчилась капитально, но в чем плюсы fish по сравнению с zsh?
Не могу сказать, чем fish лучше zsh, и лучше ли вообще. Скорее, fish интересен тем, что все его фичи включены по умолчанию и работают «из коробки», тогда как zsh нужно настраивать, чтобы излечь из его пользу. Но в техническом плане zsh, скорее всего, намного превосходит fish, по крайней мере пока.
Поддерживаю. Просто поставил — и стало существенно удобнее, такая себе более удобная замена в состоянии «из коробки».
У них вообще весьма разные парадигмы разработки. В частности, разработчики 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 — категорическая скудость возможностей. Нет встроенной математики (писать
И относительно «технических» вещей: fish имеет привычку кормить терминал огромным количеством разного мусора, который что‐то там меняет (курсор, подсветка, собственно ввод пользователя, …). Пользователю на это всё равно, но если вам нужно устроить функциональное тестирование вашего приглашения ко вводу, то fish доставит на порядок больше проблем, чем любая другая оболочка. В частности, остальные оболочки работают быстрее (т.е. я могу поставить sleep поменьше, чтобы получить воспроизводимый результат).
¹ Правда, здесь вам лучше написать подсветку синтаксиса для pygments и использовать мой zsh-pygments-highlighting, т.к. zsh-syntax-highlighting, во‐первых, медленный (написан на zsh, мой использует pygments), во‐вторых, некорректный во многих случаях. А моё дополнение быстрое и, в принципе, дописано (хотя официально и считается «technical preview»), но без подсветки именно zsh скриптов в pygments не особо полезно.
² Для тех, кто не в курсе:
С 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) и может быть зарублен некоторыми излишне параноидальными процессами (которые закрывают все неизвестные им дескрипторы).В ²
>(command) следует читать как <(command). >(command) у fish вообще нет: github.com/fish-shell/fish-shell/issues/1786.
Где почитать про =(command)? Тут ничего не нашел подобного.
Я просто ставлю за одно с zsh grml-zsh-config ничего не настраиваю, все устраивает :)
fish многопоточный, а zsh нет, по крайней мере так было когда я их пробовал. На моем raspberry pi fish рабоатл без задержек zsh лагал. Может, конечно я такой один, но тем не менее.
По поводу 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. Когда нажимаешь backspace и latency высокое, он начинает затирать строку приглашения! А потом назад отскакивает. Буэ. Так по умолчанию, но, может, отключается?
2. Капитально перестают работать нетривиальные клавиши (особенно в сочетании с tmux-ом): разные сочетания с home-end-pgup-pgdn, клавиши типа F5 или Shift+F5 и т.д. Из-за этого пользоваться, к примеру, midnight commander-ом не представляется возможным (через простой tmux mc все-таки удается приручить разными сочетаниями настроек iTerm и обучением mc, но tmux+mosh — никак).
Вот бы просто кто сделал то же самое, что mosh, но только на 100% пропуская все клавиши на сервер и выводя все обратно, так же в точности, как ssh делает. Решал бы ровно одну проблему — проблему реконнектов. И было бы тогда счастье.
А еще у mosh в зависимостях перл зачем-то.
Насколько я знаю, Дим, такие решения для ssh есть (я имею в виду auto-reconnect). А по поводу сочетаний клавиш — скажу честно, у меня с ними при работе через mosh проблем не было, но, может, я что-то не так делаю (пользуюсь обычным terminal.app).
А проблема со стиранием промпта примерно такая же, как с уезжающим правым промптом и границами панелей в тмуксе — мош просто не знает, что это «декоративные элементы», а не редактируемый текст
До тех пор, пока в fish'е не приделают команду export, он не является совместимым шеллом и к использованию не рекомендуется. Куча копипастов рассчитывает на export и брать в рассчёт одинокого отщепенца никто не будет.
Как старый пользователь zsh, не могу не упомянуть zsh-syntax-highlighting (есть в репозиториях арчика), который добавляет подсветку синтаксиса в командную строку zsh, наподобие fish.
Как-то радикально очень менять ssh на mosh.
1) Как у него с безопасностью?
2) Умеет ли он всякие штуки типа тунелирования и передачи файлов?
Как уже сказано в статье в принципе screen помогает в ситуациях с нестабильным коннектом, по крайней мере я именно им и пользуюсь обычно.
1) Как у него с безопасностью?
2) Умеет ли он всякие штуки типа тунелирования и передачи файлов?
Как уже сказано в статье в принципе screen помогает в ситуациях с нестабильным коннектом, по крайней мере я именно им и пользуюсь обычно.
С безопасностью — с помощью ssh они авторизуются и создают ключ для клиента, который передается по ssh сервером. После этого этот ключ используется для последующего шифрования трафика. Пока что не слышал историй, чтобы кто-то взломал канал передачи моша. Про тоннели и ssh-agent я не написал, но они сейчас не поддерживаются, но разработчики обещают запилить.
Еще он не умеет IPv6, но поддержку уже сделали и скоро добавят.
уже полгода использую вот этот форк github.com/rinne/mosh
там и ipv6 и ssh-agent отлично работают из коробки
там и ipv6 и ssh-agent отлично работают из коробки
С безопасностью у него: вроде безопасно :) Штука не на столько популярна как ssh, на сколько знаю, исследований на безопасность не проводилось, кроме самих авторов. Так что риск есть.
Тунелировать или передавать файлы имхо не зачем ему, он создан для комфортной работы в консоли при больших latency, а для остального есть старый добрый ssh.
Тунелировать или передавать файлы имхо не зачем ему, он создан для комфортной работы в консоли при больших latency, а для остального есть старый добрый ssh.
Простите, а для чего нужен правый prompt?
Меня смущает несколько вещей:
1. Удаленная работа впрямую. Я не против. Сам работаю. Но вся статья прямо о постоянной и прямо вот интерактивной. Но это ведь частные редкие случаи. Есть же всякий git, ansible и всё такое
2. Какие-то странные притязания к shell. Программы писать? Не на /bin/sh? Если не на /bin/sh, то зачем вообще извращаться и писать на shell? Сам факт существования 120 оболочек меня всегда удивлял.
1. Удаленная работа впрямую. Я не против. Сам работаю. Но вся статья прямо о постоянной и прямо вот интерактивной. Но это ведь частные редкие случаи. Есть же всякий git, ansible и всё такое
2. Какие-то странные притязания к shell. Программы писать? Не на /bin/sh? Если не на /bin/sh, то зачем вообще извращаться и писать на shell? Сам факт существования 120 оболочек меня всегда удивлял.
1. Так я и не админ :). Консоль обычно нужна для устранения проблем или для дебага на продакшене. На наших масштабах проблемы на отдельных серверах бывают весьма часто и требуется именно ручное вмешательство хирурга.
2. Не очень понял, если честно :). Скрипты fish'а предполагается исполнять в контексте текущей сессии, а не использовать вместо /bin/sh. Не posix-совместимый шел может иногда создавать проблемы, когда какая-нибудь программа (например, плагин к виму) начинает звать $SHELL -c… вместо /bin/sh -c ..., и все ломается
2. Не очень понял, если честно :). Скрипты fish'а предполагается исполнять в контексте текущей сессии, а не использовать вместо /bin/sh. Не posix-совместимый шел может иногда создавать проблемы, когда какая-нибудь программа (например, плагин к виму) начинает звать $SHELL -c… вместо /bin/sh -c ..., и все ломается
Так просто не ставьте SHELL=…/fish, сама fish эту переменную не выставляет. Плагины к Vim не имеют привычки такое делать, а вот сам Vim вполне — он берёт свою настройку &shell из $SHELL и использует её всегда, когда нужно запустить любой внешний процесс. Нормальные дополнения знают, что &shell может быть разный (а пользователь может и сам выставить
set shell=…/fish, потому как использует ! и/или :shell и не хочет видеть другую оболочку) и пишут с минимумом предположений (см. github.com/neovim/neovim/issues/2292#issuecomment-140504677 по поводу того, какие предположения, по моему мнению, допустимы: с fish всё будет также хорошо работать, пока вы не выходите за эти рамки).
А мне одному кажется что шелл 21 века должен быть сделан на основе Slack\Hipchat бота и с интеграцией в тот же Hubot? Особенно если вы упираете на интерактивность работы.
И история и поиск, и автокомплит и куча всяких других фишек, не говоря о том, что вы не сильно паритесь чтобы быть онлайн на плохом соединении и можете давать команды на разных девайсах, т.е. ушли с работы а он продолжает репортить — остановили или поправили что-то с мобилки, пришли домой — залезли в браузер и продолжили.
Может я конечно не очень много работаю в шелле, но в винде я бы точно избавился от всей дребедени типа CMD\Powershell и миллионов способов сделать их юзабельными…
И история и поиск, и автокомплит и куча всяких других фишек, не говоря о том, что вы не сильно паритесь чтобы быть онлайн на плохом соединении и можете давать команды на разных девайсах, т.е. ушли с работы а он продолжает репортить — остановили или поправили что-то с мобилки, пришли домой — залезли в браузер и продолжили.
Может я конечно не очень много работаю в шелле, но в винде я бы точно избавился от всей дребедени типа CMD\Powershell и миллионов способов сделать их юзабельными…
https://github.com/skwp/dotfiles :: конкурент oh-my-zsh, более подходящий под определение «из коробки». Вот уж с него точно никуда уходить не хочется.
А вот у меня очень старый конфиг, и прикручивать всякие oh-my-zsh мне уже не с руки: github.com/kstep/zsh-config.
Долго время сидел на skwp (перейдя туда по совету Акиты). Но так и не смог привыкнуть к их набору умолчаний. Во-первых, они долгое время были ориентированы на Mac OS, поэтому некоторые вещи на Linux работали странно. Во-вторых, их умолчания сильно отличались от моих привычек, и я так и не смог перестроиться.
В результате, вернулся на свой собственный vimfiles, а также на zsh + oh-my-zsh (с собственным набором плагинов). skwp dotfiles использую только как список «чего б такого интересного к своему конфигу прикрутить».
В результате, вернулся на свой собственный vimfiles, а также на zsh + oh-my-zsh (с собственным набором плагинов). skwp dotfiles использую только как список «чего б такого интересного к своему конфигу прикрутить».
Еще бы раскрыть тему терминалов с горизонтальным скроллом и отдельно с «бесконечным»
Вы сейчас про «less -S» говорите :)?
Нет, именно про терминалы, как например software.jessies.org/terminator
То есть, чтобы я мог установить ширину терминала шире размера экрана, скажем, раза в три(при нормальном шрифте) и у терминала появлялся горизонтальный скролл.
Например, так:
То есть, чтобы я мог установить ширину терминала шире размера экрана, скажем, раза в три(при нормальном шрифте) и у терминала появлялся горизонтальный скролл.
Например, так:
Помнится я искал решение для windows, часто сижу в putty и иногда надо что-то мониторить, хочется развернуть окно шире чем ширина монитора, но система не дает. Может, что-то поменялось в 10, но в 7 так делать нельзя. Зато в иксах все прекрасно )), это касается отдельных окон.
не совсем понял: имеется ввиду растянуть именно окно шире? или все-таки дать возможность расширить внутренное содержимое с горизонтальным скроллом?
кстати, у меня два монитора — и putty и MobaXTerm растягиваются спокойно на оба монитора, но у них нет горизонтального скролла, поэтому если установить например «stty cols 1500» — строки будут переноситься.
А в console2 это нормльно работает(правда конфиг надо править вручную, т.к. гуи не дают туда вбить большие значения)
А в console2 это нормльно работает(правда конфиг надо править вручную, т.к. гуи не дают туда вбить большие значения)
Я бы еще добавил, что консоль 21 века еще и поддерживает True Color (16 миллионов цветов в ٌRGB формате) gist.github.com/XVilka/8346728
Перешел с чистого tmux на byobu и всем советую.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Консоль 21 века: mosh, tmux, fish