Комментарии 17
Мне кажется, что все эти языки и отдельные "программы" типа grep это пережиток прошлого, когда не было повсеместного интернета, а у языков отсутствовали пакетные менеджеры и код связывался через include и аналоги.
Создавайся экосистема сейчас - стоило бы сделать скриптовым языком по умолчанию питон, js или что то подобное. С нормальной обработкой ошибок, нормальными завистмостями и нормальным версионированием (привет макоси с её чудными аналогами grep и прочего).
Кстати очень много девопсов пишет свои скрипты на питоне, и в целом всё больше людей знают питон, возможно в итоге всё туда и придёт.
Это всё конечно классно, но ровно до того момента, когда выясняется, что bash - дефолтный shell практически во всех более-ни-менее популярных дистрибутивах. И, увы, скрипты приходится творить именно под bash, во избежание головной боли при деплое в абстрактное куда-то. А если совсем по-хорошему - POSIX sh-compatible, хоть и те кто, оригинальный sh в руках крутил, поди еще поищи.
Потому, увы, альтернативные оболочки остаются исключительно для локального, самостоятельного развлечения админа в подавляющем большинстве случаев
Справедливости ради zsh теперь default shell on MacOS. Но ровно из-за этого пришлось откатиться от bash к sh-compatible, что бы скрипты одинаково работали локально и на каком debian/centos/mandrake/whatever.
Дополню, что bash и busybox это самые распространённые оболочки и я стараюсь писать только с shellcheck без использования специфичных для оболочек фишек.
Тем не менее на мой взгляд писать скрипты деплоя лучше на языках, которые будут выполняться одинаково на всех системах, тот же Python или Groovy в связке c Jenkins. Так вы точно будете уверены, что ваш код будет одинаково работать на разных системах, в которых установлен рантайм соответствующего ЯП.
В моем окружении сейчас сложно найти того, кто все ещё пользуется bash. Если мы пишем для кого-то скрипт - шанс того, что его попробует запустить неподготовленный юзер без zsh/fish в системе околонулевой. А таковой все же найдется - столкнется с суровой реальностью и таки поставит себе zsh, потому что факт попадания скрипта на его машину автоматически означает наличие на ней интернета и прямых рук для установки чего нужно
Если сравнивать с zsh + zsh-autosuggestions + zsh-completions + zsh-syntax-highlighting, то сильно отличается? Причины переезда?
В принципе, разницы особо нет.
Zsh точно так же настраиваемый.
В fish есть несколько уже готовых тем со всеми плешками, вполне возможно zsh с вышеперечисленным даст тот же эффект.
Насчёт скорости, не заметил разницы в работе.
Но у меня опыт запуска из WSL на своём мощном компьютере, возможно стоит посмотреть на более медленном железе и тогда будет видно.
Тогда вот еще одна добавка Powerlevel10k. Тут дело не в красивости, а информативности.
Присоединяюсь к вопросу @mishutka_ua и хочу уже то себя добавить: сильно тормозит? Субъективно, как мне показалось в ходе экспериментов, zsh+powershell10k (ради которого и ставился zsh, хотелось красивого prompt'а с git и прочими плюшками) лагает больше, чем bash.
Эта статья стала для меня стала вторым звоночком, после которого я решил лежать в сторону миграции на zsh. Первым стала попытка отладить встреченную с утечку памяти в новой версии bash. У меня был простой скрипт, воспроизводящий проблему, так что я думал, что для её поиска будет достаточно прогнать git bisect по репозиторию. Ха! Как оказалось, bash поддерживает примерно один человек и репозиторий ведёт в стиле "один коммит на релиз" (вот статистика в зеркале). zsh на этом фоне смотрится гораздо более поддерживаемым проектом.
есть https://git.sr.ht/~emersion/mrsh - POSIX shell (не bash), последний коммит 10 месяцев назад, но я гарантирую что подобный баг будет исправлен очень быстро.
А если нужно писать очень короткие скрипты, то можно посмотреть на https://skarnet.org/software/execline/ - еще более минимальная штука, мне нравится
Единственная причина, по которой я пользуюсь sh/bash, а не zsh:
$ zsh
bash: zsh: command not found
А sh/bash стоит везде.
s/bash/zsh/g