В чём различие между fish, zsh, bash и других?

А еще есть куча embedded-систем, где встроенный шелл busybox - предел мечтаний

Как видишь bash далеко не везде, по умолчанию.

Я этого и не утверждаю. Но и sh не везде именно sh. Другое дело, если его эмулирует bash или dash, как в вашем окружении.

Но и sh не везде именно sh

А какой sh считается за именно sh? Тот самый bourne shell из UNIX V7?

sh, наверное следует рассматривать как некий стандарт. Скрипт на котором будет работать под любой оболочкой.

Ну есть живой https://salsa.debian.org/clint/posh, но там именно реализация POSIX стандарта как самоцель, вряд ли кто-то использует его в реальной системе в качестве /bin/sh

Лучший стандартный шелл — bash. Лучший нестандартный шелл — xonsh. Нестандартные и одновременно бестолковые шеллы не нужны.

А какой sh считается за именно sh?

Тот, что не симлинк. /bin сам ссылка на /usr/bin

/usr/bin/sh --version
/usr/bin/bash --version

Одинаковый вывод

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
...

sh, наверное следует рассматривать как некий стандарт.

Я тоже так считаю.

В 2023 — пересечение dash и собранного без нифига busybox ash.

Нет никакого смысла писать на sh и отказываться от bash-измов и zsh-измов. Наоборот, если привык к zsh то лучше и писать скрипты под его возможности. Не только время сэкономит, но и потенциальных ошибок меньше будет.

Bash это ведь тот у которого формат файла .sh?

С точки зрения пользователя – почти никаких различий нет. Но fish идет сразу настроенным с нормальными дефолтами из коробки. Ты можешь его установить и сразу УДОБНО пользоваться. bash и zsh надо настраивать. И нет, в этом нет ничего хорошего. Нет, настраивая bash/zsh шизоидными портянками ты не изучишь Линукс. Посему я советую использовать fish.

Скрипты, однако, нужно писать именно на /bin/sh или /bin/bash, т.к. они есть везде.

Возможно, если ты новичок, стоит некоторое время попользоваться bash, чтобы понять насколько же хорош fish, как сильны его лапища.

Блоатваре вроде oh-my-zsh советую избегать как огня – это простой способ получить тормоза и лаги на ровном месте, особенно если увлечешся васянскими плагинами оттуда.

Если ты подразумеваешь РАСШИРЕНИЕ файла, то в Линуксе оно имеет лишь самодокументируещее значение, чтобы пользователь сразу понял, что это shell-файл. Ни на что больше оно не влияет и может использоваться для любого шелл-скрипта. Ты можешь свой скрипт назвать хоть my-script.mp4 – Линукс определяет формат файла не по расширения, а по содержимому.

Можно флудить в одной своей теме прикидываясь нубом.

Bash снисходительно относится к башизмам и прочим расширениям. Он вполне сожрёт скрипт со всякими local и прочим, которых нет в POSIX. Он сожрёт это и выполнит bash-скрипт, даже если был запущен симлинком /bin/sh (который и есть bash --posix), но также будет обрабатывать конструкции, специфичные для POSIX Shell. А вот в обратную сторону это не работает.

Собери какой-нибудь старый ash первых версий и удивись, как почти все (если не все) твои скрипты посыпят ошибками (и натворят дичи).

Собери какой-нибудь старый ash первых версий и удивись, как почти все (если не все) твои скрипты посыпят ошибками (и натворят дичи).

А без сборки старого ash обойтись можно? shellcheck по идее же нормально проверяет? Или и тут есть подводные камни?

Собери какой-нибудь старый ash первых версий и удивись, как почти все (если не все) твои скрипты посыпят ошибками (и натворят дичи).

ksh/dash/ash не сыпали. Было больше проблем из-за отличий GNU textutils от их неGNUтых версий.

Так не только в fish бывает.

