Комментарии
Всегда читая такие хвальбы zsh — думаю как же он сложен (не интуитивен) по сравнению с… с тем, с чем его обычно сравнивают — с bash..., наверно потому, что если Вы пользуетесь башем лет 10 — уже не возможно пользоваться этим zsh, преимуществ намного меньше чем затрат на переобучение!
До этого я тоже пользовался башем 10 лет, и у меня тоже был любимый отточенный bashrc. Новые функции очень, на мой взгляд, интуитивны, а переход абсолютно прозрачен и безболезнен. Я гарантирую это(с)
Спасибо за гарантии, но я продолжу пользоваться башем, не вхожу я в те 0.3% пользователей которым интересны специфичные фичи zsh…
Я в какой-то момент решил, а почему бы и не попробовать? Спионерил у коллеги его конфиг, сделал приглашение как в баше и chsh'нулся в zsh.

А теперь так привык, что пришлось повторить ту же операцию на большинстве своих серверов :)
Не совсем безболезнен, некоторые вещи в zsh работают немного иначе (но у многих имеется возможность настроить под баш) — к примеру обработка кавычек
echo =bla
zsh: bla not found
а теперь
setopt NO_EQUALS # в bash и без установки этой переменной работает
echo =bla
=bla
ну и много ещё чего раздел COMPATIBILITY мана намекает =)
а так да, большинство разницы не заметит =)

вот кто-бы научил автодополнения свои делать (к примеру для своего софта) цены бы ему не было, а так да…
«А ты клёвый :)»(с)
Сделаем по справедливости.
В абзац «скрипты написанные на bash на 99.999% совместимы с zsh (а при использовании каких-нибудь ключей совместимости и на все 100%)» впишем любое предложенное вами число.
скрипты написанные на sh на 99.999% совместимы с zsh (а при использовании каких-нибудь ключей совместимости и на все 100%)
а при злоупотреблении башизмами могут всплыть косяки, правда скажем спасибо sha-bang в виде #!/bin/bash а не #!/bin/sh

но опять же повторюсь «большинство разницы не заметит»
Спасибо за ссылки на раздел COMPABILTY, кстати если кто поленился посмотреть, то там описана совместимость и с другими шеллами, типа csh и ksh.
Если кто-то загорится переписать свои скрипты на zsh это будет пригодиться.
Я не претендую на звание скриптописателя, мои 1-3-5ти строчники обычно всегда укладывались в эти 99,999,
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
тут можно посмотреть, но это лишь компиляция из чужих конфигов. Уверен, что вы его допилите в лучшую сторону
Хмм исопльзую zsh о некоторых фичах не знал :)

p.s.
на правах рекламы: telnet mono.org, login: mono
По возможности я бы предпочёл перенести топик в Linux для всех
«for i in 192.168.0.{001..100};echo $i
выдаст именно то, что интуитивно ожидается»
— а что ожидается? Мне, серьёзно, интересно — зная правила написания адресов, в таком виде я восприму последний октет как восьмеричный (001)… или десятичный (100)? Так что сделает zshell?
:) согласен, пример несколько специфичный, и для адресов не подходит, именно поэтому там было echo, а не ping. Выведется
192.168.0.001
192.168.0.002
192.168.0.003

Этот синтаксис больше подходит для генерации каких-нибудь имён аккаунтов/хостов итп, чтобы вместо
host1

host10
выводилось
host01

host10

Это удобней, когда сортировка при отображении в каком нибудь GUI происходит по первым цифрам

