Позволю себе поднять упавшее знамя, оставшееся после предыдущих ораторов и продолжить благое дело продвижения zsh в массы. Надеюсь, после прочтения топика вы тоже смените старый добрый, но, как по мне, так застрявший в прошлом, bash на более удобный и продвинутый zsh.
Чтобы не быть голословным, попробуем рассмотреть это дело в контексте абсолютно субъективного и предвзятого сравнения bash vs. zsh.
Сразу оговорюсь, что не являюсь сторонником консоли на десктопах, хоть и использую линукс дома, всё-таки GUI ближе человеку. Поэтому рассказ пойдёт о вещах, которые скорее пригодятся администратору, чем конечному пользователю, но впрочем кто знает.
Итак, типичные операции администратора: навигация по файловой системе, копирование/удаление файлов, просмотр логов, правка конфигурационных файлов, умеренное использование скриптов для автоматизации однообразных операций. Мм… ничего не забыл?
Пойдём по порядку.
bash:
классическое для всех *nix (и даже не *nix) шеллов
zsh:
Самая простая и незатейливая на вид, но при этом самая моя любимая фича — этотелепатический режим управления autocd, то есть переход между каталогами без явного использования cd. По моему опыту она включена по умолчанию во всех дефолтных конфигах zsh всех дистрибутивов.
В сочетании с фичей «раскрытие путей» (т.е. когда вы на самом деле помните весь путь, но вам лень печатать, в таком случае можно ввести только начальные символы) это делает навигацию в zsh быстрее и удобнее примерно в миллион раз (по самым скромным моим подсчётам)
Как говориться, лучше один раз увидеть.
Говоря про навигацию, нельзя избежать заезженой темы автокомплита.
Автокомплит в zsh большой и красивый, но, честно говоря, какие-то сверхнавороченные вещи, кардинально отличающиеся от bash, я не использую, так как в большинстве своём они не интуитивны. Но, если говорить об интуитивности использования автокомплита при навигации по файлам, то тут zsh может похвастаться «меню», которое, для меня несомненный и большой шаг вперёд по сравнению с bash.
Ведь теперь можно пользоваться не только Tab'ом, но и стрелками.
И что самое замечательное, всё это работает не только локально, но даже и на удалённом хосте:
(функция меню, по-умолчанию отключена)
Но есть в zsh и интересный вариант использования cd (хотя казалось бы, зачем после autocd кому-то может понадобиться cd...)
Допустим, в файловой системе у нас есть такая структура каталогов:
и мы находимся в первом:
магия однако…
bash:
что нибудь разэтакое
(аналогично для копирования)
zsh:
В добавок к вышеописанному варианту из bash, в zsh можно использовать следующую конструкцию:
с помощью которй удалятся все log файлы из текущего и всех нижележащих каталогов
Во многих случаях эта фича («Рекурсивный глоббинг») в сочетании с ls/mv/cp может заменить и упростить сценарии с использованием find
bash:
zsh:
Ну… тут наивно было бы ожидать какого-то сверхпрорыва. Разработчики лишь ввели, так сказать «интуитивное» перенаправление.
При этом используется программа из переменной $PAGER
bash:
zsh:
Операция тривиальная, но «сэкономить на спичках» можно и тут.
Можно ассоциировать файлы по расширению. Например, ассоциировать ini файлы с vim
После этого просто введя имя файла
мы откроем его на редактирование.
Домашние гуру консоли используют этот функционал для открытия фильмов, картинок и документов, но по мне это фанатизм. Повторюсь повторюсь — на десктопах рулит GUI.
Умеренное, ибо для наиболее типичных задач уже все велосипеды давно изобретены, и в 90% случаев хватает простого или непростого однострочника. Посмотрим как тут ведут себя конкурсанты.
По работе мне приходится использовать кампутеры с bash2, bash3 и zsh, поэтому очень наглядно можно видеть их поведение и, можно сказать эволюцию в плане скриптовых возможностей.
Вот как они ведут себя на типичных задачах, типа опроса хостов, генерации однотипных записей для каких нибудь таблиц итп:
bash2:
bash3:
zsh:
При этом zsh более бережно обращается с форматом переменной в цикле, т.е. код
выдаст именно то, что интуитивно ожидается. bash в этом случае отбросит ведущие нули счётчика.
В общем же, скрипты написанные на bash на 99.999% совместимы с zsh (а при использовании каких-нибудь ключей совместимости и на все 100%. Для детальной информации по процентам, пожалуйста внимательно прочитайте раздел COMPABILITY в мане), я, к примеру, для своих скриптов нашёл только одно отличие в плане совместимости — в bash элементы массива нумеруются с 0, а в zsh с 1, что я бы приписал в плюс zsh, так как скрипт будет проще:
bash:
zsh:
Я не стал тут описывать остальные 50 тысяч преимуществ, ключей и прочих опций zsh, ведь как показывает опыт, 90% возможностей любого шелла 99,9% времени не используются. Кроме того, они не дают практически никаких преимуществ в ежедневной работе и не так интуитивны по сравнению с bash, при этом требуя вдумчивой работы напильником в области .zshrc
Если не знать всех вышеперечисленных особенностей, то внешне и по функционалу zsh для пользователя будет абсолютно неотличим от bash, включая все его фишки, типа рекурсивного поиска. Поэтому шелл можно сменить безболезненно, а осваивать постепенно.
zsh входит в большинство полнофункциональных дистрибутивов Linux (а также *BSD + портирован на многие экзотические OS, кажется даже на Windows, но врать не буду — сам не проверял), либо легко доступен через репозитории.
Даже учитывая и используя все вышеперечисленные преимущества zsh, есть пара моментов в которых bash мне удобней:
-опция cdspell, которая исправляет без ненужных запросов, опечатки в путях типа cd /ect на cd /etc
-в убунту, zsh по умолчанию не может правильно сотрудничать с apt, который в bash может предложить неустановленные или похожие пакеты. zsh просто говорит «пакет/команда не найдены».Как победить это я не знаю. РЕШЕНО, см. UPD
* В оригинале конечно всё было совсем даже наоборот, поэтому ради дешевого пиара цитату пришлось гнусно переврать
UPD
1. Спасибо, спасибо. Перенёс топик в Linux для всех
2. Мой конфиг как пример плагиата и неумелой компиляции чужих находок
3. Загадка с меню на удалённом хосте разгадана в комментах — конечно же тут не обошлось без авторизации по ключу
4. Спасибо Imposeren за решение проблемы интеграции zsh и apt в убунту. Чтобы apt в zsh предлагал неустановленные/похожие пакеты необходимо просорсить (от слова source) файл /etc/zsh_command_not_found
5. Переосмыслив все комментарии, редко, но метко обновил топик во имя Луны и чтоб самому не забыть
Чтобы не быть голословным, попробуем рассмотреть это дело в контексте абсолютно субъективного и предвзятого сравнения bash vs. zsh.
Сразу оговорюсь, что не являюсь сторонником консоли на десктопах, хоть и использую линукс дома, всё-таки GUI ближе человеку. Поэтому рассказ пойдёт о вещах, которые скорее пригодятся администратору, чем конечному пользователю, но впрочем кто знает.
Итак, типичные операции администратора: навигация по файловой системе, копирование/удаление файлов, просмотр логов, правка конфигурационных файлов, умеренное использование скриптов для автоматизации однообразных операций. Мм… ничего не забыл?
Пойдём по порядку.
1. Навигация
bash:
классическое для всех *nix (и даже не *nix) шеллов
user@host:/home# cd dir1/subdir1/subdir2
user@host:/home/dir1/subdir1/subdir2#
zsh:
Самая простая и незатейливая на вид, но при этом самая моя любимая фича — это
В сочетании с фичей «раскрытие путей» (т.е. когда вы на самом деле помните весь путь, но вам лень печатать, в таком случае можно ввести только начальные символы) это делает навигацию в zsh быстрее и удобнее примерно в миллион раз (по самым скромным моим подсчётам)
Как говориться, лучше один раз увидеть.
Говоря про навигацию, нельзя избежать заезженой темы автокомплита.
Автокомплит в zsh большой и красивый, но, честно говоря, какие-то сверхнавороченные вещи, кардинально отличающиеся от bash, я не использую, так как в большинстве своём они не интуитивны. Но, если говорить об интуитивности использования автокомплита при навигации по файлам, то тут zsh может похвастаться «меню», которое, для меня несомненный и большой шаг вперёд по сравнению с bash.
Ведь теперь можно пользоваться не только Tab'ом, но и стрелками.
И что самое замечательное, всё это работает не только локально, но даже и на удалённом хосте:
(функция меню, по-умолчанию отключена)
Но есть в zsh и интересный вариант использования cd (хотя казалось бы, зачем после autocd кому-то может понадобиться cd...)
Допустим, в файловой системе у нас есть такая структура каталогов:
- /projects/project1/src/backup
- /projects/project2/src/backup
и мы находимся в первом:
user@host:/projects/project1/src/backup# cd 1 2
user@host:/projects/project2/src/backup#
магия однако…
2. Копирование/Удаление файлов
bash:
что нибудь разэтакое
user@host:/home# rm somelogs201001{12,{14..19},25}.log
(аналогично для копирования)
zsh:
В добавок к вышеописанному варианту из bash, в zsh можно использовать следующую конструкцию:
user@host:/home# rm **/*.log
с помощью которй удалятся все log файлы из текущего и всех нижележащих каталогов
Во многих случаях эта фича («Рекурсивный глоббинг») в сочетании с ls/mv/cp может заменить и упростить сценарии с использованием find
3. Просмотр логов
bash:
user@host:/home# less /var/log/messages
zsh:
Ну… тут наивно было бы ожидать какого-то сверхпрорыва. Разработчики лишь ввели, так сказать «интуитивное» перенаправление.
user@host:/home# < /var/log/messages
При этом используется программа из переменной $PAGER
4. Редактирование конфигурационных файлов
bash:
user@host:/home# vim /somedir/someconfig.ini
zsh:
Операция тривиальная, но «сэкономить на спичках» можно и тут.
Можно ассоциировать файлы по расширению. Например, ассоциировать ini файлы с vim
user@host:/home# alias -s ini=vim
После этого просто введя имя файла
user@host:/home# /somedir/someconfig.ini
мы откроем его на редактирование.
Домашние гуру консоли используют этот функционал для открытия фильмов, картинок и документов, но по мне это фанатизм. Повторюсь повторюсь — на десктопах рулит GUI.
5.Умеренное использование скриптов
Умеренное, ибо для наиболее типичных задач уже все велосипеды давно изобретены, и в 90% случаев хватает простого или непростого однострочника. Посмотрим как тут ведут себя конкурсанты.
По работе мне приходится использовать кампутеры с bash2, bash3 и zsh, поэтому очень наглядно можно видеть их поведение и, можно сказать эволюцию в плане скриптовых возможностей.
Вот как они ведут себя на типичных задачах, типа опроса хостов, генерации однотипных записей для каких нибудь таблиц итп:
bash2:
user@host:/home# for i in $(seq 1 10);do ping -c 1 192.168.0.$i;done
bash3:
user@host:/home# for i in 192.168.0.{1..10};do ping -c 1 $i;done
zsh:
user@host:/home# for i in 192.168.0.{1..10};ping -c 1 $i
При этом zsh более бережно обращается с форматом переменной в цикле, т.е. код
user@host:/home# for i in 192.168.0.{001..100};echo $i
выдаст именно то, что интуитивно ожидается. bash в этом случае отбросит ведущие нули счётчика.
В общем же, скрипты написанные на bash на 99.999% совместимы с zsh (а при использовании каких-нибудь ключей совместимости и на все 100%. Для детальной информации по процентам, пожалуйста внимательно прочитайте раздел COMPABILITY в мане), я, к примеру, для своих скриптов нашёл только одно отличие в плане совместимости — в bash элементы массива нумеруются с 0, а в zsh с 1, что я бы приписал в плюс zsh, так как скрипт будет проще:
bash:
for element in {0..$((${#array[@]})) - 1}
zsh:
for element in {1..$((${#array[@]}))}
Далекоидущие выводы
Я не стал тут описывать остальные 50 тысяч преимуществ, ключей и прочих опций zsh, ведь как показывает опыт, 90% возможностей любого шелла 99,9% времени не используются. Кроме того, они не дают практически никаких преимуществ в ежедневной работе и не так интуитивны по сравнению с bash, при этом требуя вдумчивой работы напильником в области .zshrc
Если не знать всех вышеперечисленных особенностей, то внешне и по функционалу zsh для пользователя будет абсолютно неотличим от bash, включая все его фишки, типа рекурсивного поиска. Поэтому шелл можно сменить безболезненно, а осваивать постепенно.
zsh входит в большинство полнофункциональных дистрибутивов Linux (а также *BSD + портирован на многие экзотические OS, кажется даже на Windows, но врать не буду — сам не проверял), либо легко доступен через репозитории.
Bash strikes back
Даже учитывая и используя все вышеперечисленные преимущества zsh, есть пара моментов в которых bash мне удобней:
-опция cdspell, которая исправляет без ненужных запросов, опечатки в путях типа cd /ect на cd /etc
-в убунту, zsh по умолчанию не может правильно сотрудничать с apt, который в bash может предложить неустановленные или похожие пакеты. zsh просто говорит «пакет/команда не найдены».
* В оригинале конечно всё было совсем даже наоборот, поэтому ради дешевого пиара цитату пришлось гнусно переврать
UPD
1. Спасибо, спасибо. Перенёс топик в Linux для всех
2. Мой конфиг как пример плагиата и неумелой компиляции чужих находок
3. Загадка с меню на удалённом хосте разгадана в комментах — конечно же тут не обошлось без авторизации по ключу
4. Спасибо Imposeren за решение проблемы интеграции zsh и apt в убунту. Чтобы apt в zsh предлагал неустановленные/похожие пакеты необходимо просорсить (от слова source) файл /etc/zsh_command_not_found
5. Переосмыслив все комментарии, редко, но метко обновил топик во имя Луны и чтоб самому не забыть