Читать онлайн «Linux Mint и его Cinnamon. Очерки применителя». Страница 49

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'

Хотя я и утверждал не так давно, что приглашение оболочки — нечто вроде вешалки для театра, сам добрался до этой темы только к концу своего конфига. Однако вот — обычное левосторонне приглашение:

#PROMPT='%B[%n]$=>%b '

Вторичное приглашение:

#PROMPT2='%i%U> '

Правостороннее приглашение:

#RPROMPT=' %B[%~]%b '

А вот это — альтернативы, которыми я баловался во время сочинения раздела про приглашения. Все они начинаются с такой пары строк:

autoload -Uz promptinit

promptinit

После которых вызывается уже одна из конкретных тем:

#prompt fade

prompt fade white grey blue

#prompt clint

Естественно, что остальные строки должны быть закомментированы.

Осталось немного — всякая всячина. Например, предотвращение выхода из оболочки после случайного нажатия Control+D в пустой командной строке:

setopt IGNORE_EOF

Отключение раздражающего звукового сигнала при ошибках набора:

setopt NO_BEEP

Фиксация emacs-образного поведения клавиш (хотя это и так имеет место быть по умолчанию):

bindkey -e

И под занавес — определение пары переменных среды, для начала умолчального пейджера. Хотя я не так давно говорил, что расширенное перенаправление делает его практически не нужным, но, кроме всего прочего, это ещё и средство для просмотра man-страниц:

export PAGER="less"

И умолчальный редактор: не смотря на свою любовь к Joe, навыки работы с ним я утратил напрочь, поэтому так:

export EDITOR="nano"

Вот вроде и всё. Остаётся последний дистрибутив-специфичный стришок — исправление нехорошего поведения history-substring-search в Mint, унаследованного от Ubuntu. А точнее, поведения никакого — эта фича без дополнительных мер просто не работает. Благо меры эти очень просты — создание файла ~/.zshenv с единственной строкой:

DEBIAN_PREVENT_KEYBOARD_CHANGES=yes

Вот теперь действительно всё — с конфигурированием Zsh «мануальным» способом покончено.

Все дистрибутивы Linux, и Mint тут не исключение, организованы по пакетному принципу. Точно также, в виде пакетов, распространяются и любые дополнительные программы для них, создаваемые независимыми разработчиками. И потому одна из важных задач пользователя — это интеграция пакетов в свою систему. Она решается средствам управления пакетами, предназначенным для установки, обновления и удаления программ, учета и разрешения их зависимостей. Однако, прежде чем говорить о таких средствах, не худо посмотреть, что такое пакеты вообще, deb-пакеты в частности и пакеты дистрибутива Mint в особенности. А также — каким образом они организованы в репозитории.

Пакеты — это своего рода программные кванты, на которые делится система или дистрибутив. Это могут быть и простые монофункциональные утилиты (например, строчный текстовый редактор ed или архиватор tar), более или менее обширные наборы функционально связанных программ (скажем, coreutils) или составные части огромных программных комплексов (примером чему — Cinnamon, о котором столько гворилось в прошлых очерках).

Термин пакет (английское package) употребляется в двух смыслах: как авторский набор исходных текстов, созданный разработчиком программы, и как комплект скомпилированных из него исполняемых программ и всех их служебных файлов, собранный майнтайнерами дистрибутива или вообще третьими лицами. Пакеты в первом смысле называются исходниками или вообще «сырцами» (от английского Source), во втором — бинарниками. Далее в этой книге речь пойдёт почти исключительно о пакетах во втором понимании этого термина.

Бинарные пакеты специфичны для семейств некогда родственных дистрибутивов, почему часто говорят о системах rpm based или deb based. Но даже если они собраны в одном формате (например, rpm или deb), бинарные пакеты из разных дистрибутивов далеко не всегда совместимы в рамках одной системы. Впрочем, к формату deb, принятому в дистрибутиве Mint и потому в интересующему нас больше всех остальных, вместе взятых, это относится в наименьшей степени: его пакеты сохраняют почти полную бинарную совместимость с пакетами родительской Ubuntu и частичную — с пакетами прародительского Debian'а.

Ключевым для бинарных, или дистрибутивных, пакетов является понятие зависимостей. Суть его в том, что пакет packagename1 для сборки, установки и (или) функционирования требует наличия в системе пакета packagename2, тот, в свою очередь, может потребовать пакета packagename3, и так далее.

Следует различать зависимости жёсткие и «мягкие». Удовлетворение первых абсолютно необходимо для сборки и функционирования данного пакета. Так, практически любая программа использует главную системную библиотеку glibc (или libc), любое приложение для системы X — одну из главных Иксовых библиотек: старые — xlib, новые — xcb, любая интегрированная рабочая среда — одно из двух основных семейств высокоуровневых библиотек, Qt/kdelibs или Gtk.

«Мягкие» зависимости данного пакета не критичны для его функционирования — удовлетворение их лишь добавляет ему дополнительные функции (например, печати и сканирования для офисных и графических приложений) или возможности (скажем, доступ к файлам данных определённых форматов для той же графики или мультимедиа).

В deb-формате бинарных пакетов предусмотрено более дробное разделение «мягких» зависимостей, но об этом подробнее будет говориться чуть позже. А пока замечу, что часто приходится учитывать и так называемые конфликтующие зависимости — то есть альтернативные по назначению пакеты, не способные ужиться в одной системе.

Понятие зависимостей пронизывает насквозь UNIX-совместимые системы, и особенно важно для свободных их представителей. В то же время пользователи Windows с ним сталкиваются очень редко, и потому постижение его вызывает у них определённые трудности.

Традиционная модель разработки UNIX-программ (то, что задумчиво именуют UNIX Way) характеризуется ярко выраженным стремлением не множить сущности без крайней необходимости. Или, говоря попросту, не изобретать велосипеды. То есть: если требуемая разработчику данной программы функция уже реализована и включена в какую-либо распространённую библиотеку, то наш разработчик скорее всего этой библиотекой и воспользуется, а не будет переписывать ее с нуля. Благо, поскольку все распространённые и общеупотребимые библиотеки открыты, он имеет полную возможность это сделать.