имеется ввиду, что 001 это 1 в 8ричной системе счисления. Поэтому логика у баша совершенно прямая, никаких двойных стандартов. zsh в 0666 0 же не отбросит.
Не совем понятен вопрос, zsh позволяет использовать оба варианта, вы же выбираете какой вам больше подходит для вашего конкретного случая. Я бы назвал это словом «гибкость»
Не понятно в какой сейчас системе счисления определена переменная. Есть стандарты, если незначащий 0 впереди, то восьмеричная, если 0x, то 16тиричная. Как бы такое поведение баша не с потолка взято.
Абстрагируйтесь же наконец от IP адресации. Конструкция for и шелл скриптинг используются не только сетевыми инженерами. Если склероз мне не изменяет, то в bash переменные нетипизированы, и всё зависит от контекста. В большинстве (моих) случаев это будет строка, а не восьмеричное число.
Можно поспорить, кому что интуитивнее — многие, например, привыкли к C-style нотации («0» — octal, «0x» — hex). «00» для обозначения восьмеричности я уже и не помню, когда последний раз видел…
НЛО прилетело и опубликовало эту надпись здесь
По-моему, единственная киллер-фича zsh — его меню автодополнения (или как это называется). Сейчас прикинул, это единственное, что меня держит на zsh, появилось бы такое в bash — вернулся не раздумывая, люблю стандартные вещи. А вообще, пост — вода, зато название громкое, прям как пук. Не какие-то гипотетические возможности надо показывать, а как это все правильно настраивать.
Автодополнение в баше, я бы сказал на 90% такое же мощное как и в zsh, ведь вы можете свободно писать свои скрипты. Вы правы, этот пост пук и попса, написан он лишь для того, чтобы дать толчок и увлечь человека. Большинство же описанных фич (за исключением меню), довольно тривиальны, и, к примеру, уже включены в стандартном zshrc в убунту.
Конкретные настройки слишком скучны (хотя я выложил свой конфиг), я думаю лучший вариант это эксперименты с готовыми конфигами гуру из интернетов.
ммм, а как он узнаёт структуру каталогов на удалённом хосте, ведь пароль же надо ввести.
да, там был небольшой подвох :), конечно без ключа/пароля вам никто не даст листать файловую систему, какой бы там интеллектуальный ни был автокомплит.
Вы уж извините меня за склонность к эффектам в ущерб эффективности
замечательно :) только причем тут линагз? zsh есть только в линагзе чтоле? :(

уже давно живу только на zsh. до этого пользовался csh. никаких гавнобашей в глаза не видел и видеть не желаю, а любителей поменять руту шелл на гавнобаш во фрибсд прилюдно надо жопой на кол сажать!111 :)
Linux тут при том, что он мне ближе (по работе и доме). Ну вы наверно знаете — своя рубашка ближе к телу и всякое такое…
Конечно zsh есть и в других измерениях, типа *BSD, портирован он и на экзотические для меня системы типа AtheOS и др.
Чёрт, неужели кто-то воспринял это как лозунг, и из-за этого коллегу из *BSD немножко проминусовали? А ведь он просто поделился информацией. Дружно делаем хоровод и начинаем монотонно напевать «zsh вне политики и религии. zsh вне политики и религии...»
Про убунту. Есть скриптик:
/etc/zsh_command_not_found

Поидее его достаточно просто сорсить в профиле zsh:
source /etc/zsh_command_not_found

(проверить не могу — нет убунты)