Я недавно перешел на fish. Из самых ярких возможностей Alt-Ctrl-P список процессов удобный и Alt-Ctrl-F поиск удобный. А перешел из-за очень удобного автодополнения имен файлов\каталогов по Tab и приемущество подстановки истории именно для этого текущего каталога, а не из общей.

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

На самом деле башизмы жрет даже dash. Я с удивлением узнал, что он вообще не имеет ничего против == вместо =.

Это несложно на самом деле.

На любителя. Я считаю, что проще на голом ассемблере писать, чем на ваших скриптовых языках. Там хоть, понятно, почему всё так всрато сделано.

Уверен, что все кто говорят об обратном - пользователи хакер-утилит ping и top

mc. Они используют mc.

Ну и я про что, если потребности ограничиваются возможностями mc, то и bash сойдёт. Хотя для таких пользователей и чистый sh будет не сильно хуже.

Для навигации по фс удобнее баш с автокомплитом, mc открывается по месту применения при надобности в двухпанельнике или интерактивном выборе группы файлов

Это конечно вкусовщина, но для навигации по фс удобнее таки lf. Ну и главное, что баш может предложить для навигации по истории аргументов десятков других операций, помимо навигации по фс?

Мне хватает доступа к истории команд по началу введенной, остальное сделает автокомплит параметров

zsh (кстати оно идет по умолчанию в macos) куча сторонних плагинов и синтаксис совместим с bash, но все это хозяйство надо настраивать.

А что настраивать? Я вот уже лет 20 пользуюсь дефолтной консолью в линуксе. Пришел на мак, открыл терминал — все то же самое. Что там настраивать?

Ну правда по фану поставил ohmyzsh — теперь оно чуть более красиво выглядит и пишет текущую ветку гита. Но оно и без этого жилось отлично.

Ну а мне нужен доступ и к истории введенных аргументов, т.е. произвольную часть ввода нужно достать из истории с произвольной глубиной по времени. Баш так умеет? Понятно что можно использовать поиск, но это намного менее удобно.

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

history | grep

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

Еще может зависеть от особенностей работы или специфических потребностей. Мне кажется, что для новичка возможностей bash хватит с головой, особенно если он не учится на сисадмина или криминалиста.

Еще может зависеть от особенностей работы или специфических потребностей

Yep

Мне кажется, что для новичка возможностей bash хватит с головой

Да, но из коробки везде где видел баш (несколько лет назад, может быть стало лучше) это всё или не работало или работало скверно, поэтому нужно было настраивать. Так почему бы не настроить zsh или тупо поставить fish?

В скриптовых языках тоже понятно — потому что в первую очередь задизайнено под интерактив + минимум обязанностей на себя берёт сам шелл, всё сторонние программы. Да, сейчас тот же [ встроен обычно, но вообще это симлинк на test, например. Из таких соображений. В целом дело привычки. А главное, башизмы не сильно-то и помогают, конструкции-то остаются теми же. Ну да, местами надо написать две-три строки вместо одной, но это очень редкие случаи на самом деле. Ну и если становится совсем больно, значит просто надо брать более полноценный язык, а не шелл. Хоть тот же Python (Perl, Ruby — по вкусу).

Вот именно. После первых же шишек, набитых на шелле, стоит сразу

брать более полноценный язык

и не мучиться

Ну да. Каждой задаче свой инструмент. Есть скрипты, где на шелле реально проще и удобнее, чем на чём угодно ещё. Как самый примитивный пример: тупо выполнение нескольких сторонних программ поочерёдно без ветвления (опционально — с завершением в случае ошибки). Когда начинает требоваться сложная логика и сложная работа со строками, становится проще взять Python. Впрочем где именно находится эта грань, отличается от пользователя к пользователю.

shellcheck по идее же нормально проверяет?

На самом деле это меньшая из проблем. На разных ОС (и даже разных дистрибутивых) сейчас очень сильно различается базовый софт, и в итоге вполне валидный скрипт обосрётся на какой-нибудь внешней команде, которой либо нет, либо аргументы сильно отличаются.

Во FreeBSD ash (не тот ash, что в Linux) тоже прекрасно жрёт некоторые экстеншны. Тут даже local есть (который нередко выручает).

Ну так именно поэтому и в аргументах стандартных утилит тоже стоит ориентироваться именно на POSIX. Я так и делаю. А если вызывается что-то совсем не стандартное, то оно обычно таки в единственной реализации доступно (обычно это то, ради чего и вокруг чего весь скрипт, собственно, и пишется). Главное, чтоб в новых версиях чего-нибудь не поломали.

Когда начинает требоваться сложная логика и сложная работа со строками, становится проще взять Python

Если бы только строки :) Я тут упоролся разбирать бинарный протокол(данные из сокета, полученные socat) на баше и ничего - справился(благодаря совету со sof о том как работать со \0 символами на баше).

