Командные оболочки UNIX

[ivm]

Командные оболочки UNIX -

• bash,
• zsh,
• и другие...

Их так много, но в Linux чаще используется bash в качестве предустановленной командной оболочки.
Но можно установить zsh в качестве оболочки по умолчанию для отдельного пользователя:

Код: [Выделить]

chsh -s /bin/zsh 'your_user'

[vita]

В Википедии есть статья Сравнение командных оболочек.
Заинтересовала Fish или Friendly Interactive Shell - это командная оболочка Linux нового поколения. Она разработана, чтобы облегчить пользователю выполнение команд, есть подсветка синтаксиса, подсветка правильных адресов файлов, быстрый поиск по истории, веб-конфигуратор, а также особый синтаксис скриптов. Это новая командная оболочка в Linux и её синтаксис не похож ни на одну из современных командных оболочек, а скорее на язык программирования Python.

[vita]

В официальном репозитории Ubuntu 16.04 есть пакет Fish версии 2.2, но имеется возможность установить более новую версию 2.3 из стороннего репозитория:

Код: [Выделить]

sudo add-apt-repository ppa:fish-shell/release-2 -y

Код: [Выделить]

sudo apt update

Код: [Выделить]

sudo apt install fishВ терминале после ввода команды

Код: [Выделить]

fishоткрылось приглашение в новую командную оболочку:

vita@Matuntu-X64  ~ fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
vita@Matuntu-X64 ~>

По Ctrl+D в терминале вернулась оболочка bash.
Будем изучать дальше возможности Fish.

[ivm]

По поводу всех альтернативных башу оболочек достаточно содержательное обсуждение на лоре. Полностью согласен с комментарием:

А я когда-то увлекался тюнингом zsh, конфиг у меня был под двести строчек, альясики всякие, но давно перешел на баш, так как сисадминю, а в 99.9% случаях, если подключиться к удаленному серверу, то у рута будет баш.

Чаще всего линукс используется для администрирования, а здесь придётся работать в той оболочке, которая есть на сервере.
Так что не ст^'оит привыкать к "удобствам".

[alv]

Чаще всего линукс используется для администрирования, а здесь придётся работать в той оболочке, которая есть на сервере.
Так что не ст^'оит привыкать к "удобствам".

Если следовать этой логике, настоящий админ не должен привыкать ни к чему, кроме /bin/sh и vim-tiny: всего остального на сервере может не оказаться
Но мы вроде как не о серверах, всё-таки?

[ivm]

Интереса ради можно посмотреть на все доступные варианты командной оболочки.
Как обычно, а можно всех посмотреть? За просмотр денег не берут 

[vita]

Мнение одного из лоровцев о применении альтернативных оболочек командной строки показалось интересным:

Просто поделюсь своими впечатлениями, когда тоже бегал по альтернативным шеллам. Когда в последний раз тыкал шеллы, было так:

Zsh очень похож на bash. Нет, даже так: это улучшенная версия bash. Нативная поддержка не только целых чисел, но и чисел с точкой. Улученные массивы и хэши(правда, ЕМНИП, их до сих пор нельзя вкладывать друг в друга, только по строковым ссылкам). Улучшенный глоббинг, который заменяет find в большинстве случаев. Мне бы очень хотелось, чтобы bash хоть что-то перенял... Но взамен мы получаем кучу костылей для поддержки всяких там tcsh, ksh и прочих маргинальных шеллов. И слишком сильную конфигурируемость. СЛИШКАМ МНОГА НАСТРОЕК. И каждая настройка довольно сильно меняет скриптинг(например, кто-то может отключить определение переменных как в ksh, и всё, приехали). И в итоге даже страшно писать скрипты, которые могут выйти за пределы локалхоста. Ибо конфигурация на конфигурацию не приходится.

К тому же zsh многими дистрибутивами поддерживается второстепенно(в принципе проблема и fish тоже). Archlinux - единственный известный мне дистрибутив, где он по умолчанию. Во всех остальных bash. Что довольно сказывается на поддержке некоторых терминалов этого шелла. Например, уведомления об окончании выполнения команды, в которые умеет gnome-terminal, не работают в zsh. Скорее всего потому, что они захардкодили, чтобы $SHELL соответствовал /bin/bash. Но реализуется это по сути через проброс функции для формирования приглашения используя окружение.