Кстати, про телепатический cd не знал… надо же )=
Вы мой кумир — я проверил и дело действительно было в zsh_command_not_found. Былы бы вы весь из золота, цены бы вам не было
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Когда в последний раз глядел на zsh сильно мешало только то что после установки пакета, необходим перезапуск шела, чтобы он начал автодополнять по его содержимому.
НЛО прилетело и опубликовало эту надпись здесь
Ввести zsh не поможет, ведь это будет суб-шелл со своими параметрами.
Я знаю два варианта решения: опцией в zshrc, отключающей такое поведение (платой за это будет скорость работы автодополнения, так как кеш будет пересоздаваться/перечитываться каждый), другой — это функцией/алиасом, опять же в zshrc которая форсированно обновляет кеш. К сожалению не помню название опций, так как это сам не использую, но если найду то сообщу.
Спасибо
Тогда, судя по интернетам наверно так:
alias rehash='source ${HOME}/.zshrc; rehash'
Необязательно. Если нужно перегенерировать только хэш для автодополнения, то хватит просто rehash.
Когда-то давно работал на zsh…
В убунту баш ушел очень далеко от стандартного и очень удобен. Всевозможные дополнения (в т.ч. аргументов команд, пакетов из репозитория и т.п.), подсветки — все это уже готовое. Если переходить на zsh, то надо все настраивать заново.
Сейчас, единственное, что мне не нравится в bash — это косяки с длиной командной стоки с русскими буквами. Иногда слишком длинная строка не помещается в экран, и когда прокручиваешь такие строки стрелками вверх-вниз, то они начинают сползать влево или вправо. В итоге курсор показывается в одном месте, а реально он в другом. Начинаешь редактировать строку и видишь, что редактируешь совсем другое место. Пару раз нажмешь Crtl+L, потом зодолбаешься, сотрешь нафиг и наберешь полностью заново.
Корень проблемы в том, что где-то внутри баш не очень хорошо поддерживает юникод. То есть длина стоки определяется как кол-во байт в ней, в итоге курсор ставится не туда куда надо.
Впрочем в 4 версии это обещали пофиксить.
у меня такое было, когда коряво была прописан prompt (был цветной, неправильно прописан закрывающий символ, моя вина), тогда да, bash ломал строку команд. Исправил промпт — все стабильно как скала. Покопайтесь у себя — не должно быть таких косяков, у меня их нет :)
И вроде эта проблема возникает не из-за уникода, а из-за неверной обработки экранирующего символа "\" (которым пробелы делают), bash считает, что это относится к метасимволу (который где-то пропущен) — вот и получаются ошибки.
У меня промпт одноцветный.
А вот насчет пробелов — надо проверить.
Нумерация с единицы, имхо, больше минус, чем плюс. Везде с 0, и тут тоже интуитивно ожидаешь с нуля.
не войдя в посто я подумал что у баша появился какой-то достойный конкурент, а вы все о своем)) пойду дальше
zsh: command not found
Как-то не хочется ставить. Много скриптов требуют bash, а zsh никому не нужен. И не уверен я что на другой машине куда я зайду по ssh он будет установлен.
НЛО прилетело и опубликовало эту надпись здесь
попробую поставлю)
поработаю, и тогда можно будет уже уверенно написать, что вы меня переубедили! ;)
=(

bindkey "\e[1~" beginning-of-line
bindkey "\e[4~" end-of-line

не заработали клавиши Home и End.
еще пару лет назад zsh не дружил c UTF-8, если сейчас ситуация поменялась, то ура
Поменялась. Давно уже не видел проблем с многобайтовыми кодировками в zsh.
никаких убийственных фич не увидел, только лишние заморочки, если привыкнешь к этому zsh — придется везде его ставить, вот это гемор ;) а bash есть везде и его, с его обычными авто-дополнениями хватает вполне
не то чтобы совсем давно я перешел на линакс. Мне очень понравилось, его unix-way философия, делать атомарные штуки, которые делают что-то одно, но делают это очень круто.
Мне как-то ближе использовать mv/cp/grep/ls/ — потому что это разные утилиты, очень хорошо понятые мною, предсказуемые и я знаю, что оно зделает в результате.
zsh как по мне противоречит unix-way. Пытаясь сделать собой все, и не делая этого досконально. Это как виндоус — всего по чуточке и ничего конкретно.
Для меня zsh — это прежде всего удобный и мощный рабочий инструмент, а не икона, философия итд. Ежедневное обслуживание десятков *nix хостов как-то знаете быстро выветривает из головы всякие абстрактные и сакральные вещи, оставляя лишь прагматизм и заставляя тщательнее выбирать инструментарий. И никто в zsh не отменял mv/cp/grep/ls/ и умение ими пользоваться. Никогда до запуска скайнета компьютер не будет делать за вас вашу работу.
Читаете мои мысли. Тоже почитал бы и посмотрел примеры в картинках. По распространенности fish'у далеко до bash и zsh, так что для серверов это не вариант, но для домашнего использования выглядит привлекательно. Родина вас не забудет, если сделаете обзор. Если с ходу — то мне понравилась детализация в ls. Другое, что бросилось в глаза — расцветка введёных команд (правильных зелёным, ошибочных красным) не очень актуально для опытных пользователей и лишт отвлекает.
мне кажется, что такое дополнение как в zsh меркнет с использованием Ctrl+R в bash. ну это потому что, если вы знаете, что такими буквами попадете куда надо, то это значит с большой вероятность, что вы там уже были и команда cd в нужную директорию у вас уже есть в памяти, и ее оттуда вытащит продвинутый поиск по истории (Ctrl+R).
а вообще, конечно, вопрос скорее привычки, чем юзабилити. по мне и то и то удобно, просто привык уже к башу. но за статью все равно спасибо — если возникнет идея что-то поменять в жизни начну с шелла)
Вы вот мне ни за что не поверите, но то что я 10 лет пользовался bash и фраза «Если не знать всех вышеперечисленных особенностей, то внешне и по функционалу zsh для пользователя будет абсолютно неотличим от bash» как бы намекает. Про Ctrl+R как бы в том числе. Понимаете к чему я клоню?
честно говоря, не очень. если не знать «всех вышеперечисленных особенностей», то все шеллы отличаются только приглашениями для ввода, как я понял. тогда какой смысл переходить с одного на другой? или вы как бы рекламировали для начинающих — мол, не только bash в этом мире есть и если начинать с чистого листа, то попробуйте zsh, что ли…
Для каждого человека характерен консерватизм и инертность мышления. В этом нет ничего плохого и удерживает нас от необдуманных поступков и непроверенных решений. Абстрагируйтесь вы от названий bash и zsh, судя по всему всё новое вызывает подсознательное сопротивление. Называйте для себя этот шелл не zsh, а bash2010 или bash Reloaded, или как то иначе. Понимаете, он в включает в себя все функции которые есть в bash + немножко плюшек за ту же цену. Вот наверняка же вы хоть раз задумавшись вводили не
user@home:/# cd /etc
а
user@home:/# /etc
(потеряли cd)
а ведь шеллу в этом случае ничего не стоит помочь вам и сделать именно то что вы хотели. так и во всех остальных моментах — прогресс не стоит на месте, и сейчас шелл может делать немножечко больше чем 20 лет назад, когда компьютеры были большие а памяти было мало
Когда я пару месяцев назад узнал и перешел (тут же) на zsh, единственная мысль была: «какого черта баш стоит по умолчанию». Мой консерватизм видимо сломан…