Проблема не в том, что нельзя сделать Х на баше, а в том, чтобы 1) это было сделать просто; 2) чтобы получившийся код был понятным и простым в поддержке; 3) и иногда чтобы код был не слишком медленным. Это и делает другие языки более предпочтительными для многих задач. На том же perl можно распарсить бинарные данные встроенной функцией unpack, а заодно и вычитать их из сокета безо всяких socat’ов

я тоже думал что отлично жилось, до тех пор пока автодополнение по истории не настроил

На том же perl можно распарсить бинарные данные встроенной функцией unpack

Но тогда придется тащить perl как зависимость, а у нас в образе каждый мегабайт считаем. В другом скрипте, например, пришлось отказаться от iconv, потому что оно зависимостей на 60Мб тянуло в образ.

а заодно и вычитать их из сокета безо всяких socat’ов

А вот тут не соглашусь, ибо unix-way.

Что там настраивать?

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

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

С тем же xonsh с нуля разобраться гораздо проще.

Но тогда придется тащить perl как зависимость, а у нас в образе каждый мегабайт считаем.

Это довольно специфичное требование, в большинстве систем perl все-таки есть, а вот socat установлен далеко не везде.

Но есть альтернативы, например, можно писать скрипты на Lua. Это в любом случае более продуктивно, чем тянуть за уши шелл туда, где он не справляется.

zsh это какие-то модные нестандартные шеллы

zsh это дефолт в макоси

В чём был смысл менять bash на dash в debian? Просто интересно.

Он быстрее и в нем меньше потенциальных дыр, так как меньше фич

А макос это модная нестандартная ОС.

Он быстрее

На сколько?

в нем меньше потенциальных дыр, так как меньше фич

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

На сколько?

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

https://unix.stackexchange.com/questions/148035/is-dash-or-some-other-shell-faster-than-bash

т.к. пользователей на порядки меньше

Аргументация уровень б-г.

1. Debian и Ubuntu это самые популярные дистрибутивы на десктопах, серверах и в контейнерах
2. От количества пользоватлей количество уязвимостей не зависит
3. Более популярный софт чаще ломают
4. В dash не было уязвимостей типа bashdoor, и вряд ли будут, так как парсер более простой.

На сколько?

Смотря что измерять. https://github.com/shellspec/shellbench

Последнее обновление от 2020 г. Какие сейчас будут результаты, не знаю.

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

Если под /bin/sh там имеется ввиду dash, то он в 3 из 6 тестов показал error :) Да и тестируют там весьма странные вещи (как и во всех тестах скорости шеллов), которые мало имеют отношения к шелл-скриптам, применяемым на практике.

От количества пользоватлей количество уязвимостей не зависит

А вот кол-во НАЙДЕННЫХ ошибок очень даже зависит. На какой-нибудь bash явно смотрит гораздо больше глаз, причем в интерактивном режиме, когда любое странное поведение заметить гораздо легче.

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