Linux Mint и его Cinnamon. Очерки применителя
Шрифт:
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) употребляется в двух смыслах: как авторский набор исходных текстов, созданный разработчиком программы,
Бинарные пакеты специфичны для семейств некогда родственных дистрибутивов, почему часто говорят о системах 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) характеризуется ярко выраженным стремлением не множить сущности без крайней необходимости. Или, говоря попросту, не изобретать велосипеды. То есть: если требуемая разработчику данной программы функция уже реализована и включена в какую-либо распространённую библиотеку, то наш разработчик скорее всего этой библиотекой и воспользуется, а не будет переписывать ее с нуля. Благо, поскольку все распространённые и общеупотребимые библиотеки открыты, он имеет полную возможность это сделать.