пс
готовые конфиги есть на github (логично!).
> Надеюсь, после прочтения топика вы тоже смените старый добрый, но, как по мне, так застрявший в прошлом, bash на более удобный и продвинутый zsh.

А zsh не застрявший в прошлом? «4.2.7 / December 18, 2007; 2 years ago» — мне даже страшно такое ставить, вдруг оно уже неадекватно реальности.
1) мсье автору уже сказали, что cdspell в zsh уже есть три тыщи лет и, например, я его использовал ещё тогда, когда в баше это было не так тривиально.
2) а выложите-ка кто-нибудь содержимое /etc/zsh_command_not_found, пожалуйста? :))
хотя на просторах интернета чудом нашёл нечто типа:

function cnf_preexec() {
typeset -g cnf_command=”${1%% *}”
}
function cnf_precmd() {
(($?)) && [ -n "$cnf_command" ] && [ -x /usr/share/command-not-found/command-not-found ] &}
typeset -ga preexec_functions
typeset -ga precmd_functions
preexec_functions+=cnf_preexec
precmd_functions+=cnf_precmd

// Тем не менее, первый пункт всё ещё в силе :)
можно про 3хтысячелетний cdspell в zsh подробнее?
Вот поведение в zsh:
% cd /ect
zsh: correct /ect to /etc? ([Y]es/[N]o/[E]dit/[A]bort) n
cd: Нет такого файла или каталога: /ect

Вот правильное поведение в bash:
host:~$ cd /ect
/etc
host:/etc$
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.