Самая главная фича fish, ИМХО, это то, что разбивка на слова не производится при вставке переменных. При передаче аргументов не надо каждый раз экранировать переменные кавычками("$PATH"), дабы не допустить случайного разбития строк, если каким-то волшебным образом там окажется пробел. Плюс ещё реализация функций там хороша, и «живое» автодополнение. Для всего остального бесполезен. И для более-менее продвинутого скриптинга тоже. Имеет всего 2 типа данных - строка(как обычно), и массив из строк. Поэтому, если вдруг понадобится написать нечто большее, чем запуск двух команд, получится такой же рассадник костылей как winetricks.

Всё закончилось тем, что забил на это дело, и стал жрать что дают. В Fedora по умолчанию bash, его и использую. Да и лучше я таки допилю bash под себя, или напишу свою шелллибу, чем буду трахаться с совместимостью моих скриптов на других тачках. Костыли над тупостью bash, писать научился уже давно.

[alv]

Мнение одного из лоровцев о применении альтернативных оболочек командной строки показалось интересным:

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

[ivm]

Что произойдёт в случае отказа от Bash в пользу другой оболочки при его отсутствии в системе с огромным количеством  скриптов, начинающихся с  #!/bin/bash?

[vita]

Нашла хороший рецепт для поиска прежних команд по введённым буквам.
Достаточно в файл ~/.inputrc вставить строки:

Код: [Выделить]

"\e[A": history-search-backward
"\e[B": history-search-forwardТакой файл в домашнем каталоге отсутствует, поэтому его нужно предварительно создать

Код: [Выделить]

pluma .inputrcПосле сохранения файла поиск по буквам начнёт работать по табуляции.
Проверено в Matuntu-X64 в терминале с bash.

[alv]

Что произойдёт в случае отказа от Bash в пользу другой оболочки при его отсутствии в системе с огромным количеством  скриптов, начинающихся с  #!/bin/bash?

Когда я делал из LFS систему с Zsh и без Bash - у меня все системные скрипты начинались с

Код: [Выделить]

#!/bin/shКак по хорошему и должно быть.
В Ubuntu, кстати, все системные скрипты начинаются с ша-банга /bin/dash.
А dash - это чуть модернизированный шелл Альмквиста, который, в свою очередь, почти POSIX Shell.
Так что ша-банг /bin/sh - универсален, это симлинк на любой Борносовместимый шелл.

UPD. Кстати, пардон, ошибся - в Ubuntu все скрипты из /etc/ как раз с /bin/sh и начинаются. Как, по хорошему, и должно быть в любой системе.
А /bin/sh - симлинк на /bin/dash.

[alv]

Нашла хороший рецепт для поиска прежних команд по введённым буквам.

Да, есть такое. Когда-то писал даже про это.
Это и есть один из нетривиальных способов прикручивания Zsh'евых фич к Bash'у. Согласитесь, что надо допереть, что за это отвечает не Bash, а Readline, и что надо править, стало быть, не bashrc, а inputrc.
Я в своё время не допёр - спасибо, Саша Баракин подсказал, aka Sach-kan, где тут собака зарыта

[alv]

Ну вот, сочинилось: Zsh и мифы о нём

[ivm]

Посмотрел я документацию по Zsh и статью Делаем из zsh мороженку. Поскольку человек я реальный со всеми присущими людям недостатками могу забыть, что прописал в настройках. Сложилось такое ощущение, что если мне нужно будет запутать злого хакера, который попадёт на мой компьютер, то надо ставить Zsh и настраивать его под себя. Тогда уж точно никто и ничего не сможет сделать, не зная моих настроек. Но если я забуду, то компьютер станет кирпичом. Кое-что полезное для себя от Zsh я всё-таки нашёл, но предпочитаю иметь однозначную документацию, приемлемую для большинства.

[alv]

предпочитаю иметь однозначную документацию, приемлемую для большинства.

А вот по части документации Bash'у до Zsh'а - что до Гонолулу омарам: пользовательское руководство Стефенсона, плюс постоянно обновляемое оригинальное руководство Фальстада в сумме тянут страниц на тысячу. Не считая более мелких доков по частным вопросам. Ну и man-страницы тоже никто не запрещает.