В предыдущем очерке работа в CLI была рассмотрена на примере Bash — самой распространённой командной оболочки Linux'а. Однако о ней написаны пуды бумажной литературы и мегабайты сетевых материалов, повторять которые было бы скучно. И к тому же в реальной жизни я её практически не использую. Поэтому далее будет рассмотрена оболочка Zsh.
Кроме борьбы со скукой, есть и немало более технических аргументов в пользу применения Zsh как пользовательской оболочки (login shell):
- функциональность, существенно превосходящая возможности
Bash в интерактивной работе;
- расширяемость за счёт дополнительных модулей;
- настраиваемость, ограниченная практически только фантазией применителя;
- прекрасная документированность — объём официальной документации составляет более 3 МБ в формате HTML (не считая прочих форматов);
- активное сообщество энтузиастов — разработчиков и применителей.
Не последним аргументом в пользу Zsh является его отличная интеграция с утилитой apt, лежащей в основе пакетного менеджмента дистрибутива Mint. До сих пор, описывая действия по управлению пакетами в CLI, я, будучи давним пользователем Zsh, приводил их к общему знаменателю с Bash. В один прекрасный момент мне это надоело. Причём отказываться от мощного функционала Zsh, к которому привык так, что без него как без рук, не не собираюсь. И потому решил впредь помещать в тексты своих сочинений команды в «Zsh'изированной» форме. А для пояснения их сути — написать настоящуюю серию мини-очерков и включить её в книгу про Mint.
Zsh как login shell
В Mint в качестве системной командной оболочки, то есть интерпретатора общесистемных сценариев, выступает Dash (Debian-клон оболочки Альмквиста,ash), лёгкая и компактная, но имеющая слабые возможности для интерактивной работы. Для последней, как и в подавляющем большинстве дистрибутивовLinux, используетсяBash, которая является пользовательской оболочкой (login shell) по умолчанию. Что же доZsh, она отсутствует в стандартной инсталляцииMint`, но доступна в официальном репозитории, из которого легко может быть установлена.
Начинающему применителю Mint проще всего установить Zsh с помощью описанного ранее менеджера пакетов. Для чего сначала надо отыскать соответствующий пакет:
После чего поглядеть на его описание и установить:
Однако просто иметь Zsh мало — его надо сделать регистрационной оболочкой (login shell) в своём аккаунте. Как ни странно, в обоих графических модулях Системных настроек Cinnamon такой возможности нет. Однако можно прибегнуть к графической утилите usermode, предварительно установив её через Менеджер приложений и запустив из главного меню, где она скрывается в секции Параметры под именем О себе и после запуска выглядит таким образом:
После установки Zsh её можно будет выбрать из выпадающего списка в поле Оболочка:
Кажется, это единственное, что может сделать полезного данная утилита. Поэтому возникает вопрос — а стоит ли устанавливать её ради разовой операции? Может быть, лучше прибегнуть к самому простому способу смены login shell — прямой команде? Тот этой:
Вопрос, как вы понимаете, риторический…
Каким бы образом ни была назначена Zsh любимой женой пользовательской командной оболочкой, следующая авторизация данного пользователя в «голой» консоли однозначно её запустит. В эмуляторах же терминала, возможно, потребуется внести некоторые изменения в их настройках, например, предписать запуск /bin/zsh явным образом, или отметить опцию запуска оболочки как login shell.
В любом случае первый запуск сеанса пользователя с новой оболочкой предложит такие варианты выбора:
- q — выход из программы автоконфигурирования без последствий; при следующем входе в оболочку вызов её будет повторён;
- 0 — выход из автоконфигурирования с созданием пустого конфига
~/.zshrc, предотвращающем в дальнейшем повторения автоконфигурирования;
- 1 — вызов главного меню;
- 2 — создание конфига
~/.zshrc по образу и подобию эталонного, /etc/zsh/newuser.zshrc.recommended, который в дальнейшем может редактироваться вручную.
С вариантом q всё ясно, это просто откладывание вопроса на потом, вариант 1, с автоконфигурированием, был некогда описан достаточно подробно, и с тех пор процесс этот ничуть не изменился, вариант же 2 зависит от настроек общего конфига оболочки, принятых майнтайнерами данного дистрибутива. Так что я хотел бы сконцентрировать внимание на «нулевом» варианте. И последовательно рассмотреть все настройки, которые потребуется выполнить применителю для создания комфортной среды CLI. Не абстрактно, разумеется, а применительно к целям и задачам себя, любимого. Так что читатель должен воспринимать всё сказанное в этих очерках далее, не как догму, а как руководство к действиям, то есть экспериментам, и к размышлениям о своих потребностях.
Однако прежде отмечу, что применителю не обязательно сразу определять Zsh как login shell. Он может вызвать её из командной строки Bash:
Запуск Zsh ознаменуется сменой вида приглашения командной строки с Bash'евской, которая в Mint'е по умолчанию выглядит так:
на умолчальную Zsh'еву:
Вот с настройки вида приглашения командной строки я и начну. Добавив только, что после каждого изменения в конфиге ~/.zshrc для вступления его в силу вовсе не обязательно завершать сеанс и авторизоваться заново — достаточно такой команды:
Кстати, конфигурационных файлов для Zsh предусмотрено много, и порядок их считывания тоже определён жёстко. Однако далее речь будет идти, за одним специально оговоренным исключением, только о редактировании ~/.zshrc. Почему? Да потому, что остальные конфиги или были придуманы для совместимости с оболочкой совсем другого семейства, Tcsh, или не оказывают влияния на пользовательский сеанс.
Документация
Но прежде чем перейти к настройкам Zsh, надо сказать несколько слов о его документации, столь расхваленной мной во вводных словах. И первое, что тут удивляет — отсутствие для его текущих версий (5.0.X) стандартных man-страниц. Раньше они были, причём во множестве: собственные страницы были посвящены отдельным частям этой оболочки (опциям, параметрам, функциям etc.), а сама по себе страница man (1) zsh играла роль оглавления.
Но со временем суммарный объём man-документации достиг такого размера, что ей стало практически невозможно пользоваться в том режиме, в котором мы все привыкли общаться с любимой тётей Маней. И потому разработчики Zsh от man-страниц в составе самого пакета отказались.
Но зато, во-первых, пакет zsh и жёстко с ним связанный zsh-common сопровождается пакетом zsh-doc, который в большинстве дистрибутивов (в том числе и в Mint) следует устанавливать отдельно. Он содержит материалы в форматах info и html общим объёмом 6 МБ, а также включает PDF-руководство на 400 страниц.
Во-вторых, Zsh сопровождается также пакетом zsh-lovers — он также устанавливается отдельно, и его компоненты после этого будут располагаться в каталоге /usr/share/doc/zsh-lovers. Он озаглавлен так: Советы, рекомендации и примеры для Z Shell. И содержит большинство тех самых man-страниц, которые были изъяты из основного пакета — в чисто текстовом формате или в виде gz-компрессированных файлов. А также — заявленные советы, рекомендации и примеры, созданные многочисленными применителями этой оболочки. Все они поимённо перечислены в файле /usr/share/doc/zsh-lovers/README. Своего рода квинтэссенцией пакета является страница man (1) zsh-lovers, в конспективной форме описывающая основные возможности этой оболочки, иллюстрируя их примерами. Собственно, её обзор (OVERVIEW) и начинается словами:
Каждый раз, когда мы заглядываем в руководство по Zsh, мы удивляемся, почему там нет примеров или просто случаев из жизни в командной оболочке. Возможностей у Zsh, много, а руководства, иллюстрирующего их примерами, нет. Поэтому мы написали своё руководство. … Это просто развлекухи ради.
И, надо сказать, развлекуха получилась не без пользы для нас, применителей. Кстати, читать эту развлекуху можно также в форматах HTML и PDF.
В-третьих, неисчислимое по объёму количество информации о Zsh'е имеется в Интернете — и всё это богачество доступно по ссылкам с официальный сайт, главнейшей из которых является ссылка на zsh.sourceforge.net. Здесь можно найти руководства по этому шеллу на любой вкус — от «юзерофильного» до исчерпывающего, а также ссылки на книги, wiki, статьи и прочие материалы. Разбираться в этом океане я предоставляю заинтересованным (или заинтересовавшимся) читателям.
В-четвёртых, существует сайт, именуемый Oh My ZSH!. Это коллекция плагинов, скриптов, конфигов и тем приглашения командной строки. Она инсталлируется на локальную машину и в дальнейшем автоматически синхронизируется с родительским сайтом, который пользуется всенародной популярностью и широкой известностью в узких кругах энтузиастов Zsh.
Наконец, в-пятых, официальными, полуофициальными и общенародными ресурсами информация о Zsh не исчерпывается — существует много «неучтённых» на zsh.sourceforge.net сайтов и блогов, ведомых любителями этого шелла. И на них часто можно найти освещёние неожиданных и интересных нюансов его конфигурирования. В последние годы в их числе появились и русскоязычные ресурсы. Из последних хотелось бы отметить подборку статей на сайте Михаила Мищенкова aka muhas).
Настройка приглашения
Как известно со времён со времён Константин Сергеича Станиславского, театр начинается с вешалки, а дистрибутив — с инсталлятора. Командная же оболочка начинается с приглашения командной строки. Каковая, во-первых, отражает готовность системы к выполнению действий применителя, а во-вторых, несёт (или должна бы нести) некую существенную для него информацию.
Правда, умолчальное приглашение Zsh информативностью не блещёт, сообщая только имя хоста (в примере на предыдущей странице — alv-cinn), и то, что сеанс шелла запущен обычным пользователем — в отличие от Bash'а, здесь это по умолчанию выражается символом %. Однако добавить информации нам никто не мешает. А помогает — файл zshexports.gz из пакета zsh-lovers, упомянутого в позапрошлом очерке. Его можно просмотреть командой
$ zcat path3/zshexports.gz
отыскать в нём секцию, начинающуюся словами
# PS{1,2,3}, RPOMPT, ..
# The "prompt" of the shell
...
внимательно изучить её, а также фрагмент конкретных примеров:
# Some examples:
# PS1="PS1='%B%n%b@%m:%4c>'"
...
осмыслить прочитанное и опробованное на примерах. После чего решить, какую же информацию вы хотите видеть в приглашении командной строки.
Я, например, не хочу видеть там имени хоста, поскольку не дожил ещё до ситуации из известного аккордеонистого бояна: «Кто я, кто я? Губайдулин я!» Да и вообще, времена, когда каждая машина в сети имела собственное неповторимое имя, канули в лету, и нынче так называемое «хвостнаме» берётся от булды.
А вот имя пользователя в явном виде будет не лишним — у меня на основной машине их обычно не менее трёх: рабочий, экспериментальный и умолчально-восстановительный. Также неплохо иметь представление о своём положении в файловой иерархии, причём в полном виде — одноимённые подкаталоги часто находятся в разных её ветвях. Приглашение получается перегруженным? Отнюдь, потому что в Zsh таковых предусмотрено два — просто PROMPT и RPROMT, и перечисленные элементы можно разнести таким образом:
/home/data/current $=> [alv]
Или наоборот, таким:
[zshuser]$=> [/home/data/current]
Добиться этого можно, как вы понимаете, редактированием файла ~/.zshrc. До сих пор он у нас содержал единственную строку комментария:
# Created by newuser for 5.0.2
Теперь же добавляем в него сторки для получения приглашения первого вида:
## Prompt
PROMPT='%~ $=> '
RPROMPT=' [%n] '
Или второго:
## Prompt
PROMPT='[%n]$=> '
RPROMPT=' [%~] '
Раньше мне больше нравился первый вариант, но ныне я перешёл на второй.
Кроме обычного, то есть «левого» приглашения и приглашения «правого», в Zsh поддерживаются также приглашение «вторичное», выводимое в многострочных командах, и «третичное» — предложение вариантов замены при включённой коррекции ошибок, PROMPT2 и PROMPT3, соответственно. Вторичное приглашение у меня имеет вид
В результате в нём выводится номер «вторичной» строки в данном сеансе шелла, указывается стрелкой на то, что ввод следует в ней продолжить, а сам ввод даётся подчёркнутым шрифтоначертанием. Вживе это выглядит так:
[zshuser]$=> echo $USER \ [~]
33> echo $SHELL \
34> echo $PATH
zshuser echo /bin/zsh echo /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Что же до коррекции ошибок, у меня она отключена (к этому вопросу мы ещё вернёмся).
А вообще, как можно увидеть в файле zshexports.gz, в любом из видов приглашения командной строки могут фигурировать:
- полное или сокращенное имя хост-машины;
- путь к текущему каталогу в различных формах;
- номер текущей команды в буфере истории или строки в данном сеансе работы;
- имя пользователя;
- название командной оболочки;
- номер виртуальной консоли или текущего терминала;
- дата и время в разных форматах;
- индикация работы от лица суперпользователя;
- любые символы типа стрелок, крышечек, скобочек;
- текстовые сообщения (например, поздравление с началом трудового процесса);
- и многое другое.
Кроме того, приглашение могут быть оформлены визуально различно: выделением жирным шрифтом (boldface mode), инвертированием текста/фона (standout mode), полчёркиванием (underline mode), а также цветами. «Раскрашенный» шелл мне нравится не больше, чем «раскрашенный» Штирлиц, инвертирование также вызывает раздражение, а вот выделение полужирным шрифтоначертанием и подчёркиванием я использую. В результате секция настройки вида приглашения в моём ~/.zshrc выглядит так:
# Left prompt
PROMPT='%B[%n]$=>%b '
PROMPT2='%i%U> '
#
# Right prompt
RPROMPT=' %B[%~]%b '
Как уже говорилось, я не призываю к подражательству, а лишь предлагаю поэкспериментировать, чтобы добиться максимальной информативности приглашения и его внешней выразительности.
Темы приглашений
Только что речь шла о том, как оформить приглашение командной строки Zsh своими руками, в соответствие с собственными вкусами и предпочтениями. Однако можно пойти другим путём, и воспользоваться уже готовыми темами приглашений. Они входят в пакет zsh-common, который всегда, насколько я знаю, устанавливается как зависимость пакета zsh. После установки местоположение готовых тем — каталог /usr/share/zsh/functions/Prompts.
Сами по себе темы приглашения — файлы вида prompt_themename_setup, представляющие собой функции Zsh, описывающие как вид приглашения, так и, часто, некоторый его декор, типа расцветки, которая может быть нескольких видов. Однако разбираться в устройстве этих функций не обязательно — с ними можно ознакомиться визуально.
Знакомство это начинается с запуска функций управления видом приглашений:
$ autoload -U promptinit && promptinit
После чего можно давать команду на «смотрины невест»:
которая выведет их все (в моей системе — около двух десятков, плюс цветовые вариации) примерно в таком виде:
Среди «невест» можно видеть весьма пёстро наряженных:
Но и одетых весьма скромно также есть:
Выбрав подходящую невесту тему, её можно тут же установить командой
при желании — с указанием цветовых параметров, например:
$ prompt fade white grey blue
Что в «живом» терминальном окне (терминал Sakura) будет выглядеть так:
А в выпадающем терминале Guake — несколько иначе:
Кстати, а в «голой» консоли вид этой же темы будет существенно скромнее — разбираться с программами для изготовления скриншотов консоли мне было лень, так что прошу поверить на слово.
Установленная таким образом тема будет функционировать только в данном терминальном окне в течении текущего сеанса. Чтобы увековечить её, необходимо вписать в файл ~/.zshrc такие строки:
autoload -Uz promptinit
promptinit
prompt clint
В примере приведена тема, пожалуй, наиболее информативного приглашения, которое «вживе» вылядит так:
Большое количество тем можно при желании отыскать на сайте Oh My ZSH!, но эти я уже заниматься не стал.
Приёмы навигации
Сознательные граждане, активно применяющие CLI, используют множество команд, как встроенных в их любимый шелл, так и внешних. Но, думаю, что самыми употребимыми в повседневной жизни являются такие:
pwd для определения своего текущего положения на файловом древе — да-да, иногда, после многократных переходов между подкаталогами, забываешь, не только кто я, но и где я (уж не в Тимирязском ли?);ls — для просмотра содержимого текущего каталога;cd — для перехода в определённый каталог.
Однако здесь Zsh вносит свои коррективы, здорово облегчающие жизнь его применителя. Только что было показано, как фактическим можно избавиться от команды pwd, выведя путь к текущему каталогу в качестве RPROMPT. Без команды ls, конечно, не обойтись и Zsh. А вот команда cd в Zsh просто… не нужна.
Да, дорогие мои болельщики, в среде Zsh без этой команды не просто можно обойтись, а жить куда комфортней, нежели с ней. Ведь давайте вспомним, что такое переход в каталог имя_рек? Для типа файлов, именуемого каталогом (directory) это то же самое, что исполнение для обычного (ordinary) файла, будь он откомпилированным бинарником или интерпретируемым сценарием.
И потому более чем логично то, что как для запуска скрипта оболочки не требуется никакой внешней команды (хотя и не возбраняется что-нибудь типа . или /bin/sh), так и для перехода в каталог, к которому данный юзер имеет доступ (то есть попадает в число тех, для кого у этого каталога установлен бит исполнения), ему достаточно указать полный путь к нему, без всяких команд. Например, введя к командной строке что-нибудь вроде
$ /usr/share/fonts/truetype/
можно сразу оказаться в каталоге с TTF-шрифтами.
«Бескомандный» переход в каталоги распространяется и на «символические» обозначения последних. Так, команда
переместит пользователя в его домашний каталог. Как, кстати, и команда
Хотя практического смысла последний вариант не имеет. Зато директива
волшебным образом ознаменует переход в каталог, родительский относительно текущего.
Правда, всё это происходит не само собой: для практического воплощения этого волшебства в общесистемном конфиге /etc/zsh/zshrc или пользовательском ~/.zshrc должна присутствовать строка
В пару к ней можно добавить ещё и такую строку:
cdpath=(~/ /home/current/ /home/data/)
где в скобках перечислены каталоги, к подкаталогам которых чаще всего требуется быстрый доступ. И теперь, где бы в пределах файлового древа ни находился пользователь, ввод им директивы
нечувствительно сделает текущим каталогом /home/username/Documents.
То есть опция autocd и массив переменных cdpath отнюдь не исключают, а прекрасно дополняют друг друга.
Автодополнение
Волшебное свойство клавиши Tab, вызывающей автодополнение — одно из первых, с чем знакомится применитель CLI. Хотя при этом часто забывается, что когда-то, в перворождённом шелле Борна, никакого автодополнения не было. Оно появилось в Csh — и сначала только для путей, но не для команд. Тем не менее, ныне представить себе интерактиную работу в командной строке без автодополнения невозможно (да и не нужно).
Однако в Zsh клавиша Tab волшебна дважды: она не только дополняет пути и команды после их частичного ввода, но и способна развернуть аббревиатуры для тех и других. Например, нажатие клавиши табулции после набора последовательности
развернёт её в полный путь к каталогу со шрифтами TrueType
$ /usr/share/fonts/truetype
а после нажатия клавиши Enter сделает этот каталог текущим, как мы только что видели.
Правда, само по себе развёртывание аббревиатур работать не будет — его надо активизировать такими строками в файле ~/.zshrc:
autoload -Uz compinit
compinit
Можно пойти дальше, и не просто разворачивать безальтернативные аббревиатуры, типа приведённый выше, но и выбирать стрелками, как в меню, подкаталги или файлы среди предлагаемый альтернатив. Например, если набрать ту же самую последовательность символов:
а затем дважды нажать клавишу табуляции, то она не только развернётся в полный путь
$ /usr/share/fonts/truetype/
но и выведет список подкаталогов указанного каталога:
dejavu/ freefont/ openoffice/ ubuntu-font-family/ droid/ liberation/
ttf-dejavu/ wqy/
И выбор нужного среди них можно выполнять либо стрелками управления курсором, либо обычными кейбиндингами типа Control+f, Control+b и им подобными:
Правда, и такая реакция Zsh на Tab возникает не из воздуха, а из присутстствия в файле ~/.zshrc таких строк:
setopt menucomplete
zstyle ':completion:*' menu select=1 _complete _ignored _approximate
По умолчанию их там нет, а вот стоит ли их вносить — применитель должен решить для себя сам — перебор вариантов традиционным способом, то есть последовательным нажатием клавиши табулции, может показаться более удобным.
История команд
Возможность просмотра истории введённых ранее команд клавишами Up/Down кажется таким же неотъемлемым атрибутом CLI, как и автодополнение командной строки. И, как и последнее, напрочь отсутствовало в перворождённом шелле Борна, однако ныне имеется во всеш развитых шеллах. Причём доступ к истории команд в них не ограничивается командой history и упомянутыми стрелками. В частности, в Bash широко практикуется инкрементный поиск по клавишной последовательности Control+R и вводу последовательности символов одной из предыдущих команд или её аргументов.
В tcsh же испокон веков существовала (и, что характерно, обычно была активирована по умолчанию) другая возможность — так называемый history-substring-search, то есть инкрементный перебор истории команд по вводимым символам. Что это такое — проще пояснить на примере: вы вводите в командной строке один символ (для примера — s) и нажимаете клавишу Up. И тут в перебор включаются только те команды из истории, которые с буковки s начинаются. Вводя дополнительные символы, можно сузить круг поиска: например, последовательность sudo позволяет просмотреть, что было наколбасино от лица суперпользователя вообще.
Поскольку Zsh изначально задумывалась как синтез всех передовых достижений шелло-строительной мысли, аналогичная возможность имеется и здесь. Правда, как и многие другие продвинутые фичи этой оболочки, она требует активации. То есть — внесения в файл ~/.zshrc таких строк:
bindkey "^[[A" up-line-or-search
bindkey "^[[B" down-line-or-search
Как выяснилось, надо подчеркнуть: перебор history-substring-search и инкрементный поиск по Control+R отнюдь не исключают друг друга, а дополняют: первым способом проще искать ранее введённые директивы по имени команды, вторым — по её аргументам, например, по имени файла.
Справедливости ради надо сказать, что history-substring-search нынче реализован и в Bash, хотя, как и в Zsh, требует активации.
Опытный применитель Zsh, не имевший ранее дела с Ubuntu и её производными (в том числе и с Mint'ом), будет весьма удивлён тем обстоятельством, что эта фича (по моему мнению, одна из самых полезных среди всех достоинств нашей героини), с кондачка работать не будет. Даже при условии правильно настроенного конфига — при внесённых в него строках, указанных выше. Точнее, не будет делать это в окне любого иксового эмулятора терминала, хотя не откажется от выполнения history-substring-search в «голой» консоли. Причём интересно, что это же касается и Bash, хотя в Tcsh данная фича будет работать «искаропки».
Следствие, проведённое в Джуйке и благодаря участию джуковца @altwazar'а, показало, что это давний известный баг, восходящий к Debian'у, знаменитому своей стабильностью во всех отношениях (в том числе и в отношении багов, вероятно). И бороться с этим можно различными методами. Мне самым простым показался такой: создание в домашнем каталоге файла ~/.zshenv с единственной строкой:
DEBIAN_PREVENT_KEYBOARD_CHANGES=yes
Разумеется, на поведение Bash это никак не скажется: в нём history-substring-search включается не через его профильный файл, а через inputrc — конфиг для readline. Как именно — оставляю на рассмотрение преданных поклонников этой оболочки.
Разумеется, возможности настройки доступа к истории команд всем сказанным выше не исчерпываются: имеет место быть и исключение из неё дубликатов, и пустых строк, и прочего баласта, а также подключения некоторых полезных фич, вроде ограничения общей истории и истории текущего сеанса. А также — дополнения файла истории. Однако ничего особенного, специфичного именно для Zsh, тут уже нет. Так что к рассмотрению этих вопросов я вернусь под занавес — когда буду говорить о ~/.zshrc для себя, любимого...
Рекурсивный поиск
Все применители CLI знают и любят утилиту find — и любят заслуженно, ибо это апофеоз командного интерфейса: с её помощью можно отыскать в файловой системе всё, что угодно — и почти всё, что нужно, с найденным сделать, конечно, с помощью некоторых дополнительных средств, вроде xargs и конвейеров. Однако для многих рутинных задач мощь этой команды кажется излишней, напоминая знаменитое упражнение по отстрелу мелких пернатых их зенитно-ракетных комплексов. И вот тут Zsh опять позволяет решать такие задачи малой кровью — то есть с минимальным ударением по клавишам. Ибо поддерживает такую штуку, как рекурсивные поиск.
Что это такое — как обычно, проще показать, чем рассказать. Предположим, перед применителем стоит задача отыскать все картинки в каталоге некоего проекта, включая все вложенные в него подкаталоги. Средствами Zsh сделать это очень просто — достаточно дать команду
где path3, как нетрудно догадаться, «корневой» каталог поиска, *.png — маска искомых файлов, а «двузвёздие» — так сказать, директива рекурсивного поиска.
Правда, вопреки утверждениям некоторых уж очень правоверных Zsh'истов, эта возможность не делает команду find избыточной, ибо, как все знают, она умеет и многое другое. Но зато такая простая директива позволяет не беспокоить Её Величество по пустякам...
А заодно — конструкции вида **/* можно использовать как аргументы команд управления файлами, таких, как cp, mv, rm. В частности, с помощью команды вида
можно легко гуртом избавиться от всех временных копий, которые по умолчанию так любят сохранять некоторые текстовые редакторы и ворд-процессоры, если им не запретить это самым категорическим образом.
Разумеется, можно фильтровать базар. Давеча в приступе чёрной меланхолии переслушивал я всё, что сочинил и спел Фред Солянов — увы, большинство моих потенциальных читателей о его существовании не подозревают: в отличе от многих всенародно известных так называемых «бардов», он не был популярен при жизни. А когда его верхние люди позвали — люди нижние про него забыли напрочь. И зря — но это из совсем другой оперы. А в нынешней арии мне было интересно, сколько же Фред сочинил песен за ту четверть чека, что ему отпустила на то судьба. И я дал очень простую команду:
$ ls path3/fred/**/*.mp3 | wc -l
И она мне сказала, что сочинил Фред 168 песен. Откидываем дубликаты, неизбежные в любой коллекции — но здесь их очень мало, на штуки счёт.
Откинем откровенно слабые песенки — ведь даже гений не каждое утро начинает с сочинения чего-то шедеврального. Откинем песенки вторичные — Фред никогда не претендовал на основоположничество, и, в отличе от некоторых более иных авторов, на которых я не хотел бы указывать пальцем, не считал для себя западло называть своего реального учителя в ентом деле, Булат Шавловича...
Для себя откину те песенки, которые лично меня не очень зацепили — их, по сравнению с прочими фильтрами, больше всего, почти полсотни.
Остаётся - около ста песен. За двадцать пять лет. Мало по сравнению с раннеперестроечными сборниками типа «Шестьсот лучших песен имя река»? Да, не много. Но ведь (и это мнение не только моё, а тысяч людей с такими же биографиями) эти песни стали, как нынче принято говорить, культовыми.
Ну, дальше на эту тему распространяться не буду, а вернусь к генеральной линии сюжета. А именно — что маски типа **/* можно использовать в аргументах команды grep и для поиска фрагментов текстов. Так, команда
выведет все строки с упоминанием KDE в html-файлах каталога текущего и вложенных. А в форме
$ grep -i kde **/kde*.html
она произведёт аналогичный поиск только в файлах вида kde01.html, kde02.html и так далее. Причём без учёта регистра — но к мадемуазель Zsh, интересы которой я представляю в данный момент, это не имеет никакого отношения.
Перенаправление расширенное и множественное
Что такое перенаправление ввода/вывода — знают все применители CLI. Однако в Zsh возможности его очень широки, почему оно и называется здесь расширенным перенаправлением. Этот механизм позволяет в ряде случаев обходиться без некоторых команд вообще. Например, обычно для просмотра текстового файла применяют или команду cat, или команды-пейджеры типа more, less, most. Выбор между конкатенатором и одним из пейджеров определяется ситуацией, выбор внутри «тройки по борьбе с басмачами файлами» зависит от привычек или предпочтений. Однако Zsh может избавить применителя от мук буриданова осла, подменяя любую из этих команд оператором перенаправления в виде команды
Результатом чего будет постраничный вывод содержимого файла, подобный таковому любого пейджера.
С помощью того же оператора можно просмотреть одновременно содержимое двух файлов — то есть, конечно, не одновременно, а последовательно, но в едином потоке. То есть команда
покажет оба файла как одно целое. Причём в данном случае можно поступить ещё проще, ибо маски имён файлов также не возбраняются:
Кстати, в терминах Zsh развёртывание масок имён файлов называется globbing — с ним мы уже сталкивались в рассказе о рекурсивном поиске.
Число «оперируемых» файлов ничем не ограничено, кроме здравого смысла и целесообразности. Так, есть резон проглядеть таким образом на скорую руку, как будут выглядеть 5-6 заметок по несколько строк каждая, если их объединить в одну статью. Но просматривать с помощью оператора перенаправления книжку, состоящую из пары десятков глав по много страниц каждая, уже явный перебор.
Однако бывают случаи, когда большое число «оперируемых» файлов очень даже уместно. Например, если требуется объединить ряд текстовых фрагментов в единый файл. И тогда, легким движением рук набрав в командной строке конструкцию
$ < chapter[01-10] > mybook
мы на выходе из разрозненных глав получаем готовую книгу.
Таким образом мы перешли уже к множественному перенаправлению. Применение которого просмотром файлов не исчерпывается — их содержимое может быть перенаправлено не только на стандартный вывод, но и на ввод какой-либо команды, подменяя командный конвейер. Например, конструкция вида
совместно отсортирует строки обоих файлов, file_1 и file_2, точно так же, как это сделал бы конвейер команд
$ cat file_1 file_2 | sort
Кстати, перенаправление вполне может играть с конвейерами в одной команде. Например, конструкция вида
$ time commandname [options] [arguments] > filename | cat
занесёт время выполнения некоей команды в файл с одновременным выводом его на экран, заменяя команду tee. Это особенно полезно при всяких «тестированиях на быстродействие», когда надо и сохранить результат для дальнейшей обработки, и не терпится посмотреть на него сразу.
Множественное перенаправление удобно использовать для суммарного подсчёта числа символов в нескольких файлах таким образом:
Что на выводе даст единственное число, например:
Казалось бы, та же команда в «обычной» форме даже короче на один символ:
Однако вывод её будет развёрнут:
2820 my_file_1.txt
606 my_file_2.txt
401 my_file_3.txt
1555 my_file_4.txt
5382 итого
Что при работе во встроенных терминальных окнах текстовых редакторов вроде Geany или Kate , часто небольших по размеру может оказаться лишним. А ведь именно там приёмы, подобные описанным в этом разделе, оказываются весьма эффективными.
В общем, уже за одну только конструкцию < filename разработчики Zsh заслужили памятник, а все остальные возможности расширенного и множественного перенаправления выступают как бесплатное приложение к ней.
Просто псевдонимы и псевдонимы глобальные
Что такое псевдонимы, по простому `aliases, — знают все, кто применяет любую командную оболочку: их поддержка существует со времён перворождённого шелла Борна. Это один из простых способов минимизировать ввод командных директив, начиная с простейшего рекурсивного копирования файлов:
И заканчивая бессчётным количеством псевдонимов для команды ls.
Однако в Zsh есть ещё одна фича — глобальные псевдонимы, по сей день не имеющие аналогов, насколько я знаю, во всяких там ваших башах. И даже в почти соплеменных тсишах их нет.
Но начну по порядку. Опять же, кого не раздражала ситуация: в ответ на поиск файла find'ом или поиск фрагмента текста grep'ом выдаётся сто пятьсот экранов сообщений, что доступ к каталогу запрещён?
Разумеется, каждый применитель Bash'а знает, как с этим бороться — достаточно присобачить к конструкции поиска посредством той или другой утилиты маленький аппендикс в виде 2> /dev/null, отправляющий в небытие все сообщения об ошибках.
Сложнее применителям Tcsh — там подавления вывода нежелательных сообщений об ошибках возможно в виде такой конструкции:
где command — команда со всеми её опциями и аргументами, out — условное имя файла, в который перенаправляется «полезный» вывод команды, а & в данном контексте представляет весь остаток от оного, то есть сообщения об ошибках, которые помещаются в файл err. Имя последнего также условно, так что никто не запрещает подменить его сакраментальным /dev/null.
Конструкция далеко не столь проста, как в sh-совместимых оболочках типа Bash. Кроме того, для просмотра «полезного» вывода она потребует ещё одной команды — вызова какого-либо пейджера вроде less:
% (command > out)>& err ; less out
А вот применителям Zsh — проще всех. Им достаточно задать такой глобальный псевдоним:
$ alias -g N='2>/dev/null'
где -g указывает, что следующий символ (или символы) являют собой на простой псевдоним, а глобальный, N — его имя, а следующая после равенства последовательность в строгих кавычках — подменяемое им выражение. После чего можно практиковать такое:
$ find path3 -name [filename] N
И больше не заботиться о фильтрации зёрен от плевел.
Глобальные псевдонимы очень полезны в командных конструкциях перенаправления по конвейеру, например, для поэкранного вывода:
Пример для «пролистывания» вывода команды dmesg:
Для фильтрации по вхождению «слова» можно задать такой глобальный псевдоним:
После чего использовать его в конструкциях, подобных такой:
что выведет нечто вроде
[ 1.434246] md: raid0 personality registered for level 0
[ 1.434376] md/raid0:md0: md_size is 390742016 sectors.
...
Мне весьма полезен глобальный псевдоним вида
Поскольку часто требуется прибегать к такой конструкции
которая в данном случае выведет число символов в текстовом файле — для меня оно важнее числа байт (а при использовании 16-битной кодировки для преимущественно кириллического текста эти значения не совпадают).
К именам глобальных псевдонимов применяются те же требования, что и к именам псевдонимов обычных: они должны быть по возможности короткими, мнемонически прозрачными. И, разумеется, определения всех постоянно используемых глобальных псевдонимов следует занести в свой кондуитик — то есть в ~/.zshrc.
Разумеется, здесь не описаны все возможные случаи употребления глобальных псевдонимов — они лимитируются только потребностями применителя и его фантазией. И, конечно, наказом, который дал атаман Платов небезызвестному Левше:
Не пей мало, не пей много, а пей средственно.
То есть — не придумывайте глобальных псевдонимов больше, чем сможете запомнить.
Псевдонимы-суффиксы
Кроме обычных и глобальных псевдонимов, в Zsh существует ещё одна их разновидность — псевдонимы «суффиксные», более удачного определения на языке родных осин я не придумал, псевдонимы.
Подобно тому, как добаление к команде alias опции -g с помощью магии превращает обычный псевдоним в глобальный, так и опция -s делает обычный псевдоним «суффиксным». То есть привязывает суффикс имени файла (те, кто, подобно автору этих строк, затронуты порчей чёрным DOS'ом, до сих пор часто называют его «расширением») к некоей программе, которая может сотворить над ним нужное действо. Например, если задать псевдоним такого вида
а затем набрать в CLI такое
то этот самый некто.html будет открыт в текстовом браузере Links.
Чем, разумеется, возможности «суффиксных» псевдонимов не исчерпываются — как всегда, предел им ставит только фантазия применителя применительно к его задачам. Ограничусь одним примером.
Какой же русский не любит Командера-полуночника? В том числе и потому, что он — один из сыновей прославленного командера Нортона, имя которого, в свою очередь, не более чем alias незабвенного лейтенанта Шмидта (история его чудесного спасения из лап царской охранки и последующей блестящей карьере сначала в ВМС Пендостана, а затем в интернациональном софтверном бузиненсе реконструирована нашими замечательными историками из славного Екатеринбурга). Впрочем, со временем наш русский применитель, не смотря на весь свой патриотизм, начинает понимать, что слепая любовь к MC связывает ему руки в операциях с возлюбленной CLI, и хорошо бы с командиром расстаться, как это делают цивилизованные люди — без скандалов и истерик.
Но тут возникает проблема: MC — один из самых удобных способов просмотра того, из чего состоят файлы пакетов (будь то deb, rpm или что ещё из tar.*z-серии). Так вот, механизм «суффиксных» псевдонимов Zsh предлагает нам адекватную замену: если дать команду, например,
а затем набрать в командной строке такое:
$ path3/opera-beta_25.0.1614.11_amd64.deb
то мы сразу увидим, что же припасли для нас разработчики этого многими любимого браузера в своём полуподпольном пре-релизе за нумером 25 (впрочем, за время сочинения этой книги он стал вполне официальным, приобретя номер версии 27):
drwxr-xr-x root/root 0 2014-09-13 03:54 ./
drwxr-xr-x root/root 0 2014-09-13 03:54 ./usr/
drwxr-xr-x root/root 0 2014-09-13 03:54 ./usr/bin/
drwxr-xr-x root/root 0 2014-09-13 03:54 ./usr/lib/
drwxr-xr-x root/root 0 2014-09-13 03:54 ./usr/lib/x86_64-linux-gnu/
...
Понятное дело, что аналогичные псевдонимы можно придумать и для всяких rpm-и tgz-пакетов. И, разумеется, наиболее востребованные из них занести в кондуит... то есть в ~/.zshrc.
Конфигурирование
В качестве обобщения всего сказанного выше в заключение этого очерка я размещаю свой конфигурационный файл ~/.zshrc, прокомментированный, по мере сил, подробно. Этот конфиг существует с 2001 года, кочуя с машина на машину, из системы в систему, постоянно модернизируюсь в соответствие с изменениями моих потребностей и возможностей Zsh. И в текущем состоянии он обеспечивает все функции и особенности, о которых я говорил ранее, и некоторые другие, которые станут понятными после знакомства с Mint-утилитой пакетного менеджмента apt.
Данный конфиг может быть использован полностью или фрагментарно всеми заинтересованными лицами: блоки, заключённые в теги, пригодны для прямого копирования, за одним исключением, о котором будет сказано в своё время. Однако я отнюдь не призываю к этому, напротив: настоятельно рекомендую, используя данный конфиг и аналогичные, которые можно найти в Сети, по мере сил и возможности создавать конфиг собственный. Ибо хороший (для конкретного применителя) ~/.zshrc — это не результат, а процесс, и причём процесс преувлекательный.
Как и большинство уважающих себя конфигов, мой начинается с секции, закрытой комментариями, в которой сообщается, что:
- это
~/.zshrc — то есть «домашний» конфигурационный файл для командной оболочки Zsh;
- используется только в интерактивных её экземплярах;
- содержит команды для определения псевдонимов, функций, опций и прочих кейбиндингов;
- укладывается в последовательность считывания конфигов таким образом:
zshenv, zprofile, zshrc, zlogin.
Всё это потибрено унаследовано от прототипа, распространяющегося разрабочиками Zsh. От себя я добавил лишь такую строку:
#
# Alv's edition for Mint
#
Это не значит, что данный конфиг нельзя использовать вне Mint: подавляющая часть его строк будет иметь силу в любых дистрибутивах Linux'а или в BSD-системах. Но отдельные его блоки (специально оговоренные) в них просто не будут иметь смысла.
Далее начинается собственно строки определения конфигурируемых параметров. Для удобства восприятия (по крайней мере, моего собственного) они разделены на блоки «целевого назначения». Последовательность блоков, как и строк внутри них, в большинстве случаев рояля не играет, отдельные исключения также оговорены специально.
Поскольку всё имеет своё начало, начать свой конфиг мне показалось логичным с блока строк, имеющих отношение к истории команд. Перво-наперво — определение числа команд, сохраняемых в буфере во время данного сеанса, имени файла истории, и числа сохраняемых в нём команд:
HISTSIZE=2000
HISTFILE=~/.zhistfile
SAVEHIST=10000
Обычно для HISTSIZE и SAVEHIST рекомендуют принимать одинаковые значения (по умолчанию при автоматическом конфигурировании они равны 1000). Однако если действительно трудно представить ввод более чем тысячи команд в течении сеанса, то вот за весь цикл жизнедеятельности оболочки в системе превысить этот лимит достаточно просто.
Кроме того, надо учесть, что в обоих случаях сохраняются не просто команды, а целые директивы с опциями и аргументами, перенаправлениями и конвейерами, подчас достаточно сложными и редко используемыми. В Zsh имеются очень эффективные механизмы извлечения командных строк из сохранённой истории — не только по именам команд, но и по их опциям и аргументам. Обычно этим мало кто заморчивается, однако в некоторых, пусть и не частых, случаях такие командные конструкции могут потребоваться вторично. И тогда приятно сознавать, что они храняться в файле истории, откуда вытащить их всё равно проще, чем пытаться воспроизвести по памяти или отыскивать аналоги в сети.
Так что со временем я, увеличив на всякий пожарный случай HISTSIZE вдвое, отвёл под SAVEHIST 10000 строк. Кстати, когда предупреждают о том, что увеличение обоих значений может привести к торможению, следует учитывать, что в памяти постоянно находится только содержимое HISTSIZE, тогда как из SAVEHIST оно извлекается по мере необходимости. Не говоря уже о том, что при типичных для современных машин объёмах памяти об этом просто смешно говорить.
Имя файла истории я тоже изменяю на ~/.zhistfile. Во-первых потому, что иногда по старой памяти балуюсь Tsch, а в ней файл истории по умолчанию также именуется ~/.histfile (собственно, оттуда он в Zsh и был потибрен, в хорошем смысле этого слова). А во-вторых, просто для удобства восприятия — чтобы все имеющие отношение к Zsh файлы в домашнем каталоге были рядом.
Однако продолжим наши «исторические» опции. Следующие строки задают условия сохранения команд в файле истории:
setopt INC_APPEND_HISTORY
setopt HIST_IGNORE_ALL_DUPS
setopt HIST_REDUCE_BLANKS
setopt HIST_IGNORE_SPACE
Они определяют, соответственно:
- инкрементное наращивание файла истории — без указания этой опции (или одной из однотипных) его прежние команды будут заменены командами текущего сеанса;
- удаление предыдущих полных дубликатов нововведённых командных конструкций;
- избавление от пустых строк, возникающих после ошибочного нажатия Enter в «голом» приглашении;
- удаление лишних пробелов из командной конструкции.
Зачем нужны пункты 2–4 — ясно без комментариев. А вот о пункте 1-м надо сказать несколько слов. Ибо он не просто обеспечивает наращивание файла истории (для этого было бы достаточно опции, APPEND_HISTORY), но делает это в ходе сеанса, не дожидаясь его завершения. В результате команда, введённая в одном терминальном окне или вкладе терминала, будет доступна в истории команд другого терминала или вкладки (хотя и с некоторой задежкой).
Далее следуют две очень важные строки, определяющие одну из полезнейших возможностей Zsh — тот самый механизм history-substring-search, о котором говорилось ранее:
bindkey "^[[A" up-line-or-search
bindkey "^[[B" down-line-or-search
Следующие две строки касаются уже простого пролистывания истории в командной строке, позволяя делать это клавишами PageUp и PageDown (а не только стрелками Up и Down, которые в этом качестве работают всегда и везде):
bindkey "^[[5~" up-line-or-history
bindkey "^[[6~" down-line-or-history
Этими строками перебрасывается логический мостик к определению кейбиндингов для клавиш, которые в Zsh по умолчанию работают «неправильно» в большинстве терминалов (если не во всех). У меня это Home, End, Delete — их поведение исправляется такими, соответственно, строками:
bindkey "^[OH" beginning-of-line
bindkey "^[OF" end-of-line
bindkey "^[[3~" delete-char
Это как раз пример тех строк, которые as is копировать не нужно. Во-первых, в общем случае, могут не работать другие клавиши (скорее, не только эти). Во-вторых же и главных, в более иных терминалах коды тех же клавиш могут быть совсем другими. Какими — легко определить, нажав Control+V, а затем «неправильную» клавишу. Именно таким образом получены коды для Home, End и Delete в системе, в которой сочиняются эти строки.
Теперь — опции, определяющие магию Zsh при навигации по файловой системе:
cdpath=(/home/current /home/current/alv.me /etc)
setopt autocd
Первая строка позволяет с помощью команды cd переходить в подкаталоги перечисленных каталогов, не набирая никаких путей, ни относительных, ни абсолютных, вторая же — обходиться без команды cd.
На грани между опциями навигации и автодополнения находятся такие строки:
setopt menucomplete
zstyle ':completion:*' menu select=1 _complete _ignored _approximate
Они в паре обеспечивают «менюобразный» вывод списка доступных дополнений по нажатию клавиши табуляции. И это как раз тот случай, когда последовательность строк имеет значение.
Аналогично и со следующими строками — теми самыми, которые обеспечивают волшебство развёртывания сокращённого ввода пути в полный:
autoload -Uz compinit
compinit
Расширенные подстановки и дополнения обеспечиваются вот этими строками:
setopt extendedglob nomatch notify
zstyle ':completion:*' completer _expand _complete _ignored _correct _approximate
Строка
zstyle ':completion:*' use-compctl false
знаменует собой отречение от старого мира — системы дополнения compctl, в пользу новой системы compsys.
Строка
zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
устанавливает равноправие при дополнениях символов нижнего регистра с верхним.
А строка
zstyle :compinstall filename '/home/zsh/.zshrc'
фиксирует файл, в который compinstall (функция автоматического конфигурирования compsys) будет вносить свои изменения при грядущих её вызовах (если они, конечно, будут).
Пора переходить к псевдонимам. Сначала — серия таковых для команд манипуляции файлами, предписывающие запрос подтверждения на таковые или, напротив, форсированное исполнение, в зависимости от ситуации:
alias mv='mv -i'
alias cp='cp -iR'
alias cpr='cp -fR'
alias rm='rm -i'
alias rmf='rm -f'
alias rmrf='rm -fR'
Оказывается, что для одной-единственной команды ls можно придумать больше псевдонимов, чем для всех файломанипулирующих команд, вместе взятых:
alias ls='ls -F'
alias ll='ls -lh'
alias la='ls -A'
alias li='ls -ial'
alias lsd='ls -ld *(-/DN)'
alias lsa='ls -ld .*'
На самом деле их можно придумывать ещё и ещё — этот тот необходимый минимум, который я в состоянии запомнить без вреда для рассудка. Расшифровывать псевдонимы не буду — кому надо, и так могут сорвать с них маски, а кто не знает — так ему это и не нужно.
Далее идёт серия псевдонимов для различных команд и утилит разного назначения. Здесь также расшифровка будет лишней. Ибо они или оболее-менее общеприняты:
alias h=history
alias df='df -h'
alias du='du -h'
Либо обусловлены давними привычками (как, например, more-образный вывод команды less):
alias less='less -M'
alias wget='wget -c'
alias nano='nano -$'
Либо связаны со спецификой деятельности:
alias wcl='wc -l'
alias wcw='wc -w'
alias wcm='wc -m'
alias wcc='wc -c'
Так что можно переходить к следующей убойной фиче Zsh — определению глобальных псевдонимов:
alias -g N='2>/dev/null'
alias -g L='|less'
alias -g G='|grep'
alias -g W='|wc -m'
Где, впрочем, комментарии тоже излишни.
А посему перехожу к тем самым дистрибутив-специфическим блокам, которые я предназначил для применения в Mint. Это — псевдонимы для субкоманд её утилиты apt, призванные минимизировать ввод при наиболее частых действиях по пакетному менеджменту:
alias aptin='apt install --yes'
alias apter='apt purge'
alias aptup='apt update'
alias aptug='apt upgrade'
alias aptse='apt search'
alias aptsh='apt show'
Псевдонимы для внутренних команд apt из APT также имеет смысл определить, по крайней мере один, для получения списка инсталлированных пакетов:
alias aptlist='/usr/bin/apt list --installed'
Смысл этих псевдонимов будет ясен после знакомства с очерком об утилите apt. И в них нет ничего Zsh-специфичного. В отличие от альтернативного метода, основанного на псевдонимах глобальных, которые определяются для соответствующих аргументов команды sudo. Правда, особенность реализации утилиты apt в Mint такова, что она не требует ввода этой команды в явном виде. И потому здесь у меня осталась единственная строка для псевдонима команды добавления репозиториев:
alias -g Ar='add-apt-repository'
Хотя я и утверждал не так давно, что приглашение оболочки — нечто вроде вешалки для театра, сам добрался до этой темы только к концу своего конфига. Однако вот — обычное левосторонне приглашение:
Вторичное приглашение:
Правостороннее приглашение:
А вот это — альтернативы, которыми я баловался во время сочинения раздела про приглашения. Все они начинаются с такой пары строк:
autoload -Uz promptinit
promptinit
После которых вызывается уже одна из конкретных тем:
#prompt fade
prompt fade white grey blue
#prompt clint
Естественно, что остальные строки должны быть закомментированы.
Осталось немного — всякая всячина. Например, предотвращение выхода из оболочки после случайного нажатия Control+D в пустой командной строке:
Отключение раздражающего звукового сигнала при ошибках набора:
Фиксация emacs-образного поведения клавиш (хотя это и так имеет место быть по умолчанию):
И под занавес — определение пары переменных среды, для начала умолчального пейджера. Хотя я не так давно говорил, что расширенное перенаправление делает его практически не нужным, но, кроме всего прочего, это ещё и средство для просмотра man-страниц:
И умолчальный редактор: не смотря на свою любовь к Joe, навыки работы с ним я утратил напрочь, поэтому так:
Вот вроде и всё. Остаётся последний дистрибутив-специфичный стришок — исправление нехорошего поведения history-substring-search в Mint, унаследованного от Ubuntu. А точнее, поведения никакого — эта фича без дополнительных мер просто не работает. Благо меры эти очень просты — создание файла ~/.zshenv с единственной строкой:
DEBIAN_PREVENT_KEYBOARD_CHANGES=yes
Вот теперь действительно всё — с конфигурированием Zsh «мануальным» способом покончено.