Skip to content

Linux Mint и его Cinnamon. Очерки применителя

Linux Mint и его Cinnamon. Очерки применителя published on 18 комментариев к записи Linux Mint и его Cinnamon. Очерки применителя

Алексей Alv Федорчук

Версия для ознакомления. Версии для чтения в оффлайне можно скачать в Библиотеке Блогосайта.

Аннотация

Эта книга посвящена дистрибутиву Linux Mint и одной из его главных рабочих сред рабочих сред — десктопу Cinnamon. В ней рассмотрены их особенности, средства настройки дистрибутива и среды, системы управления пакетами, некоторые прикладные программы. Затронут также ряд более специальных вопросов, имеющих отношение не только к Linux Mint, такие, как командная оболочка Zsh, использование программных RAID, технологии LVM и системы размещёния данных ZFS. Заключительным аккордом в ней прозвучит рассказ о создании собственных индивидуализированных сборок на базе Linux Mint и Cinnamon.

Книга не является систематическим руководством по данному дистрибутиву и, тем более, по Linux вообще. Она ориентирована исключительно на любопытствующих применителей любого уровня подготовки, имеющих склонность к экспериментам, с одной стороны, и к изящной словесности — с другой.

Содержание

Об этой книге

В основу этой книги легли заметки, посвящённые дистрибутиву Linux Mint и десктопу Cinnamon, которые на протяжении последнего года размещались на нашем Блогосайте. В ней использованы также фрагменты цикла статей на ту же тему, публиковавшиеся на сайте IBM developerWorks (правда, цикл этот по не зависящим от меня обстоятельствам не был закончен). При подготовке книги эти статьи и заметки были систематизированы, структурированы, отредактированы и актуализированы в соответствии с текущими реалиями, а также дополнены новыми материалами.

Автор не ставил себе целью написать последовательное и законченное руководство по Linux Mint и Cinnamon. Это — именно очерки, посвящённые тем аспектам устройства и применения данного тандема, которые а) не очень подробно освещёны в имеющихся источниках и б) интересны лично автору. И вследствие последнего обстоятельства носят вполне субъективный характер.

Дистрибутив Mint, по моему мнению, пригоден для применителей любого уровня начальной подготовки. Соответственно и книга о нём не предполагает у читателя наличия каких-то особенных познаний, кроме самого обычного любопытства. А также понимания того, что это — именно очерки, а не сборник документации.

При этом читатель книги не обязан быть применителем именно Linux Mint. Дистрибутив этот является дериватом Ubuntu и сохраняет с ней практически полную бинарную совместимость. Так что ряд описанных в книге вещёй (например, про управление пакетами) — общие для всего семейства Ubuntu’идов, а отчасти и для всех deb based дистрибутивов, включая даже прародительский Debian. Кое-что же, скажем, включение поддержки LVM, softRAID, ZFS, имеет силу для всех дистрибутивов Linux вообще.

Ну а сведения, содержащиеся в очерках про Cinnamon, приложимы к любому дистрибутиве, в котором этот десктоп может быть установлен, и в котором обеспечивается его корректная работа — список их постоянно расширяется, и нынче включает в себя и не только Linux-, но и BSD-системы.

Во время работы над книгой затронутые в ней вопросы обсуждались с моими товарищами и коллегами: Владимиром Поповым, Сергеем Голубевым, Владимиром Родионовым, Станиславом Шрамко, а также многочисленными участниками социальной сети Juick, форумов Linux Mint Росинка и Matuntu, для поимённого перечисления которых не хватит никаких ресурсов. Всем именованным и подразумеваемых лицам автор выражает свою признательность.

Отдельная благодарность — поэту-линуксоиду Ирине Киттель aka Алиса Деева, вдохновлявшей меня на трудовые свершения своими стихами, и моим детям — Ольге и Виктору, ставшими применителями Linux’а по собственной инициативе.

Наконец, автор искренне признателен команде разработчиков дистрибутива Mint и интегрированной среды Cinnamon, и лично Клементу Лефевру aka Clem за создание прекрасного дистрибутива и его рабочего окружения.

Примечание: книга в основных форматах для чтения в оффлайне доступна в Библиотеке Блогосайта. Для неё, как и всех остальных книг Библиотеки, разрешается свободное использование и некоммерческое распространение в электронной форме при условии указания авторства и активной индексируемой ссылки на первоисточник. Все книги Библиотеки доступны бесплатно, хотя автор не отказывается от аморального (то есть финансового) содействия своим проектам, оказать которое можно, заглянув на эту страницу.

Введение в Linux Mint

Разговор о Mint и его Cinnamon логично начать с рассказа о том, что же такое, товарищи, Mint, и что такое, братья, Cinnamon. Начну с этого и я.

Лирическое вступление

Ведь в науке, в основном, происходят вещи посредственные — и я приучил себя к посредственному.
Владимир Савченко, Открытие себя

В долгой истории дистрибутивов Linux до сего дня было два знаковых события (если не считать самого факта начала Linux-дистрибуции). Был период «бури и натиска» — рубеж тысячелетий, когда, вслед за первой версией Mandrake (имевшей, как ни странно, номер 5.1), поднялась волна так называемых «дистрибутивов, дружественных к пользователю» (они же — «с человеческим лицом»). И был «год великого перелома» — 2005, когда Ubuntu 5.10 Breezy Badger, став пригодной для применения, в одночасье обрела невероятную популярность среди применителей всех стран и народов, заставив разработчиков всех остальных популярных дистрибутивов пересмотреть свою политику в отношении этих самых применителей.

С тех пор в мире Linux-дистрибуции происходили события более или менее заурядные. Новостные ленты заполнились сообщениями: вышел релиз W.W дистрибутива Имя рек с ядром X.XX, KDE Y.Y.Y и GNOME Z.Z.Z, со списком прочих изменений — длинным, но мало чего дающим применителю. Конечно, каждый такой релиз содержал усовершенствования. Хотя в последние годы первое действие при знакомстве со многими из них было: посмотреть — а чего они на этот раз поломали?

Началось привыкание к заурядности происходящих событий. Настолько сильное, что, когда в последний день весны 2014 года, произошло событие действительно незаурядное — оно имело все шансы остаться практически незамеченным. А, между тем, по своей значимости оно вполне сопоставимо с выходом Mandrake 5.1 и Ubuntu 5.10. Это событие — релиз Mint 17 Qiana в сборке с рабочей средой Cinnamon 2.2. О которых и пойдёт речь в дальнейшем — но уже в актуализованном тандеме, появившемся в ноябре 2014 года и включающем Mint 17.1 Rebecca и Cinnamon 2.4.

Что такое Mint

Полное имя первого из героев этого цикла — Linux Mint. Однако, поскольку ясно, о дистрибутиве какой операционной системы идёт речь, первый компонент я в дальнейшем буду опускать.

Дистрибутив Mint, начиная с 2011 года, стабильно занимает первое место в рейтинге Distrowatch. Конечно, это не значит, что он является самым распространённым или самым популярным — рейтинг этот, как и все подобные измерители… животов, вещь достаточно условная. Но безусловно свидетельствует о широкой известности дистрибутива в узких кругах применителей Linux. Так что я могу ограничиться очень краткой его характеристикой.

Дистрибутив Mint был создан в 2006 году Клементом Лефевром (Clement Lefebvre), который поставил своей целью создание идеального десктопа «для народа» — домашних пользователей и малого бизнеса. Он представлял собой дериват Ubuntu — термины клон или форк в данном случае не применимы. То есть Mint в базовой своей части, вплоть до Xorg, основан на кодовой базе Ubuntu, и все соответствующие пакеты берутся из её репозиториев без всяких изменений. Однако он имеет и собственный небольшой репозиторий (около 500 пакетов), содержащий дистрибутив-специфические компоненты.

clemet-lefebvre

Клемент Лефевр

В сентябре 2010 года было объявлено о выходе другого дистрибутива проекта Mint — Linux Mint Debian Edition (LMDE). Как можно догадаться из его имени, он был основан на кодовой базе не Ubuntu, а Debian. В качестве таковой выступала его ветка testing, и потому релиз-цикла у LMDE нет — его «плавающие» версии маркировались годом и месяцем. Впрочем, в этом цикле речи о них не будет — этот дистрибутив заслуживает отдельного рассказа, время для которого ещё не наступило.

Немного истории

Завязка сюжета относится к 2011 году. До этого момента в качестве рабочего окружения в Mint использовался GNOME текущей версии — той же, что в базовой Ubuntu. Правда, GNOME был в нём главным, но не единственным десктопом. Чуть ли не со дня основания Mint существовала и его сборка с KDE, позднее к ней присоединились варианты с рабочими средами Xfce (2007 год) и LXDE (2010 год), на протяжении 2008-2010 годов существовал даже вариант с оконным менеджером Fluxbox. Однако они имели не вполне официальный статус, и появлялись, как правило, несколько позже сборок «генеральной линии». И иногда пропадали с горизонта вообще, как случилось с редакциями LXDE и Fluxbox.

Но весной 2011 года, с одной стороны, Ubuntu переходит на среду Unity, с другой — появляется релиз GNOME 3 с оболочкой GNOME Shell, поддержка же GNOME 2 разработчиками этого десктопа официально прекращается.

Оба новых десктопа, по ряду причин, оказались для разработчиков Mint неприемлемыми. И потому они, с одной стороны, включили в свой дистрибутив десктоп MATE, а с другой — занялись разработкой новой оболочки для GNOME 3, которая в декабре 2011 года была анонсирована под именем Cinnamon. И это — второй герой настоящего цикла.

Возвращаясь к современности

Однако надо возвратиться к первому герою и обрисовать современное положение дел. Вышедший 31 мая релиз 17 Qiana был представлен, как уже говорилось, основными десктопными редакциями с Cinnamon и MATE в качестве рабочих сред, в сборках для 32- 64-разрядных архитектур.

Постепенно к ним присоединялись другие варианты дистрибутива. Так, обе базовые редакции получили так называемые образы nocodecs и oem. Как нетрудно догадаться, первые предназначены для стран, признающих патенты на алгоритмы, вторые — для предустановки на новые компьютеры. А затем к базовым редакциям присоединились редакции с рабочими средами KDE и Xfce.

С появлением в ноябре 2014 года релиза 17.1 Rebecca перечисленные образы сменились одноимёнными редакциями с актуальными на данный момент рабочими средами Cinnamon и MATE, к которым опять-таки чуть позже присоединились KDE- и Xfce-сборки. Выход же второй версии дистрибутива LMDE запланирован на март 2015 года.

Все перечисленные варианты представляют Live-образы, которые могут быть записаны либо на DVD-диски (объём их 1,3-1,4 ГБ), либо на твердотельные носители типа USB Flash или SD-карт. Во втором случае это можно сделать и специализированными утилитами типа UNetbootin, и прямой командой dd. Программа инсталляции запускается из Live-режима любого диска, альтернативных, то есть «чисто установочных», вариантов ни для одной редакции Mint не предусмотрено.

Скачать образы можно по ссылкам с официального сайта проекта, где приведён список многочисленных зеркал, физически находящихся в разных странах. В российских условиях целесообразно обратиться на зеркало Яндекса.

На этом мы временно попрощаемся с дистрибутивом Mint. Следующий очерк будет посвящён общему знакомству со второй героиней нашего повествования — одной из двух основных его рабочих сред, которая носит имя Cinnamon.

Введение в Cinnamon

Здесь будет рассказано о интегрированной рабочей среде Cinnamon — её истории, особенностях, распространении и поддержке в других дистрибутивах.

История

Cinnamon — самая молодая из «уже действующих» интегрированных рабочих сред (иначе — декстопов): проект был анонсирован 20 декабря 2011 года, а уже 23 декабря он стал доступен для скачивания, и сразу в виде релиза 1.1.2 — версии с меньшими номерами предназначались только для тестирования.

Далее развитие проекта происходило стремительно: 23 января следующего года появляется релиз 1.3, в середине марта — 1.4, а затем, в сентябре — релиз 1.6. После чего устанавливается полугодовой релиз-цикл — релиз 1.8 выходит в свет 5 мая 2013 года, после серии релизов корректирующих. В октябре того же года появляется релиз 2.0, в апреле 2014 года — релиз 2.2. И, наконец, герой нашего рассказа, релиз 2.4, увидел свет 1 ноября 2014 года.

Все релизы среды опережали версии Mint, для которых они предназначались, примерно на месяц — для дополнительного тестирования среды силами энтузиастов и притирки её к целевому дистрибутиву. Что, как показала практика, давало весьма положительный результат. О чём могу свидетельствовать по собственному опыту для версий Cinnamon 2.2 и 2.4: в релизы Mint 17 и 17.1, соответственно, они были включены в существенно доработанном виде по сравнению с первоначально представленными сборками.

Смена версий Cinnamon отражает специфичность его судьбы. Что же происходило при этом? В предыдущем очерке упоминалось, что история этого десктопа началась с появлением GNOME 3. Говорить о кипении страстей, связанных с этим событием, здесь не уместно. Достаточно сказать, что для многих применителей ряда дистрибутивов, включавших GNOME 2 в качестве штатного десктопа, его «осовремененная» версия, в частности, «очень прогрессивная» оболочка GNOME Shell, оказалась неприемлемой.

В частности, Mint был очень крепко связан с десктопом GNOME 2. Однако GNOME 3, особенно в своём первозданном виде, в концепцию его развития не вписывался, а основа его предшественника, библиотека Gtk 2, перестала поддерживаться разработчиками. Ситуация требовала кардинального решения.

Первое решение носило косметический характер. Это был набор MGSE (Mint GNOME Shell Extensions), объединяющий дополнения к GNOME Shell, которые могли обеспечить не только его традиционный интерфейс, но и восполнить недостающий функционал за счёт внешних модулей, таких, как панель Bottompanel, система переключения между окнами Windowlist и меню приложений Menu. Результатом стал выход в ноябре 2011 года релиза Mint 12 Lisa, включавшего в качестве десктопа по умолчанию GNOME 3 с MGSE.

Однако, видимо, майнтайнерам Mint изначально было ясно, что MGSE — не более, чем паллиатив, и потому, с одной стороны, включили в свой дистрибутив альтернативный десктоп — MATE (первыми среди майнтайнеров распространённых дистрибутивов). А с другой стороны, можно догадаться, что где-то за кадром Клемент Лефевр (Clement Lefebvre), основатель и основной майнтайнер дистрибутива, уже ковал основу совершенно новой оболочки для GNOME 3. Которая стала доступной буквально через месяц после выхода Mint 12 Lisa и получила имя Cinnamon.


Отступление. Словом cinnamon, восходящим к латыни, в английском языке называют, во-первых, коричное дерево, коричник цейлонский (Cinnamomum zeylanicum) — вечнозелёное растение семейства лавровых. Второе его значение — корица, название пряности, изготовляемой из коры этого дерева. Наконец, слово cinnamon применяется и для именования коричного масла, добываемого из листьев коричника, и используемого в медицине, парфюмерии и косметике.

Основу Cinnamon’а составил оконный менеджер Muffin — форк аналогичной программы Mutter из GNOME 3. Главное отличие новой оболочки от связки GNOME 3 и MGSE состояло в том, функционал внешних расширений последнего был включён непосредственно в её состав. Это предоставило средства управления взаимодействием между дополнительными функциями и определения порядка их загрузки. В результате были реализованы добавление пиктограмм в область уведомлений, система уведомлений в стиле GNOME 2, возможность изменения позиции панели и и её автоматического скрытия.

После серии основных и корректирующих релизов, стремительно следующих друг за другим, Cinnamon 1.4 UP1, появившийся 14 мая 2012 года, был включён в качестве штатного десктопа в Mint 13 Maya, анонсированный десять дней спустя. С тех пор выход его версий и стал привязан к релиз-циклу этого дистрибутива.

Всё это время Cinnamon представлял собой просто оболочку к GNOME 3, надстраивающую «форкнутый» менеджер окон и замещающую собой его штатный GNOME Shell. Он включал все базовые приложения GNOME 3 — терминал, файловый менеджер, текстовый редактор — в неизменном виде. Однако во время подготовки релиза GNOME 3.6, в котором предполагалось существенное ограничение функционала файлового менеджера Nautilus, разработчики Cinnamon начали работы над форком его версии 3.4, назвав её Nemo. Который и попал в релиз Mint 14 Nadia, хотя сначала в качестве альтернативного. Но уже в версии Cinnamon 1.8.X он был интегрирован с этой средой. Кроме того, в этой версии отказались от Центра управления GNOME 3.

Версии Cinnamon 1.8 суждено было стать последним «чистым» форком GNOME 3 — в это же время полным ходом шла подготовка релиза 2.0. Суть её заключалась в полной замене базовых компонентов GNOME 3 собственными аналогами. То есть — в создании полностью обособленного окружения, не пересекающегося с GNOME 3 и не связанного с ним внешними зависимостями. В результате чего Cinnamon из оболочки для GNOME, вроде GNOME Shell и Unity, превращался в полноценное рабочее окружение. Итог этой деятельности был вынесен на суд общественности 10 октября 2013 года, в виде релиза 2.0.

Особенности

Так каковы же особенности нового десктопа, приобретённые им в версии 2.0 и получившие дальнейшее развитие в версиях последующих? Важнейших — три.

Первая — в Cinnamon гармонично сочетаются старые добрые элементы управления, такие, как главное меню в стиле кнопки Пуск, и элементы модерна, столь привлекающие в Unity, такие, как строка поиска, подобная Dash — но без излишеств последнего, то есть без средств поиска в Интернете всякого рода «парнухи».

Вторая особенность — достигнутая в Cinnamon гармония между простотой конфигурирования и богатством возможностей последнего. Если настройки в KDE, при их изобилии, приобретают всё более необозримый вид, а в GNOME 3, напротив разубоживаются, в нашем десктопе они почти столь же просты, как в Xfce, и почти столь же изобильны, как в KDE. И, в отличие от Ubuntu, выполняются исключительно штатными средствами, а не бесчисленными твикерами с полуофициальным и вообще неофициальным статусом.

Третья особенность — аскетизм Cinnamon в отношении штатных приложений. В существующем виде к таковым можно отнести только файловый менеджер Nemo. Обычно богатство приложений считается достоинством интегрированных сред (на то они и зовутся интегрированными). И бедность Cinnamon в этом плане можно было бы отнести к числу её недостатков. Если бы не оборотная сторона медали — отсутствие приложений в штате среды позволяет легко и без избыточности подобрать оптимальный набор рабочих инструментов «для себя».

Наконец, весь традиционализм Cinnamon’а покоится на весьма современном базисе в виде библиотек Gtk+ 3, что должно обеспечить спокойное развитие этого десктопа в обозримом будущем. При этом сохраняется и совместимость с приложениями на основе Gtk+ 2, до сих пор широко распространёнными и не имеющими адекватных аналогов.

Распространение

Тем не менее, несмотря на многочисленные достоинства, десктоп Cinnamon долго не получал широкого распространения в дистрибутивах Linux. И после знакомства с его историей легко понять, почему. В сущности, модель разработки его оказалась противоположно направленной по сравнению со всеми остальными интегрированными средами. Если KDE, Xfce, GNOME, а позднее LXDE и Razot-qt создавались командами разработчиков, более или менее независимыми от майнтайнеров отдельных дистрибутивов, и лишь потом начинали использоваться последними в своих сборках, если MATE представлял собой попытку сохранить наработки GNOME 2, то Cinnamon с первых дней своего существования выглядел «привязанным» к прародительскому Mint. Почти так же, как это имеет место для Ubuntu и Unity — или, по крайней мере, как это воспринимается для последней пары так называемой общественностью.

На самом деле эта «привязка» была кажущейся, хотя команды разработчиков Mint и Cinnamon действительно были множествами сильно пересекающимися. И политика разработчиков этого десктопа не требует от сторонних разработчиков, скажем, передачи им имущественных прав на свою продукцию, как это практикует фирма Canonical при приёме патчей для Ubuntu и Unity. Однако можно предполагать, что майнтайнеры большинства дистрибутивов отнеслись к Cinnamon настороженно. Тем не менее, некоторые из них поддержали нашу героиню.

Поддержка

Если через поиск Distrowatch попытаться найти дистрибутивы, поддерживающие Cinnamon, получится список из 16, на момент сочинения этих строк, позиций. Он не вполне соответствует действительности — с одной стороны, на официальных сайтах некоторых проектов явных упоминаний о поддержке этого десктопа не обнаруживается, с другой — некоторые дистрибутивы, в которых он есть заведомо (например, openSUSE), в нём отсутствуют. Однако, с учётом этого и с исключением явной экзотики из Южной Африки, Андалузии или Непала, оказывается, что Cinnamon поддерживается в десятке распространённых дисрибутивов, среди которых:

  • Fedora и её клон — Korora;

  • Sabayon — дружественный к пользователю клон Gentoo;

  • Archlinux и его клон Manjaro;

  • openSUSE, где он присутствует в полуофициальном (Semi official) репозитории;

  • siduction — дистрибутив, основанный на unstable-ветке Debian;

  • PC-BSD, которая, конечно, не Linux, но Cinnamon поддерживает на стадии установки.

Я перечислил только те дистрибутивы, в которых поддержка Cinnamon может быть задействована на стадии их установки, и реализацию её проверял лично. Кроме того, Cinnamon нынче можно найти в портах FreeBSD и пакетах DragonFly, в тестовоой ветке Debian, а главное — в ppa-репозиториях Ubuntu. До недавнего времени в последних она поддерживалась Гвендалем Ле Бианном (Gwendal Le Bihan). И, хотя весной 2014 года он отказался от сборки стабильной ветки этой среды, ограничившись экспериментальными «ночными», эстафета была немедленно подхвачена другими майнтайнерами.

Как я уже сказал, большая часть перечисленных выше систем проверялась мной на предмет поддержки Cinnamon собственноручно. И этот личный опыт показывал, что до недавнего времени качество таковой у всех представителей списка (кроме Ubuntu) оставляло желать лучшего. Это касалось мелких, но часто существенных для применителях деталей, таких, как настройка раскладок клавиатуры и их переключателей.

Однако буквально в последние месяцы, после выхода Cinnamon 2.4, ситуация изменилась кардинальным образом. И теперь этот десктоп безукоризненно поддерживается в большинстве дистрибутивов первого эшелона — в Archlinux’е и Manjaro, в openSUSE и Fedora, по прежнему хорошо — в Ubuntu, с оговорками на счёт отставания версии — в Debian testing (опять же, говорю только о тех, в которых проверял сам).

Однако по прежнему наиболее эффективно Cinnamon поддерживается в Mint — за счёт интеграции его с дистрибутив-специфическим системным инструментарием последнего. Подобно тому, как испокон веков KDE было лучше всего интегрировано с openSUSE, GNOME органично срастался с Fedora, а Xfce был «роднее» лёгким клонам Slackware (таким, как Zenwalk и Salix). Так что самый простой способ ознакомиться со средой Cinnamon во всёй её красе — установка соответствующей редакции Mint 17.1 Rebecca, о чём и пойдёт речь в следующем очерке.

Linux Mint: установка

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

Именно так случилось некогда с инсталлятором Ubuntu — десять лет назад его установка в пять кликов сыграла не последнюю роль и в распространении этого дистрибутива по пользовательским десктопам, и в образовании многочисленных прямых, косвенных и откровенно примазавшихся родственников, вплоть до «дистрибутивов с нескучными обоями».

В числе родственников… нет, не примазавшихся, а настоящих, но пошедших другим путём, был и дистрибутив Mint. Сейчас не время обсуждать его взаимоотношения с прародительской Ububtu, но программу установки он унаследовал от неё практически без изменений. По крайней мере, до недавнего времени макроскопических различий в инсталляторах этих систем не наблюдалось.

Честно говоря, их не наблюдается и сейчас, с выходом версии Mint 17, а затем и Mint 17.1 — формально отличий в установке с Ubuntu 14.04 нет. Так что о чём тут говорить, спросите вы меня? Отвечу: говорить действительно не о чем — это нужно видеть. Точнее, делать своими руками — и наблюдать за результатом. Ибо даже скриншоты, которыми я на этой странице практически и ограничусь, не в силах передать того ощущения лёгкости и плавности, которое испытывает истинный применитель при установке этого дистрибутива.

Итак, установка Mint’а запускается из Live-режима его работы, являющегося следствием загрузки с соответствующего носителя — DVD или, что предпочтительно, флешки (или SD-карты). Кстати, не обязательно слушать того, кто будет убеждать вас закатать iso-образ на твердотельный носитель с помощью всяких специальных утилит. С этой задачей прекрасно справляется такая команда:

# dd if=path3/linuxmint-17.1-cinnamon-64bit.iso

of=/dev/sd? bs=8M

Символ решётки тут символизирует, что она должна быть дана от имени администратора (то есть в Ubuntu и её клонах — в форме

$ sudo dd…

и так далее. Имя входящего файла образа выбрано так потому, что дальнейший рассказ у меня пойдёт исключительно о Cinnamon-редакции соответствующего релиза. Хотя, надо отметить, что установка MATE- и Xfce-редакций ничем не отличается, только инсталлятор редакции с KDE имеет некоторую специфику,

Вместо знака вопроса следует подставить литеру своего твердотельного устройства — подчёркиваю, именно устройства целиком, а не раздела на нём. Ну а значение bs (размер блока записи) взято с потолка: если не задать этот параметр, запись будет идти блоками по 512 байт, и это будет очень медленно и печально.

Конечно, использование для записи iso-образа на флешку/карточку всякого рода графических утилит тоже не возбраняется. Важно только помнить, что многие из них — дистрибутив-специфичны. Этому вопросу на Блогосайте посвящена специальная статья: Дистро в твёрдом теле.

Так или иначе, но флешка будет записана и с неё произойдёт загрузка системы — автоматически, если в ходе её ничего не делать, или, если в течении 10 секунд нажать любую клавишу, из такого меню:


Изображение2

После чего мы оказываемся в live-среде Cinnamon — пора бросить на неё взгляд, пока беглый:


Изображение3

Вдаваться в её рассмотрение сейчас не стоит — для этого у нас будет много времени после установки, к которой и приступаем. Как нетрудно догадаться, запуск инсталлятора осуществляется щелчком на пиктограмме с соответствующей подписью — Install Linux Mint. И начинается процесс с предложения выбрать язык установки — по умолчанию английский:


Изображение4

Однако, если у вас нет непреодолимого отвращения к языку родных осин, но есть желание без лишних трудозатрат иметь корректно локализованную систему, выбирайте русский, не пожалеете. Это будет язык не только интерфейса инсталлятора, но и грядущей инсталлированной системы:


Изображение5

Русификация Cinnamon до недавнего времени была далека от идеала, и со смесью нижегородского с оксфордским приходилось сталкиваться сталкиваться довольно часто. Однако в версии 2.4 ситуация резко улучшилась, и языковый микст можно увидеть только в единичных случаях.

Далее выдвигаются претензии к объёму свободного места и подключению к Интернету — приведённой цифрой первого и потребностью во втором нынче испугать трудно:


Изображение6

Следующий этап — разметка диска. Здесь надо действовать по амбициям и амунициям, так что просто прокомментирую пукты соответствующего меню:


Изображение7

Очевидно, что отмеченный по умолчанию пункт Стереть диск и установить Linux Mint подходит только для установки на «чистый» носитель или такой, содержимым которого можно безболезненно пожертвовать. Причём именно всего устройства, а не какого-либо его раздела, ибо в этом варианте диск будет переразмечен полностью, начиная с таблицы разделов.

Об установке системы на шифрованный раздел (пункт второй) сказать ничего не могу, так как никогда не пробовал (и сомневаюсь в необходимости в обычных «настольных» условиях). Установка с использованием LVM (Logical Volume Manager) показалась мне не очень прозрачной, и я её тоже не опробовал. Но со временем расскажу, как задействовать LVM в уже инсталлированной системе. И потому я всегда выбираю Другой вариант: он подразумевает разметку диска вручную. Как её выполнить — говорено и переговорено на бесчисленных ресурсах в Сети: тут всё зависит от ситуации, потребностей и возможностей. Так что просто приведу несколько скриншотов, иллюстрирующих самый простой случай — разметку одиночного «чистого» на два раздела — корневой и под будущий домашний каталог (каковой, кстати, в умолчальном первом варианте не создаётся).

Итак, перед нами чистый, неразмеченный диск:


Изображение8

Можно видеть, что ни одна из кнопок манипуляции разделами (+, , Change) не активизирована, ибо диск наш лишён таблицы разделов. Которую и надо в первую очередь создать, нажав соответствующую кнопку. Ответом будет предупреждение о том, что все ранее существовавшие разделы будут уничтожены. Поскольку их всё равно нет, соглашаемся на это:


Изображение9

В результате будет создана таблица разделов в стиле MSDOS. Создание GPT-разметки не предусмотрено, но если диск был предварительно размечен в этом стиле — он прекрасно воспримется инсталлятором.

Теперь активизируется кнопка с плюсиком — очевидно, что она служит для создания разделов. Однако, прежде чем заняться этим делом, бросим взгляд на строку Устройство для установки системного загрузчика, каковым на скриншоте выступает /dev/sda. То есть загрузчик будет установлен в MBR первого диска, что для «чистой» однодисковой (и к тому же виртуальной) конфигурации вполне естественно. А вот в случае какой-либо уже установленной системы, особенно при наличии двух и более дисков, этот момент требует внимания.

Дело, однако, в том, что первый диск (то есть устройство /dev/sda) будет по умолчанию целевым для установки загрузчика вне зависимости от того, на какой диск и или раздел устанавливается Mint, что в большинстве таких случаев не только не нужно, но и прямо вредит здоровью сосуществующих систем. И потому надо ни в коем случае не забыть выбрать из выпадающего меню нужное устройство — MBR диска или PBR раздела, целевых при установке Mint.

К сожалению, вообще отказаться от установки загрузчика нельзя, даже когда он заведомо лишний, и Mint предполагается загружать через загрузчик какой-либо иной системы. Эта багофича унаследована от Ubuntu, где существует испокон веков. Но можно обмануть установщик, подсунув ему в качестве целевого MBR какого-либо «левого» устройства, например, старой ненужной флешки или SD-карты, каковые потом просто извлекаются, как-будто так и было.

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

Изображение10А затем для раздела под будущий каталог /home:


Изображение11

И в результате получаем вот такую картину:


Изображение12

По умолчанию в обоих случаях предлагается файловая система Ext4. Если она почему-либо не устраивает — можно ознакомиться со списком доступных, он включает все нативные файловые системы Linux’а, кроме ReiserFS:


Изображение13

Должен заметить, что на стадии установки в Mint не только нельзя создать, скажем, программный RAID (в отличие от Ubuntu, в которой это уже предусмотрено): нельзя даже установить систему на softRAID, созданный заблаговременно, инсталлятор его просто не увидит. Впрочем, в дальнейшем, после установки, ни подключить существующий RAID, ни слздать его заново труда не составит, о чём будет говориться в соответствующем очерке.

Как можно было видеть, в приведённой схеме разметки отсутствует раздел подкачки. О чём и будет сообщено на следующей стадии:


Изображение14

Нужен такой или нет — вопрос спорный и многократно обсуждавшийся. На мой взгляд, при памяти от 4 ГБ в большинстве случаев, кроме некоторых специальных, не нужен. Так что можно продолжать — это действие вызовет последнее китайское предупреждение:


Изображение15

Смысл его в русском переводе может показаться не вполне внятым. Он сводится к тому, что все действия по разметке диска будут выполнены только сейчас, но после этого возврат к прошлому станет невозможным — до сих пор установку можно было в любой момент прервать, сохранив исходное состояние диска.

Поскольку бояться нам нечего, нажимаем кнопку Продолжить. И, после некоторого времени, требующегося на разметку и создание файловых систем, совершаем последние манипуляции — настройку часов, клавиатуры и создание пользовательского аккаунта.

С выбором часового пояса всё понятно без комментариев — при выборе русского языка инсталляции он будет московским и подразумевать установку «железных» часов по UTC:


Изображение16

Так что обитателям более иных городов и весей нашей необъятной Родины следует не забыть внести нужные изменения — это можно сделать, просто ткнув курсором мыши в район Петропавловска Камчатского (Улан-Удэ, Новосибирска — нужное дописать).

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


Изображение17

Он устроит большинство применителей — но не таких старых «печатно-машинистов», как автор этих строк. Что же, никто не запрещает выбрать вариант Typewriter Legacy — это раскладка советских пишущих машинок, почему-то объявленная устаревшей. И даже опробовать его в деле, переключаясь с латиницы на кириллицу через Alt+Shift:


Изображение18

Смены переключателя раскладок на стадии установки не предусмотрено — её можно будет поменять потом, средствами Cinnamon. Зато установленная сейчас раскладка сохранится после установки не только в Иксах, но и в «голой» консоли. Причём даже такая нетипичная, как при моём выборе. Это чуть ли не уникальный случай — в других дистрибутивах для консоли раскладку Typewriter Legacy мне приходилось изготавливать самому.

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


Изображение19

После этого начинается собственно установка, то есть перенос системы на целевой носитель:


Изображение20

В Ubuntu это делается весьма неторопливо. В инсталляторе же Mint едва успеваешь заварить себе кофий или выкурить сигарету, как обнаруживаешь на экране вот такое сообщение:


Изображение21

После которого только и остаётся, что перезагрузиться. Правда, после этого будет ещё одно сообщение:


Изображение22

Если установка проводилась с DVD-диска, он будет извлечён из привода автоматически, и Enter можно нажимать сразу. Если с флешки или SD-карты — соответствующее устройство желательно предварительно удалить. Ну а что получилось в результате инсталляции — будет рассказано в следующем очерке.

Mint и Cinnamon: обзор среды

Предыдущий очерк мы завершили тем, что после удачной установки отправили машину на перезагрузку. После которой, проскочив меню GRUB’а (в случае одной системы по умолчанию оно не выводится), оказываемся в дисплейном менеджере MDM с предложением авторизоваться:


Изображение23

По принятии этого предложения перед нами предстаёт рабочий стол Cinnamon с экраном приветствия:


Изображение24

И о дисплейном менеджере, и об экране приветствия случай поговорить ещё будет. Нынешний эе очерк будет посвящён интерфейсу рабочего стола Cinnamon, так как именно там в основном будет проходить деятельность применителя, избравшего соответствующую редакцию дистрибутива Mint.

Cinnamon. Общий вид

При первом своём запуске Cinnamon выглядит более чем традиционно – перед нами самый обычный рабочий стол с управляющей панелью, на которой имеется кнопка с подписью Меню (или Menu, в зависимости от локализации):


Изображение25

В отличие от GNOME Shell’а или Unity, здесь сразу ясно, что делать дальше. Во-первых, можно щёлкнуть правой кнопкой мыши по рабочему столу, чтобы увидеть его контекстное меню:


Изображение26

Здесь почти всё понятно без комментариев, пару слов можно сказать только про два пункта:

  • Добавить десклеты – добавление на рабочий стол мини-приложений (подробнее об этом будет сказано в следующем очерке);

  • Открыть как администратор – вызов, после ввода пароля, файлового менеджера Nemo с правами суперпользователя.

Во-вторых, щёлкнув правой же кнопкой мыши по свободному полю управляющей панели, можно заняться её настройками (о чём будет разговор в соответствующем очерке):


Изображение27

Или, уже с помощью левой кнопки, вызвать одно из приложений, пиктограммы запуска которых уже имеются на панели. По умолчанию их не густо – браузер Firefox, унаследованный от GNOME терминал и файловый менеджер Nemo:


Изображение28

Но пополнить панель иконками приложений первой необходимости труда не составит – и со временем я расскажу, как.

Наконец, в-третьих, можно обратиться к главному меню Cinnamon для знакомства со всем изобилием установленного софта:


Изображение29

Но обзор штатных приложений дистрибутива будет дан в соответствующем очерке.

Как и во всех современных рабочих средах, в Cinnamon’е можно задействовать несколько виртуальных рабочих столов. В терминах этой среды они называются рабочими областями (Workspaces), и по умолчанию их два. Переключение между рабочими областями – комбинациями клавиш Control+Alt+Right/Left.

Есть и другие способы переключения между рабочими областями, и количество их можно увеличить до любого разумного предела. Но это относится уже к категории настроек, которым будет посвящён отдельный очерк.

Управляющая панель

Если на рабочем столе (точнее, в рабочих его областях) происходят основные события, то управление этими событиями в значительной мере осуществляется с панели – в других средах её часто называют главной, или управляющей. Но в Cinnamon её принято называть без определений, поскольку здесь она обычно имеется в единственном экземпляре. Хотя в принципе в нём может быть включена и вторая панель, о чём речь пойдёт в очерке о настройках.

Положение панели по умолчанию – вдоль нижней части экрана, хотя её можно переместить и наверх. И разделяется она на следующие части (слева направо):

  • кнопка главного меню (опять же – обычно просто Меню);

  • область запуска приложений (Panel Launcher) с пиктограммами – как уже было сказано, по умолчанию их всего три;

  • область открытых приложений (Window list);

  • область системных сообщений (Notifications);

  • системный лоток (System Tray), куда помещаются пиктограммы «перманентно работающих» приложений;

  • несколько пиктограмм разного назначения – список открытых окон (Windows Quick List) и подключаемых накопителей (Removable Drives), модуль сетевых соединений, регулятор громкости, часы, индикатор раскладки клавиатуры, пиктограмма менеджера обновлений.


Изображение30

Кроме того, имеется «пользовательская кнопка» – она показывает сведения о текущем аккаунте, вызывает системные настройки, через неё блокируется экран и переключаются пользователи, осуществляется вход в так называемый «гостевой» сеанс, а также выполняется завершение сеанса работы, перезагрузка машины и её выключение:


Изображение31

Все области и кнопки панели представляют собой так называемые апплеты – мелкие программки, не способные к самостоятельному функционированию. Некоторые из этих апплетов (Panel Launcher, Window list, System Tray) представляют собой контейнеры для помещёния в них других пиктограмм (запуска, открытых окон, и так далее), другие же существуют как бы сами по себе.

Апплеты могут добавляться на панель и удаляться с неё. Содержимое апплетов-контейнеров добавляется или автоматически (System Tray, Window list), или вручную (Panel Launcher). Удаление апплетов-контейнеров приводит к исчезновению всего их содержимого. Элементы из лаунчера можно удалять по одному, содержимое лотка и области приложений – вместе с закрытием соответствующих программ.

Главное меню

Центральным (хотя и левым крайним) элементом панели является, безусловно, главное меню, с которым и настало время ознакомиться подробнее. На первый взгляд оно ничем не отличается от обычных менюшек «пускового» типа, с их страшной многоступенчатой иерархией. Однако если вглядеться в соответствующий скриншот ещё раз – различия обнаруживаются, и весьма существенные:


Изображение32

Перво-наперво, обратим внимание на колонку пиктограмм вдоль левого края поля меню:


Изображение33

Набор их в сборке Cinnamon для Mint включает иконки для запуска:

  • браузера Firefox;

  • менеджера программ mintinstall;

  • Центра управления (он же – Системные настройки);

  • терминала;

  • файлового менеджера Nemo.

Кроме того, имеются значки блокировки экрана, выхода из сеанса и завершения работы. Конечно, к последним действиям можно получить доступ и через User Applet панели, но там его ещё надо разглядеть и до действий докопаться, а тут они всегда на виду.

Не менее примечательна поисковая строка в верхней части экрана – она предназначена для поиска приложений. Но не простого, а золотого инкрементного. То есть, введя в ней последовательность символов libre, мы получим список только тех пунктов меню, которые её содержат, то есть компонентов LibreOffice:


Изображение34

То есть строка поиска в меню Cinnamon тихо и скромно, без шума и пыли выполняет ту же функцию, что и пресловутый Dash в Unity (и его аналог в GNOME 3). Правда, с её помощью нельзя устанавливать программы или искать «парнуху» в Интернете – но не больно-то и хотелось.

А вот искать по русским словам – с некоторыми ограничениями можно. Введя, например, слово редактор, мы увидим приложения, содержащие его в своём имени:


Изображение35

А на слово текст ответом будет список приложений, содержащих его и в описании:


Изображение36

На мой взгляд, сказанного уже достаточно, чтобы проникнуться величием среды Cinnamon. Однако это ещё не всё – оно проявляется и в управлении окнами. Однако прежде чем говорить на эту тему – остановимся на вопросе, как эти окна открывать.

Вызов приложений

Открываются окна обычно вместе с запущенными в них приложениями. Способов же запуска последних в Cinnamon, как и во всех современных десктопах, несколько.

Первый, наиболее универсальный – запуск из командной строки терминала путём ввода соответствующей команды. Однако обычно полноразмерное терминальное окно использовать для этого не целесообразно, его вполне можно заменить панелью мини-терминала – она вызывается обычной для всех десктопов комбинацией клавиш Alt+2:


Изображение37

До некоторого времени панель мини-терминала в Cinnamon не блистала функциональностью – в ней не было ни автоподолнения, ни истории команд, имелась только возможность ввести команду руками или вставить её из буфера. Однако в Cinnamon 2.6 все эти прелести появились. Историю команд можно, как и в шелле, просмотреть с помощью стрелок Up и Down. И автодополнение команды происходит после набора первых трёх символов её имени, в случае альтернатив выводя все доступные варианты:


Изображение38

Правда, при вызове панели минитерминала блокируются как любые любые действия мышью, так и ввод с клавиатуры. Открывается она всегда по центру, и перемещёнию не поддаётся. Так что пользоваться этой панелью не всегда удобно. Однако её возможности сполна, а то и с лихвой, заменяются функциями строки инкрементного поиска в главном меню, о которой только что говорилось. Именно она становится основным инструментом запуска приложений для тех применителей, которым, как автору этих строк, проще набрать несколько символов из имени программы, нежели, подобно Баяну, «мысью рыскать» в её поисках по менюшному древу. Тем более, что привычные программы, вызываемые давно памятными командами, в меню, тем более русифицированном, могут носить самые неожиданные имена, и потому опознаваться с трудом.

Сразу по вызове главного меню мышью или хоткеем (в Cinnamon, как и в Unity, для этого по умолчанию зарезервирована левая win-клавиша, она же Super_L), строка поиска находится в фокусе ввода, и можно начинать набор имени приложения. Только нужно помнить про раскладку клавиатуры: как бы ни было настроено её наследование (о чём речь пойдёт в одном из следующих очерков), в этой строке она всегда будет наследоваться от раскладки последнего активного окна, а не от раскладки по умолчанию.

Разумеется, для запуска приложений можно пользоваться и главным меню непосредственно, тем более что некоторые из них (браузер, терминал, Центр управления, файловый менеджер), как только что говорилось, вынесены в нём на отдельную панель в виде кнопок быстрого запуска. А вот остальные программы в меню уже надо поискать – тем более что, повторяю, там они могут именоваться весьма причудливо.

Благо, пиктограммы наиболее востребованных приложений из меню можно поместить в Launcher на главной панели, на рабочий стол или в пункт Избранное. Для этого достаточно щёлкнуть правой кнопкой на имени нужной программы и из контекстного меню выбрать требуемый пункт:


Изображение39

Кроме того, иконки приложений можно просто перетаскивать мышью из меню в Launcher. Причём – сразу в желаемое его место, тогда как при автоматическом помещёнии иконок они попадают в его конец, и их перетасовка потребует дополнительных телодвижений.

Как только что было сказано, пиктограммы запуска приложений можно поместить и на рабочий стол, и запускать их оттуда. Однако я этим способом никогда не пользуюсь — он кажется мне неудобным, и и рабочего стола у меня обычно не видать за распахнутыми окнами.

Вот теперь, разобравшись с запуском приложений и открытием вмещающих их окон, можно переходить и к управлению последними.

Управление окнами

В предыдущем разделе очерка речь шла о способах запуска приложений, в этом же поговорим о способах управления приложениями, которые уже запущены. Поскольку мы (пока ещё) живём в системе, которая официально называется X Window System, то большая часть приложений запускается в её окнах. Так что в основном применителю придётся иметь дело с ними.

Вид окон с запущенными приложениями зависит от темы рабочего стола, стиля окон и других индивидуальных настроек. Но по умолчанию они выглядят примерно так:


Изображение40

Управление окнами подразумевает в первую очередь переключение между ними. Что можно сделать несколькими способами. Первый, напрашивающийся, щелчком любой кнопкой мыши в области окна. В этом случае окну передаётся фокус и оно, как принято говорить, «поднимается», то есть оказывается на первом плане. Просто перевод курсора мыши на другое окно переводит его в фокус (то есть оно может скроллироваться), но не поднимает.

Как можно видеть на скриншоте, в одной рабочей области может быть открыто несколько окон, которые могут частично или полностью перекрываться. И тогда универсальный универсальный способ переключения между окнами, существующий во всех графических средах, – комбинация клавиш Alt+Tab. Удержание её в нажатом состоянии выводит ленту значков открытых окон, с миниатюрой для окна активного:


Изображение41

Третий способ переключения между окнами – область Window List на управляющей панели:


Изображение42

Есть ещё переход в режим масштабирования рабочей области, но по умолчанию этот способ отключен, поэтому я вернусь к нему чуть позже.

Сказанное относится к переключению между окнами, расположенными в одной рабочей области. Но они могут пребывать и в разных областях – как мы помним, по умолчанию их две. И в этом случае один из способов переключения между ними, имеющийся «из коробки» – апплет Windows Quick List (в последних версиях Cinnamon он помещён на панели по умолчанию):


Изображение43

Второй же – переход в режим Expo через один из «горячих углов», о чём также будет говориться вскоре.

Теперь посмотрим, что можно делать с самими окнами. В строке заголовка каждого окна, кроме самого заголовка, в правой его части можно видеть три управляющие кнопки (слева направо): сворачивания, максимизации/восстановления исходного размера, закрытия – назначение их очевидно.

Кое-какие манипуляции с окнами можно выполнять и кликами мыши по строке заголовка. Так, двойной щелчок левой её кнопкой вызывает максимизацию окна, повторение его – восстанавливает исходный размер. Тот же двойной клик, но уже правой кнопкой сворачивает окно на панель задач. Для средней кнопки предусмотрен только одинарный клик – он «опускает» окно на задний план.

Лишь закрыть окно нельзя кликами мыши по строке заголовка. Но это делается (если не обращаться к штатному меню запущенного в окне приложения) комбинацией клавиш Alt+F4 – подобно Alt+Tab, она также универсальна для почти всех графических сред (или вообще всех современных?). Кроме того, закрыть окно можно из его собственного меню – оно вызывается щелчком правой кнопки мыши по строке заголовка, и содержит такие пункты:


Изображение44

Назначение первых четырёх и последних двух пунктов абсолютно понятно. А вот о тёх «средних» пару слов сказать можно. Отметка Закрепить на переднем плане – это запрет перекрытия данного окна другими. А пункты Всегда на видимом рабочем месте и Только на этом рабочем месте (включён по умолчанию) – альтернативны: при включении первого окно будет «кочевать» вслед за перемещёниями пользователя по рабочим областям.

Тайлинг окон

Всё, что было только что сказано относительно управления окон, не покажется чем-то необычным применителю любого современного десктопа и приверженцам подавляющего большинства оконных менеджеров. А вот сейчас речь пойдёт о вещи более неожиданной – о тайлинге окон. Это – та самая вторая особенность (после строки поиска в меню), которая столь восхитила меня в Cinnamon’е.

Для начала – пара слов о том, что такое тайлинг. Он основывается на той же идее, что и консольная утилита screen или двухпанельные файловые менеджеры – потомки командира Norton’а – расщеплении экрана на ряд независимых областей, в каждой из которых локализуется окно с запущенным в нём приложением. Это подобно покрытию пола кафелем (tiling), чем и порождена аллюзия.

При этом понятие управления окнами как бы лишается смысла – тайлинговые системы управляют не столько окнами, сколько теми самыми областями экрана, в которых окна открываются. Области эти (в чём-то они похожи на фреймы, некогда популярные среди web-дизайнеров) могут быть статическими, с жёстко определёнными размерами, и динамическими, при котором их размеры изменяются при масштабировании окон запущенных в них приложений. В Cinnamon реализована первая модель.

Конечно, тайлингом удивить пользователей менеджеров окон типа Awesome сотоварищи не легче, чем испугать ежа голой… эээ… спиной. Однако во времена не очень больших экранов я этой идеей не проникса (парадигма «одно приложение – одна рабочая область» была мне ближе). А ко времени мониторов больших и широкоэкранных тайлинг подоспел и в десктопах – в Xfce и KDE. Однако в сравнении с Cinnamon’овским тайлинг в них выглядит что плотник супротив столяра. Ибо предусматривает расщепление экрана только на две области – по горизонтали или по вертикали. В Cinnamon’е же возможности тайлинга намного богаче.

Начать с того, что в Cinnamon’е окна можно «тайлить» не только на поэкрана – например, по вертикали:


Изображение45

Или, если хочется, по горизонтали:


Изображение46

Но есть и «четвертиночный» вариант разбивки экрана:


Изображение47

А подчас даже

…получается в ответе
Два землекопа и две трети

Примерно как на этом скриншоте:


Изображение48

Тайлинг окон не препятствует существованию на его фоне окон обычных:


Изображение49

Вот только, к сожалению, средства «тайлить» окна на произвольные области экрана на предусмотрено. Однако и без этого область его использования достаточно широка, в чём мы убедимся после рассмотрения средств управления тайлингом.

Управление тайлингом

Тайлинг окон может выполняться двумя способами – посредством мыши и с клавиатуры. Как обычно, первый – легче, то есть «ленивей», второй – быстрее и эффективней. Замечу в скобках: как обычно, это вовсе не означает оценки в терминах товарища Маяковского. Иногда «хорошо» – это лениво развалясь в кресле, елозить мышью по экрану, а иногда – напрягать пальцы рады быстроты выполнения неких действий.

Рассмотрим сначала тайлинг мышью, выполняемый над окном с положением и размерами, соответствующими умолчаниям десктопа:


Изображение50

При подтаскивании окна мышью к верхней границе экрана оно занимает верхнюю же его половину:


Изображение51

Аналогичное движение к нижней границе экрана разворачивает окно на нижнюю его половину:


Изображение52

Перемещёние окна к боковой стороне экрана «тайлит» его на левую


Изображение53

или правую половины, в зависимости от стороны «подтаскивания»:


Изображение54

Если передвинуть окно в любой из углов дисплея, оно займёт соответствующую его «четвертинку»:


Изображение55

То есть всё просто, но… Предположим, что при сочинении текста в текстовом редакторе (или word-процессоре) появилось желание параллельно бросить взгляд на картину, призванную этот текст иллюстрировать: в этом случае тайлинг посредством мыши потребует отрыва руки от клавиатуры и переноса её на спину грызуна. И вот тут-то на помощь и придёт тайлинг с клавиатуры, который осуществляется комбинацией из двух пальцев – клавиши Super (она же – левая Win) и одной из стрелок управления курсором.

Опять же подвергнем издевательствам исходное окно с умолчальными параметрами. Комбинация Super+Right развернёт её на правую половину экрана, Super+Left – вернёт в исходное состояния. Из которого комбинацией Super+Left оно развернётся на левую половину, а последующий Super+Right – возвратит взад. Из положения «половинка справа» комбинация Super+Up превратит окно в «четвертинку» в правом верхнем углу, Super+Down – «четвертинку» в правом нижнем.

Принцип, я думаю, понятен: Super плюс стрелка в любую сторону – окно на соответствующую половинку экрана, Super плюс стрелка в обратную – возврат в исходное положение, Super плюс стрелка из «половинного» состояния – перевод в состояние «четвертиночное». Запомнить это не сложно, навык до рефлекторного уровня приобретается очень быстро. А как его можно применить на практике – сейчас увидим.

Тайлинг на практике

Всё это очень блаародно – вправе сказать читатель, – но в чём преимущество тайловых окон перед обычными? Долгое время ответа на этот вопрос у меня не было, тем более, что я окнами почти не пользовался: во всё ширь каждого десктопа у меня было открыто одно приложение. Пока не опробовал тайловый режим – сначала в Xfce 4.10, где он незатейлив, а затем и в среде Cinnamon, в которой, как я пытался показать на предыдущих страницах, он куда более изощрён.

Тем не менее, объяснить преимущества тайловых окон над масштабированными довольно трудно – это надо попробовать самому и оценить. Для меня оно выразилось в возможности мгновенно перейти от сочинения текста в полноэкранном режиме к режиму параллельного просмотра текста, иллюстраций к нему, файловой иерархии и так далее. И сделать это лёгким движением даже не руки, а двух пальцев.

Причём параллельным просмотром нескольких окон можно не ограничиваться. А, например, перетаскивать мышью или просто копипастить горячими клавишами картинки из файлового менеджера или вьювера изображений в word-процессор. Аналогичным образом можно перетаскивать из теста документации в командную строку терминала примеры командных конструкций. Или, наоборот, команды или исходники сценариев – помещать в сочиняемый текст.

Конечно, всё это можно сделать и при традиционном расположении окон, но прошу поверить на слово брату незабвенного Голубкова:

Так лучше, Лёня.

В общем, обращение с содержимым окон становится похожим на работу с двухпанельными файловыми менеджерами a la Midnight Commander. Или даже с четырёхпанельными: возможно, кое-кому из читателей памятен «пай-мальчик» – Pie Commander, незаконный четырёхглазый отпрыск командира Norton’а…

Правда, в двух- и тем более в «четырёхплиточной черепице» становится мучительно больно за бесцельно расходуемое экранное пространство, занятое в каждом окне строкой меню. И возникает сожаление об отсутствии возможности встроить его в главную управляющую панель, как это делается по умолчанию в Unity. Но увы – нет в жизни совершенства, ибо нет в Cinnamon такой возможности. Иначе он безусловно достиг бы высшей степени совершенства, а его разработчики имели бы полное право впасть в нирвану.

Интерфейс Cinnamon: краткий итог

В этом очерке были описаны особенности интерфейса Cinnamon, которые представляются мне наиболее существенными. Пора подводить итоги.

В своём современном виде Cinnamon наделён всеми функциями, присущими остальным десктопам. Причём реализованными если не идеально, то близко к тому. А две из них в сочетании оказываются почти уникальными. Это – строка инкрементного поиска в меню и развитый тайлинг. Обе они представлены и в Unity, и Xfce, и в KDE. Но в первой среде пресловутый Dash как раз функционально перегружен, предусматривая поиск в Интернете не только всякой ерунды, типа программ и пакетов, но и весьма важной и разнообразной «парнухи». В Xfce строка поиска по меню как раз зарыта в дебрях её минитерминала. Ну а в KDE эта строка есть только в «меню современного вида», которое само по себе многим (в том числе и автору этих строк) представляется неудобным. Что же до тайлинга – как я уже отметил, его реализация в Cinnamon среди всех десктопов превзойдённа.

При этом всё сказанное в этой части касалось особенностей Cinnamon’а по умолчанию. Но особенно ярко они заиграют после соответствующих настроек, которым будут посвящены следующие очерки.

Cinnamon и системные настройки

Следующая серия очерков посвящена описанию способов, как штатных, так и не очень, которые изменяют те умолчания Mint и Cinnamon, что были рассмотрены в очерке предыдущем.

Системные настройки: вступление

Подавляющее большинство настроек в Cinnamon выполняется из панели его Системных настроек (cinnamon-settings), именуемых также Центром управления. С ними тесно интегрированы фирменные утилиты Mint, имеющие отношение к конфигурированию системы. Однако они будут предеметом отдельного очерка.

Пиктограмма запуска Системных настроек занимает почётное место в левой колонке главного меню управляющей панели. Через один-два клика мышью до них можно добраться и из контекстных меню как самой панели, так и рабочего стола. И при первом запуске выглядит он так:


Изображение56

Ранее Системные настройки имели два режима — нормальный и расширенный, и реликты такого положения можно найти в сетевых материалах. Однако, начиная с Cinnamon версии 2.2, эта дискриминация ликвидирована, и расширенный режим стал нормой жизни применителя.

Если пролистать окно Системных настроек до конца, можно увидеть, что отдельные её модули группируются в четыре секции:

  • Оформление

  • Параметры

  • Оборудование

  • Администрирование

Далее я последовательно рассмотрю возможности каждого модуля примерно в том порядке, в котором они следуют в русскоязычном варианте Cinnamon. Отклоняясь от него, когда когда того потребует логика.

Секция Оформление

Секция Оформление включает в себя модули:

  • Темы;

  • Фоновые рисунки;

  • Шрифты;

  • Эффекты.

Модуль Темы выглядит таким образом:


Изображение57

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


Изображение58

Пиктограмм:


Изображение59

Управляющих кнопок окна:


Изображение60

Указателей мыши:


Изображение61

И, наконец, для собственно тем рабочего стола:


Изображение62

Обращает на себя внимание изобилие расцветок умолчальной темы Mint-X, с одной стороны, и пиктограмм — с другой. Это позволяют комбинировать элементы оформления интерфейса в очень широких пределах, достигая максимального визуального эффекта. Что, между прочим, сколько бы ни иронизировали на эту тему, имеет практическое значение, особенно для людей с плохим зрением или нарушением цветовосприятия.

С помощью кнопки Добавить/удалить темы рабочего стола умолчальную тему Mint-X можно заменить на одну из предустановленных:


Изображение63

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


Изображение64

Но будет вознаграждено обильным уловом:


Изображение65

Правда, перепробовав немало тем, я в конечном счёте вернулся к умолчальной Mint-X. И даже отказался от её модификации — этому занятию ранее я тоже отдал свою дань, и потому опишу в конце данного очерка.

Модуль Фоновые рисунки в нынешней Cinnamon — это не просто банальные обои. Нет, конечно, их можно использовать и в этом качестве. Но самый цимес модуля — организация слайд-шоу из нескольких предустановленных наборов картинок, носящих имена былых и нынешних релизов Mint:


Изображение66

И не только из них — в качестве такого набора можно легко подключить каталог с собственными изображениями, на следующем скриншоте таковым выступает my_backgrounds):


Изображение67

Модуль Шрифты позволяет определить гарнитуры, шрифтоначертания и кегли для элементов интерфейса, документов и терминальных окон. По умолчанию в качестве интерфейсных (пропорциональных) шрифтов в Cinnamon, начиная с версии 2.4, используется гарнитура Noto Sans собственной выделки:


Изображение68

Мне эта гарнитура понравилась до чрезвычайности:


Изображение69

Особенно с учётом того, что она не одинока — в дополнение к ней имеется и гарнитура с отсечками, как нетрудно догадаться, именуемая Noto Serif:


Изображение70

То есть семейство гарнитур Noto оказывается почти самодостаточным не только для интерфейса среды и её приложений, но и для оформления документов. Почти — потому что в нём явно не хватает какой-либо моноширинной гарнитуры для использования в текстовых редакторах и терминальных окнах. Впрочем, я это восполняю последнее время за счёт моноширинного представителя семейства Liberation — Liberation Mono. В результате чего мои шрифтовые настройки выглядят следующим образом:


Изображение71

Тут нужно оговориться, что настройка шрифтов главного меню управляющей панели, подписей и всплывающих подсказок на ней возможна только путём прямого редактирования стилевого файла выбранной темы рабочего стола, о чём будет говориться в следующем разделе этого очерка.

А пока — про Эффекты. По умолчанию этот модуль выглядит таким образом:


Изображение72

До недавнего времени тут я просто снимал галочку с бокса Включить эффекты рабочего стола и больше на эту тему не думал. Предоставляя разбираться с «красивостями» тем, кто таким образом охмуряет молоденьких вендузятнец. Однако в Cinnamon эффекты мне неожиданно понравились своей плавностью и ненавязчивостью. Так что я затратил некоторое время на приведение к такому виду:


Изображение73

На этом в данный момент я с оформлением закончил. Однако, как и обещал, под занавес расскажу о том, как редактировать темы рабочего стола. Хотя, как уже было сказано, в конце концов я вернулся к умолчальной Mint-X, но как опыт это было интересно.

Cinnamon и собственные темы

В отличие от большинства остальных очерков, в этом разделе я описываю не актуальную версию Cinnamon 2.4, а её предшественниц 2.0 и 2.2. Где ни одна тема, даже самая красивая, не подходила мне целиком и полностью. В текущем же релизе неожиданно оказалось, что тема по умолчанию, Mint-X, устраивает меня во всех отношениях. Тем не менее, я решил включить описание моих тогдашних развлечений в эту книгу — вдруг когда возникнет желание заняться этим делом снова?

Как только что было сказано, настройка шрифтов Cinnamon действует на все элементы его интерфейса, кроме панели и главного меню. Причём следствие, проведённое в то время, показало, что в панели и меню шрифты зависят от темы оформления: при смене её гарнитура в этих элементах интерфейса менялась, хотя кегль оставался если не неизменным, то обычно маленьким и трудно различимым.

После отправки дела на доследование оказалось, что так оно и есть: кегли шрифтов для меню и разных элементов панели (а в ряде случаев – даже и гарнитуры) жёстко прописывались в CSS-файле всех тем, которые я просмотрел. А поскольку все они были изготовлены зоркими соколами, кегли эти везде были очень маленькими, от 7 до максимум 11 пунктов.

Обсуждать вопрос о том, насколько это идеологически правильно, здесь не буду. Конечно, на мой взгляд, неправильно абсолютно – ибо противоречит идее сквозных настроек десктопа, последовательно проводимой в KDE и Xfce. Однако идеология – идеологией, а практика – практикой: поскольку это оказался чуть ли не единственный недостаток Cinnamon’а, его следовало по возможности искоренить, а не рассуждать на тему

Что делать, блин?
И кто, блин, виноват?!

Что делать – было ясно: редактировать тему, наиболее близкую по всем остальным показателям. А как делать – в принципе стало ясно из прочтения материала Клемента Лефевра, к переводу или оригиналу которого и отсылаю заинтересованного читателя. Здесь же лишь кратко опишу последовательность собственных действий.

В качестве подопытного кролика я выбрал тему Void, все относящиеся к ней файлы имели место быть у меня в каталоге ~/.themes/Void/cinnamon. В том числе и cinnamon.css, который я отредактировал самым простым способом: без лицемерия явным образом указал гарнитуру:

stage {

font-family: «Cantarell»;

}

Затем просто добавил один-два пункта к кеглям шрифтов всех интерфейсных элементов. А заодно из темы Canelita потырил пиктограмму для кнопки главного меню – умолчально-зелёная в мою цветовую гамму вписывалась плохо.

И вот что получилось в итоге:


Изображение74

Секция Параметры

Если модули секции Оформление отвечают за внешний вид среды Cinnamon, то в секции Параметры собраны модули, определяющие её поведение. Это — самая обширная секция среди Системных настроек, и в полностью обозримом виде она выглядит так:


Изображение75

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

Автозапуск

Модуль Автозапуск предназначен для управления программами, автоматически загружаемыми при старте сеанса Cinnamon, как системными, так и сугубо прикладными. По умолчанию список их выглядит так:


Изображение76

Способы коррекции списка очевидны: снятие «птицы» с соответствующего бокса отключает загрузку данной программы (например, mintwelcome, выводящей приветственную панель при запуске сеанса), кнопка Удалить исключает её из списка вообще, а с помощью кнопки Добавить список пополняется программами по желанию применителя. Для чего в появившейся панели надо заполнить поля Имя (желательно соответствующее имени программы), Команда (имя запускающего файла, при необходимости — с указанием пути) и, по желанию, Комментарий (в свободной форме). Например, для выпадающего терминала Tilda (использование которого без автозапуска лишено смысла) это выглядит так:


Изображение77

В результате таких действий у меня панель автозапуска выглядит таким образом:


Изображение78

По умолчанию в панели автозапуска отображаются далеко не все автоматически запускаемые приложения — в ней мы не увидим всякого рода системных служб. Чтобы сделать их видимыми, нужно отредактировать соответствующие конфиги в каталоге /etc/xdg/autostart/, имеющие вид *.desktop. Каждый из них включает в себя параметр NoDisplay, отвечающий за вывод на экран, и значение его по умолчанию true. Которое достаточно заменить на false, чтобы увидеть весь стартовый букет служб и приложений. Сделать это в один присест можно при помощи утилиты sed, запущенной с правами администратора:

$ sudo sed -i ‘s/NoDisplay=true/NoDisplay=false/’ /etc/xdg/autostart/*

Годится для этого и любой развитый текстовый редактор, позволяющий выполнять поиск и замену в серии файлов (Geany, Komodo Edit).

В предыдущих версиях Cinnamon в панели автозапуска имелся боксик Автоматически запоминать запущенные приложения при выходе из сеанса. Правда, работал он из рук вон плохо, и потому в текущей версии был в Системных настройках ликвидирован как класс. Но возможность включить сохранение сеансов сохранилась в Редакторе dconf, о котором будет говориться своевременно.

Апплеты, десклеты и расширения

Апплеты уже мельком упоминались в очерке об интерфейсе Cinnamon, а вот про десклеты и расширения речи ещё не было. Так что для начала скажу пару слов о том, что это такое.

Название апплеты является уменьшительно-ласкательной формой английского application, то есть по русски — программульки, или маааленькие программы. Однако главное не в их размере, а в том, что они работают только внутри других, «полноценных», программ, и не способны к самостоятельному существованию. В нашем случае апплетами являются пиктограммы управляющей панели Cinnamon’а, которые вне её не то что функционировать — жить не могут.

Десклеты — это название принято в Cinnamon’е для элементов, которые в других рабочих средах называют виджетами (то есть «штуковинами»). Как и апплеты, самостоятельно роли они не играют. Но, в отличие от тех, встраиваются на рабочий стол (откуда, видимо, и название).

Что же до расширений (extensions), их назначение понятно из названия: подобно плагинам и прочим add-on’ам, они добавляют к базовой функциональности десктопа дополнительные возможности (например, добавление второй нижней панели плюс к главной управляющей).

А теперь посмотрим, как эти самые апплеты, десклеты и расширения настраиваются. Начав по алфавиту, с первых.

Собственно, настройка апплетов сводится к двум моментам. Первый — это добавление на панель уже установленных апплетов или, напротив, удаление с неё добавленных:


Изображение79

Второй момент — загрузка списка апплетов не установленных, выбор из них нужных и установка последних:


Изображение80

Я думаю, что обе задачи заинтересованный читатель сможет решить без труда. Как и вопрос с определением нужности или ненужности конкретных апплетов. Попрошу только обратить внимание на апплеты Workspace switcher и Expo в списке предустановленных, но не используемых — они скоро потребуются нам в одном из ближайших разделов этого очерка.

А при установке подгружаемых апплетов надо учитывать, что при переходе от Cinnamon версии 2.2 к 2.4 произошла смена API. И, по сообщениям в Сети, не все из сторонних апплетов, сочинявшихся ещё для прежних версий, обязаны корректно работать в последнем релизе. Впрочем, со временем эта проблема теряет актуальность.

С десклетами дело обстоит сходным во всех отношениях образом. Во-первых, их также можно выбрать из числа предустановленных, каковых всего три:


Изображение81

Во-вторых, можно просмотреть список десклетов, доступных в Сети, и включить их в список установленных:


Изображение82

В-третьих, можно настроить оформление десклетов (в рамке, с заголовком или без ничего) и их размещёние (привязка к сетке с заданным шагом).:


Изображение83

Для подключения десклетов из списка установленных их остаётся только добавить на рабочий стол — подобно пиктограммам рабочего стола, они появятся во всех рабочих пространствах:


Изображение84

Вопрос, нужны ли народу десклеты, остаётся спорным. С одной стороны, болтающиеся на экране дополнительные часы, калькулятор, информатор о занятости дисковых разделов или сводка погоды (а никакого иного полезного функционала я среди них не обнаружил) не особенно и видны в рабочем режиме. Но с другой — и не мешают, а при случае могут и пригодиться.

Однако тут надо учитывать два момента. Первый — к десклетам относится всё сказанное об апплетах относительно совместимости их с текущей версией Cinnamon.

Второй момент — более существенный. Как показала практика, даже десклеты, заведомо предназначенные для соответствующей версии Cinnamon, могут работать некорректно и даже приводить всю среду в полностью неработоспособное состояние.

Правда, лечится это достаточно просто — нажатием кнопки Восстановить стандартные настройки, если не помогло — ручной очисткой каталога ~/.local/share/cinnamon/desklets, но всё равно радости мало. Учитывая сомнительную пользу даже от тех десклетов, которые кажутся подозрительными на полезность.

С расширениями ситуация ещё менее однозначна. В предустановленном виде их нет ни одного, да и список доступных не так велик:


Изображение85

И среди существующих расширений вызывающих подозрения в своей полезности оказалось не мало — например, CinnaDock, похожий, судя по описанию, на Cairo, упомянутый выше 2 Bottom Panels или трёхмерный переключатель задач — 3D App Switcher. Но слова относительно совместимости с Cinnamon 2.4 относятся к расширениям ещё больше, чем к десклетам. В частности, ни одно из заинтересовавших меня в текущей версии этой среды даже не устанавливалось, не говоря уже об активизации. Я понимаю, что со временем это всё устаканится — но вот тогда и вернусь к этому вопросу.

Панель и рабочий стол

После рассмотрения апплетов, десклетов и расширений логично будет перейти к конфигурированию элементов, их вмещающих — управляющей Панели и Рабочего стола.

Правда, про настройки рабочего стола сказать особо нечего. Здесь можно только отметить, какие пиктограммы из заданного списка следует на него выводить:


Изображение86

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

В модуле Панель по умолчанию всё достаточно стандартно — расположение её «традиционное», то есть внизу экрана:


Изображение87

Однако есть немало возможностей для видоизменения. Так, панель может располагаться не только внизу, но и вверху экрана. Кроме того, их может быть две — и вверху, и внизу (как было по умолчанию в GNOME 2, и как ныне принято в его форке — MATE). Самое же главное — можно задавать произвольную высоту панели, с масштабированием текста и пиктограмм на ней:


Изображение88

Относительно автоматического скрытия всё понятно без комментариев — для кого-то это полезно, для иного же (например, для меня) — не удобно. А вот включение режима редактирования панели позволяет перетасовывать отдельные её элементы, в частности, пиктограммы в Launcher’е и в трее. Правда, при этом отключается запуск с помощью кнопок приложений на ней — то есть свои рабочие функции она выполнять перестаёт. Так что включать этот режим следует только на время — действительно при необходимости что-то перетащить.

Здесь же уместно сказать и о модуле Блокировка экрана. Сама по себе блокировка с параметрами по умолчанию — штука, меня страшно раздражающая. Особенно когда для разблокирования требуется ввод пароля. Так что первым делом я её отключаю напрочь — даже на ноутбуке. Оставляю только включение, через разумный промежуток времени, скринсейвера (который здесь, впрочем, тоже называется блокировкой):


Изображение89

А вот сам скринсейвер — предмет гордости разработчиков, и гордости законной. Потому что в нём можно задать вывод времени и даты в период блокировки, причём в собственном формате. Кроме того, вместо времени и/или даты можно указать любой произвольный текст, например

Руки прочь от моего компа

Впрочем, текст можно указать и в специально предназначенном для этого поле, например, подобно Кристоферу Робину, вот такой:


Изображение90

Как можно видеть на скриншоте, предшествовавшем этому, настройке поддаются и шрифты вывода времени, даты и текстового сообщения.

Окна и их тайлинг

В очерке об интерфейсе Cinnamon говорилось о средствах управления окнами по умолчанию. Настало время посмотреть, как эти умолчания можно изменить. Разумеется, делается это через пункт Окна. Здесь можно настроить стандартные действия при щелчках мышью на строке заголовка и режим передачи фокуса окну, если не устраивают умолчания — и думаю, очевидным способом. Меня умолчания устраивают, так что вдаваться в подробности не буду.

Самое же интересное здесь — это примирение «правосторонников»» и «левосторонников», то есть приверженцев расположения кнопок управления окном с той или другой стороны строки заголовка:


Изображение91

Как известно, в своё время революционная идея «левого уклона» кнопок в Ubuntu вызвала массу нападок со стороны «правых уклонистов» — твёрдых искровцев GNOME’вцев. В Cinnamon принято компромиссное решение — любые кнопки можно поместить как с левой стороны титульной строки, так и с правой.

Что, впрочем, тоже не ново, и испокон времён внедрено в оконных менеджерах KDE и Xfce. И чем я с давних пор пользуюсь — при общем «правом уклоне» делаю для кнопки закрытия окна «отмашку влево»: за долгие годы работы проверено, что это сильно снижает вероятность нажать её случайно, что обычно весьма не желательно.

В очерке об интерфейсе я много места посвятил описанию тайлинга окон — как одной из особенностей, делающих Cinnamon «лучшим из десктопов». Настраивается же тайлинг в модуле Прикрепление окон и притяжение… Вот только настраивать здесь особенно нечего: для приобщения ко всем прелестям тайлинга достаточно отметить боксик Включить режим прикрепления — а это и так сделано по умолчанию:


Изображение92

Что же до возможности изменить переключатель между режимами простого и защищённого прикрепления — мне она оказалась без надобности, умолчальный Control справляется с этой задачей не хуже других.

Смысл включения притяжения к границам (так называемый Flip) — вовсе не в каком-то притяжении, а, как мне объяснили резонные люди, в самом обычном переключении на соседнюю рабочую область при подведении курсора мыши к границе текущей. Это меня всегда раздражало во всех графических средах — и эту опцию я всегда отключаю.

На счёт инверсии клавиш со стрелками ничего сказать не могу, ибо не ощутил необходимости. А вот режим, названный традиционным, оказался не вредным. Только означает он, вопреки тому, как можно понять написанное, следующее: при его включении, если вам не хочется, чтобы какое-либо окно «превращалось в черепицу» при перемещёнии его к краю экрана, следует удерживать клавишу Shift.

Рабочие области и Горячие углы

Говоря в «интерфейсном» очерке о переключении между окнами, я вскользь упомянул о переключении в режим Expo, при котором на экран выводятся все наличные рабочие области. А уже в этом очерке просил обратить внимание на одноимённый апплет. Настало время поговорить обо всех этих материях подробнее.

В том же «интерфейсном» очерке говорилось, что рабочих областей в Cinnamon по умолчанию две, и способа изменить это число на поверхности не видно, а переключение между имеющимися возможно только по комбинации клавиш Control+Alt с Right или Left. И всё это правда, чистая правда, но далеко не вся правда.

Так, найти альтернативный способ переключения между рабочими областями не так уж и сложно даже при слабом знании английского. Это — упомянутый ранее апплет Workspace switcher: будучи включённым, он выводит на панель обычный переключатель рабочих столов, привычный всем пользователям интегрированных сред и многих оконных менеджеров:


Изображение93

Далее, логично было бы ожидать, что количество рабочих областей можно задать в модуле, который называется Рабочие области. Однако, открыв его, мы не увидим там и намёка на эту опцию:


Изображение94

А смысл всех остальных опций этого модуля остаётся не очень понятным — так что рассмотрение его немного отложим.

Потому что настало время вспомнить об апплете Expo. Ибо он служит для переключения Cinnamon в одноимённый режим — режим вывода на экран всех наличных рабочих областей одновременно:


Изображение95

Очевидно, что это ещё один способ переключения между рабочими областями — для чего достаточно кликнуть мышью на нужной. Но главное — это единственный способ увеличить их число, для чего служит большой жирный плюс с правой стороны экрана. А уменьшить количество рабочих областей можно с помощью крестика, появляющегося в правом верхней углу любой области при наведении на неё курсора:


Изображение96

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

Радость эта омрачается одним: изменение любой опции не влечёт за собой никаких последствий от слова абсолютно. И в результате оказывается, что единственный рабочий пункт этого модуля — Показывать экспозицию как сетку. По умолчанию он включён. Снятие же с него отметки приводит к тому, что рабочие области в Expo-режиме выстраиваются в одну линию:


Изображение97

Кстати, апплет Expo — не единственный способ переключения в одноимённый режим. Согласитесь, что было бы странно, если такая важная функция выполнялась с помощью внешнего апплета, да ещё и не включаемого по умолчанию. Главный, встроенный, способ перехода в режим экспонирования рабочих областей — комбинация клавиш Control+Alt+Up. Задействована и противоположная комбинация — Control+Alt+Down: Она переводит Cinnamon в режим, который можно назвать экспонированием окон (или режимом масштабирования): одновременный вывод всех окон всех открытых приложений текущей рабочей области, в том числе и свёрнутых:


Изображение98

Однако и это ещё не всё: существует ещё один способ переключения в оба режима экспонирования. По умолчанию он отключён, а за его настройку его отвечает модуль Горячие углы. Он обеспечивает привязку к любому из углов экрана одного из трёх действий: переключения в режим экспонирования рабочих областей, в режим масштабирования окон или очистку рабочего стола (то есть сворачивания всех окон). Действия эти происходят при подведении курсора мыши к соответствующему углу. Повторное перемещёние курсора в тот же угол возвращает Cinnamon в нормальный рабочий режим.

На следующем скриншоте в качестве «горячего» выступает правый нижний угол — к нему привязано экспонирование рабочих областей:


Изображение99

Кроме того, потенциально через «горячий угол» можно выполнить произвольную команду. Так, на следующем скриншоте приведена попытка настроить правый верхний угол на вызов выпадающего терминала Tilda:


Изображение100

Однако практика показала, что это неудобно, в том числе и потому, что при каждом наведении на «горячий угол» вызывался новый экземпляр терминала, который для начала желал, чтобы его настроили. А никакого другого применения этой фиче я не придумал. Может, у кого из читателей фантазия окажется богаче?

Конфиденциальность, Общие, Уведомления

Общего между этими тремя модулями, пожалуй, только то, что они были переработаны при переходе на Cinnamon версии 2.4.

Вся настройка конфиденциальности сводится к решению вопроса, запоминать ли открываемые файлы, и если запоминать — навсегда или на какой-то определённый срок:


Изображение101

Я остановился на варианте «вечного хранения».

В модуле Общие обнаружилась интересная функция — возможность масштабирования рабочего стола. Для этого надо значение по умолчанию, Автоматически


Изображение102

заменить на Двукратный (HiDPI):


Изображение103

Правда, после этого рабочий стол приобретает устрашающий вид даже для моего зрения:


Изображение104

Но возможно, что в некоторых случаях это будет менее плохо, чем не видеть никакого вида вообще. Ну а пока я поспешил вернуться к виду нормальному (он оказался идентичным автоматическому).

В модуле Уведомления можно, во-первых, отказаться от их вывода (по умолчанию он, разумеется, включён). Они часто раздражают — например, сообщения IM-клиента о том, что гражданин Имя Рек вошёл в сеть, а гражданин Некто из неё, напротив, вышел. Однако совсем отключать уведомления неправильно, потому что временами они несут разумное, хотя обычно как раз не доброе. А вот удалять сообщения по истечении тайм-аута — как раз разумно, что и проделано на скриншоте:


Изображение105

Кроме того, здесь же можно отрегулировать прозрачность уведомления, и немедленно протестировать это дело нажатием на соответствующую кнопку:


Изображение106

Я уменьшил прозрачность практически до минимума, так как иначе ничего не видел. А ведь уведомления — для того, чтобы их читать, не так ли?

Детали учётной записи

Не смотря на название модуля, Детали учётной записи, никаких особых деталей там нет:


Изображение107

А есть возможность поменять пароль (к чему в некоторых случаях время от времени прибегать приходится) и изменить логин. Хотя вот последнего как раз делать не следует: численный идентификатор пользователя (так называемый UID) при этом не меняется, так что, скажем, на правах доступа к файлам это сказаться не должно. Но в каких-то случаях программы могут обращаться не к UID’у, а именно к названию аккаунта, и ничего, кроме путаницы, это не даст. Зато можно приклеить собственную аватарку, как это видно на скриншоте.

Прочие параметры

По остальным пунктам секции Параметры я позволю себе пробежаться галопом — они или не очень существенны (с моей точки зрения), или тривиальны. Неохваченными у нас остались (слева направо и сверху вниз):

Дата и время, смысл которого очевиден:


Изображение108

Приложения и съёмные носители — аналогично:


Изображение109


Изображение110

Ну а Специальные возможности — они и есть специальные:


Изображение111

Не смотря на то, что они предусмотрены во всех рабочих средах и вроде бы предназначены как раз для таких как я (в частности, плохо видящих), прибегнуть к ним мне не приходилось: они либо не нужны, либо бесполезны.

Я умышленно не сказал ничего о модуле Языки. Потому что на самом деле это не модуль Системных настроек Cinnamon, а одна из фирменных утилит Mint, в ряду которых и будет рассмотрена в одном из последующих очерков.

Секция Оборудование

В секции Оборудование собраны модули, имеющие, как ни странно, отношение именно к оборудованию. И обозреть их все единым взглядом можно здесь:


Изображение112

А поскольку внутренней логикой они не особо между собой связаны (за одним исключением), и к тому же кое-какого оборудования у меня просто нет, то рассматривать эти модули я буду в произвольном порядке, руководствуясь собственными соображениями о их важности. Начав, однако, с самого общего — О системе.

О системе и дисплее

Модуль О системе не предусматривает никаких настроек, а просто выводит сведения о ней, родимой, в простой и наглядной форме:


Изображение113

Думаю, тому, кто знает такие слова, как операционная система или процессор, не составит очень большого труда догадаться о том, что означают и соответствующие им значения.

Модуль Дисплей я приплюсовал сюда же, так как в случае одномониторной конфигурации, да ещё и не с поворачивающимся экраном, он тоже просто выводит самые общие сведения о мониторе и его разрешении:


Изображение114

Во всех же прочих пунктах секции предполагается совершение некоторых настроечных действий. Из них для нас важнейшим является настройка клавиатуры — с неё-то и начнём.

Клавиатура

В модуле Клавиатура для начала можно настроить поведение при нажатии клавиш и реакцию курсора:


Изображение115

А во второй вкладке, Комбинации клавиш, определить хоткеи на очень многие случаи жизни:


Изображение116

В частности, здесь я в обязательном порядке устанавливаю клавишные комбинации для переключения между рабочими областями — Alt+1, Alt+2 и так далее (пункт Рабочие области):


Изображение117

В некоторых случаях может быть полезным назначение хоткеев для перемещёния окон в подпункте Размещёние пункта Окна — в правый верхний угол, левый верхний угол, и так далее (по умолчанию не включены):


Изображение118

Такие перемещёния не следует путать с управлением тайлингом — размер окна при этом не меняется. А собственно настройки управления тайлингом выполняются в том же пункте Окна — соответствующий подпункт так и называется, Tiling and Snapping. Именно здесь можно изменить умолчальные комбинации типа Super плюс стрелки, описанные в предыдущем очерке:


Изображение119

В пункте Общие (он идёт первым в списке) можно перенастроить переходы в режим Expo и масштабирования:


Изображение120

Раньше здесь же можно было лишить клавишу Super_L (она же — левая win-клавиша) её сакрального значения — вызова меню. В версии 2.4 эта возможность пропала, но кто знает? Может, появится снова. Ведь Cinnamon — не Unity, где всё на супер-клавишу завязано, так что нет смысла трястись над этой священной коровой.

В мои цели не входит описывать все действия, для которых можно определить комбинации. Но думаю, что и сказанного достаточно для иллюстрации факта: перед любителями оперировать хоткеями открывается очень широкое поле деятельности.

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

Раскладки и переключатели

Настройка раскладок клавиатуры и переключателей между ними может быть не актуальной для тех применителей, которых устраивают умолчания инсталлятора — вариант winkeys для русской раскладки и комбинация Alt+Shift в качестве переключателя раскладок:


Изображение121

Но для требовательных применителей-текстовиков здесь есть все возможности не изменять своим привычкам, а заодно и приобрести новые, полезные.

Перво-наперво следует определиться, использовать ли одинаковую раскладку во всех окнах, или в каждом — свою, что делается отметкой одной из соответствующих радиокнопок (см. предыдущий скриншот). А во втором случае — решить, будет ли раскладка нового окна наследоваться от таковой окна предыдущего, или же от умолчальной раскладки, той, что стоит в списке первой (на самом деле это тоже раскладка окна — так называемого корневого окна Иксов).

До некоторого времени наследование раскладки в Cinnamonm работало произвольным образом. В версии 2.4 это изжито, и при включении последней опции раскладка в новом окне действительно будет умолчальной. За единственным, отмеченным ранее, исключением: в строке инкременетного поиска главного меню среды раскладка почему-то всегда наследуется от текущей.

Далее переходим к выбору варианта русской раскладки. Список их включает все обычные варианты, немало экзотических и несколько национальных:


Изображение122

В случае сомнений раскладку можно, с помощью кнопки Предпросмотр, поглядеть на экране:


Изображение123

Я, ввиду большого стажа ремингтониста (это — мужской вариант професси машинистки), предпочитаю вариант Typewriter Legacy, обзываемый по русски печатная машинка, устаревшая. Вдаваться в обоснования этого выбора и тем более агитировать за него здесь неуместно. Заинтересованных отсылаю к специальному материалу.

Из прочих вариантов интересен вот этот: Русский (Польша, фонетический Дворак). Чего там осталось от раскладки профессора Дворака — разве что то, что это и близко не QWERTY. Но расположение алфавитно-цифровых символов и знаков препинания на ней выглядит вполне разумным:


Изображение124

Правда, есть большие сомнения в том, что эта разумность стоит полного переучивания.

Нет напряга и с переключателями раскладок — они входят в число параметров, вызываемых, как ни странно, кнопкой Параметры:


Изображение125

Легко догадаться, что переключение настраивается в пункте Переключение на другую раскладку, и в нём можно найти переключатель на любой вкус:


Изображение126

Имеются и немодальные переключатели — это своего рода заменители корректоров ввода при «неправильной» раскладке, примером которых в Linux’е выступает программа X Neural Switcher (точнее, в Иксах, ибо работает также и в любых BSD-системах). Ибо из применителей может сказать, положа руку на сердце и поклявшись на своём Священном Писании, что он никогда, никогда, никогда… не забывал переключать раскладку клавиатуры с латиницы на кириллицу (или наоборот)?

Достоинства и недостатки XNeur обсуждались многократно, поэтому повторю только главный из последних: эта утилита принадлежит к тем, которые полагают себя умнее своих создателей (и, тем более, применителей), и потому часто автоматика его срабатывает прозвольным образом. Конечно, он имеет и «ручной» режим работы, но его использрвание очень узко: если вовремя заметить, что в «не той» раскладке набрано одно слово или его кусок, обычно проще и быстрей тут же перенабрать его, нежели выделять кусок текста и заказывать для него перекодирование.

Тем более, что «проблему забывчивости» применительно к переключению раскладок можно попытаться решить другим способом — я бы назвал его «кембриджским». Как известно, в Оксфордском университете, воспитывавшем английских джентльменов, учили мыть руки после туалета. А в более прагматичном Кембридже, давшем миру немало естествоиспытателей, учили не справлять малую нужду на руки. Первому алгоритму следует программа XNeur, второй же можно реализовать, сведя к минимуму вероятность забывчивости при наборе. Чему очень поспособствуют те самые немодальные (или нециклические) переключатели раскладок.

Суть немодальных переключателей в том, что они ничего не переключают, а включают. То есть одна определённая клавиша (или их комбинация) всегда включает английскую раскладку, а другая делает то же самое для раскладки русской. И в использовании их есть только одна проблема — привыкание. То есть нужно отучиться смотреть на индикаторы раскладки. Нужно забыть о том:

  • какая раскладка является текущей;

  • какая раскладка является умолчальной;

  • от кого наследуется раскладка нового окна — от корневого окна (то есть повторяет умолчальную) или от окна текущего.

А помнить нужно только одно: перед вводом любого кириллического текста нажать, скажем, комбинацию Shift+CapsLock, а переходя к вводу латиницы — клавишу CapsLock. Подобно тому, как при вводе прописной буквы мы автоматически нажимаем Shift, не задумываясь особо о причинах этого.

Немодальных переключателей предлагается довольно много:


Изображение127

Далее, чтобы побороть забывчивость при переключении раскладок, надо переключать их как можно реже. И на сей предмет придуманы временные переключатели, действующие, пока нажата определённая клавиша — в частности, они совершенно незаменимы при вводе типографских символов с использованием клавиши Compose, о чём я скажу чуть позже. Причём они не исключают использования любых постоянных переключателей, как модальных, так и немодальных.

Традиционно в качестве временного переключателя используется правая клавиша Control, но и тут выбор достаточно велик:


Изображение128

А вообще все возможные переключатели раскладок, модальные, немодальные и временные, можно посмотреть в файле /usr/share/X11/xkb/rules/evdev.lst — в секции ! option, где они перечислены в строках, начинающихся с grp:

! option

  grp                  Switching to another layout

  grp:switch           Right Alt (while pressed)

  grp:lswitch          Left Alt (while pressed)

  grp:lwin_switch      Left Win (while pressed)

  grp:rwin_switch      Right Win (while pressed)

  grp:win_switch       Any Win key (while pressed)

  grp:caps_switch      Caps Lock (while pressed), Alt+Caps Lock does the original capslock action

  grp:rctrl_switch     Right Ctrl (while pressed)

  grp:toggle           Right Alt

  grp:lalt_toggle      Left Alt

  grp:caps_toggle      Caps Lock

  grp:shift_caps_toggle Shift+Caps Lock

  grp:shift_caps_switch Caps Lock (to first layout), Shift+Caps Lock (to last layout)

  grp:win_menu_switch  Left Win (to first layout), Right Win/Menu (to last layout)

  grp:lctrl_rctrl_switch Left Ctrl (to first layout), Right Ctrl (to last layout)

  grp:alt_caps_toggle  Alt+Caps Lock

  grp:shifts_toggle    Both Shift keys together

  grp:alts_toggle      Both Alt keys together

  grp:ctrls_toggle     Both Ctrl keys together

  grp:ctrl_shift_toggle Ctrl+Shift

  grp:lctrl_lshift_toggle Left Ctrl+Left Shift

  grp:rctrl_rshift_toggle Right Ctrl+Right Shift

  grp:ctrl_alt_toggle  Alt+Ctrl

  grp:alt_shift_toggle Alt+Shift

  grp:lalt_lshift_toggle Left Alt+Left Shift

  grp:alt_space_toggle Alt+Space

  grp:menu_toggle      Menu

  grp:lwin_toggle      Left Win

  grp:rwin_toggle      Right Win

  grp:lshift_toggle    Left Shift

  grp:rshift_toggle    Right Shift

  grp:lctrl_toggle     Left Ctrl

  grp:rctrl_toggle     Right Ctrl

  grp:sclk_toggle      Scroll Lock

  grp:lctrl_lwin_rctrl_menu LeftCtrl+LeftWin (to first layout), RightCtrl+Menu (to second layout)

Руководствуясь этим списком, переключатели раскладок (в числе прочих параметров) можно изменить и через Редактор dconf, о котором со временем пойдёт речь.

Кроме того, настройкой переключателей параметры клавиатуры не исчерпываются. Например, на десктопах резонно Использовать клавиатурные индикаторы для отображения дополнительных раскладок:


Изображение129

В ряде случаев полезно в Разных параметрах совместимости установить опцию С клавиш цифровой клавиатуры всегда вводятся цифры — вне зависимости от настроек BIOS и общесистемных:


Изображение130

И, наконец, сакраментальный вопрос о вводе типографских символов. Хотя уже давно, как заметил Brego,

…данная задача решается не просто и даже не очень просто, а примитивно.

А именно — так. Для начала поддержку ввода типографских символов следует включить — это делается в тех же Разных параметрах совместимости (см. предыдущий скриншот).

Далее нужно определить Положение клавиши Compose — она служит для переключения в режим ввода единичного типографского символа. Список вариантов тут более чем обширен:


Изображение131

И последнее, но самое главное: затвердить, как символ веры (своей, разумеется) список кейбиндов для типографских символов. Если и не полный, который можно найти в файле /usr/share/X11/locale/en_US.UTF-8/Compose, то хотя бы суперминималистический, образуемый с помощью Compose плюс:

—.         —       en dash

—         —       em dash

spb spb     nbsp    неразрывный пробел

<<          «       открывающая кавычка >>          »       закрывающая кавычка

..          …       многоточие

oo          °       градус

+-          ±       плюс-минус

oc          ©       копирайт

^2          ²       в квадрате

12          ½       одна вторая

Набор любой степени — Compose ^ #

где # — нужная степень

Набор (почти) любой дроби — Compose  x y

где x — числитель, y — знаменатель

Правда, правила для набора дробей имеют исключения. Так, в моей системе не выводятся все дроби, содержащие цифру 7, что в числителе, что в знаменателе. За единственным исключением — дробь ⅞ почему-то пропечатывалась. Не печатаются также и дроби с цифрой 9, в том числе и бессмысленные, тип 3/9 и 9/3. Причём девятка не проходит ни в каких сочетаниях, и ни в какой позиции, без всяких, в отличие от семёрки, исключений.

Да, ещё самое распоследнее: следует помнить, что ввод типографики после Compose работает только при латинской раскладке клавиатуры. И вот тут-то самое время вспомнить о временных, или «удержальных», переключателях — при некотором навыке они здорово упрощают ввод типографики.

Мышь и сенсорная панель

О настройках мыши мало что можно сказать. Разве что рассмотреть скриншот и решить, что следует здесь поменять — и следует ли что-то менять вообще. Для меня оказалась полезной опция Показывать позицию указателя при нажатии клавиши Ctrl — способствует отысканию курсора, если он затерялся в океане безбрежного широкоформатного монитора:


Изображение132

А вот настройка сенсорной панели — очень существенный момент при работе на ноутбуке. Хотя на своей Ноутбучке я ограничился переключением режима прокрутки — водить по ней двумя пальцами мне удобней, чем елозить одним по краю:


Изображение133

Но, как хвастаются разработчики (и как видно на скриншоте), в Cinnamon 2.4 появилась поддержка «однокнопочных» тачпадов — от Macbook’ов этой модой заразились и производители некоторых «обычных» ноутбуков. Действительно, опции, имеющие к этому отношение, присутствуют. Но что они делают и как работают — проверить не смог, ибо моя Ноутбучка имеет две натуральные, традиционно ориентированные, кнопки.

Раз уж речь зашла о ноутбуках, добавлю тут же пару слов про модуль Управление питанием. Я этим вопросом особенно не заморачиваюсь, ограничиваясь отключением всего того энергосбережения, которое можно отключить:


Изображение134

А с прочими опциями предлагаю разбираться заинтересованным лицам. Как и с модулем Bluetooth, поскольку соответствующие устройства я не использую.

Звук

С настройками звука дело теоретически обстоит так: запустив соответствующий модуль, можно для начала определить устройство воспроизведения оного. У меня таковым по умолчанию выставляется HDMI, по которому подключён монитор со встроенными колонками. Ни малейшего звука при этом не воспроизводится — он начинает звучать только при переключении на аналоговый выход (S/PDIF у меня нет):


Изображение135

После чего остаётся проверить звучание — с неизменно превосходным результатом:


Изображение136

И слушать музыку или смотреть кино со звуковым сопровождением — штатными ли средствами Mint (Banshee и Totem, соответственно) или через более привычный мне Mplayer.

Принтеры и цвет

В секции Оборудование остались неохваченными вниманием два модуля — и описание обоих вполне уместится на одну страницу. Обратившись у пункту Принтеры, я увидел, что у меня нет настроенных принтеров:


Изображение137

Поскольку физически у меня имелось МФУ DeskJet 2050, я нажал кнопку Добавить — и увидел, что такое действительно имеет место быть:


Изображение138

Оставалось его настроить — для чего была нажата кнопка Вперёд, после чего было выведено некое умолчальное описание принтера:


Изображение139

Его можно подкорректировать, но я этого делать не стал. А нажал кнопку Применить, через несколько секунд, ушедших на поиск драйверов, получил предложение напечатать пробную страницу:


Изображение140

Вслед за чем оказалось, что принтер волшебным образом у меня появился:


Изображение141

И свойства его оказались таковы:


Изображение142

Надо сказать, что всё это потребовалось только потому, что при инсталляции Mint 17.1 Rebecca с нуля я не включил принтер. Иначе всё было бы автоматически установлено посредством HPLIP (HP Linux Imaging and Printing). Именно так было у меня при установке Mint 17 Qiana — ни малейших усилий по настройке принтера я тогда не прикладывал. Но, когда он мне понадобился впервые (а принтер мне требуется максимум раз в квартал), обнаружил, что он есть и готов к работе.

Кстати, в обоих случаях моё МФУ, в соответствие со своим многофункциональным титулом, способно и сканировать — причём опять-таки без всяких настроечных действий. Что, впрочем, к нынешней теме не относится. Да и ставить это надо в заслугу не Cinnamon, и даже не Mint, а фирме HP и разработчикам системы HPLIP. Вот уже в который раз и на котором дистрибутиве я убеждаюсь, что HPLIP полностью избавил применителя от забот о настройке печати и сканирования. Правда, только счастливого обладателя продукции HP.

И, наконец, последний модуль секции носит имя Цвет, а суть его заключается в калибровке цветов монитора и принтера. Поскольку я в этом ничего не понимаю и ни малейшей потребности понимать не испытываю, ограничусь скриншотом:


Изображение143

А уж кому нужно или интересно — делайте с ним что хотите.

Секция Администрирование

Наступает волнующий момент — среди штатных настроек Cinnamon’а осталась одна секция —Администрирование, а в ней — четыре модуля:

  • Источники приложений;

  • Менеджер драйверов;

  • Окно входа в систему;

  • Пользователи и группы.

Первые два модуля прямого отношения к Cinnamon не имеют, а принадлежат к кругу фирменных утилит Mint, которые будут предметом соответствующего очерка. Так что в очерке этом будут рассмотрены два последних.

Окно входа в систему

Строго говоря этот модуль тоже не часть среды Cinnamon, а является инструментом настройки дисплейного менеджера MDM (изначально аббревиатура Mint Display Manager, ныне превратившаяся в рекурсивное MDM Display Manager), обеспечивающего во всех редакциях дистрибутива Mint авторизацию в системе. Однако он очень тесно интегрирован в Системные настройки, в том числе и в отношении внешнего вида, и потому его целесообразно рассмотреть здесь.

Поскольку авторизация в системе выходит за пределы компетенции отдельного пользователя, при запуске этого модуля (из CLI его можно запустить командой sudo mdmsetup) для начала запрашивается пароль, после ввода которого появляется такая панель:


Изображение144

С пунктом Тема всё понятно — это выбор заставки, на фоне которой выводится окно авторизации, а также, при желании, определение собственного приветствия:


Изображение145

Далее можно задать автоматический вход в систему для определённого пользователя, и установить задержку перед входом, позволяющую выбрать сеанс:


Изображение146

Сеанс по умолчанию задаётся в пункте Настройки:


Изображение147

Здесь же есть вожделенная для начинающих линуксоидов опция — разрешение авторизоваться в иксовом сеансе в качестве суперпользователя. Что, конечно, круто, но делать не рекомендуется, за исключением единичных ну очень специальных случаев.

Пользователи и группы

А вот модуль Пользователи и группы — родной для Cinnamon, из CLI его можно запустить командой cinnamon-settings-users. Очевидно, что и здесь потребуется пароль, ввод которого даст доступ к святая святых — списку пользователей и групп:


Изображение148


Изображение149

От описания возможных тут действий в каждом аккаунте позволю себе воздержаться — они почти очевидны из скриншота и становятся более чем очевидными после пары щелчков мышью. А вот о том, как создаётся новый пользовательский аккаунт, скажу чуть подробнее.

Собственно, для создания аккаунта достаточно заполнить простую форму, выбрав в ней тип учётной записи:


Изображение150

Тут возможно два варианта — Администратор и Стандартный. Второй выводится по умолчанию — и пусть таковым остаётся (почему — скажу чуть позже). Так что теперь достаточно нажать кнопку Добавить, чтобы новый пользователь появился в списке оных:


Изображение151

Обращаю внимание, что пароль в ходе создания нового аккаунта не запрашивается. Его можно установить здесь же, щёлкнув на поле Пароль:


Изображение152

Впрочем, я по ряду причин предпочитаю делать это из CLI командой

$ sudo passwd username

Только после этого надо не забыть исключить пользователя из группы nopasswdlogin, членство в которой даёт возможность беспарольного входа в систему, что не есть правильно. Для этого достаточно щёлкнуть мышью на поле Группы и снять отметку с соответствующего боксика:


Изображение153

Здесь, во-первых, надо подчеркнуть, что беспарольный вход в систему — это совсем не то же самое, что автоматический вход, о котором говорилось выше: во-втором случае пароль пользователя существует, просто его не нужно вводить в окошке MDM (это, в соответствие с названием, делается автоматически, за кадром). А вот при авторизации в консоли этому самому «автоматическому» пользователю пароль вводить придётся. Как и при запуске программ, требующих прав администратора. И, чтобы ни говорили записные параноики, с точки зрения безопасности на локальной машине, находящейся в индивидуальном пользовании, автоматический вход ничем не отличается от парольного.

Во-вторых, поясняю, в чём отличие административного типа учётной записи от стандартного: только пользователь с аккаунтом первого типа имеет возможность получить доступ к административным привилегиям с помощью команды sudo. Административный статус автоматически присваивается тому пользователю, чей аккаунт был создан при инсталляции системы. Так что для всех остальных аккаунтов достаточно статуса стандартного. Ибо зачем нам два генеральных секретаря? — резонно говорил незабвенный Леонид Ильич (правда, не в жизни, а в анекдоте)

И в-третьих, может возникнуть вопрос, зачем на индивидуальной машине несколько аккаунтов? Причины могут быть разные, скажу только за себя. Мой первый и главный аккаунт, alv, предназначен для меня, любимого, когда он занят выполнением своей непосредственной работы. Например, сочинением этой книжки.

Никаких потенциально опасных действий я под основным аккаунтом не делаю (или стараюсь не делать). Для всякого рода экспериментов предназначен аккаунт exp, пользователь которого не имеет доступа к правам администратора и потому напортачить на системном уровне не может — в его власти только развалить собственные пользовательские настройки. Поскольку такое рано или поздно случается — на помощь приходит аккаунт def, в котором сохраняются все настройки по умолчанию. И из которого настройки несчастного exp можно восстановить до исходного состояния простым копированием конфигов.

На этом разговор о настройках Mint совместно с Cinnamon можно считать законченным. Следующий очерк имеет отношение только к Mint, так как посвящён «фирменному» иснтсрументарию этого дистрибутива — и не только имеющему отношение к настройкам.

Mint: фирменный инструментарий

Редкий дистрибутив из числа тех, что носят это гордое имя по праву, не обзаводится более или менее полным набором системного инструментария, специфичного только для него (в дальнейшем я буду называть такие инструменты фирменными). Не исключение в этом отношении и Mint — он имеет набор фирменных инструментов для решения весьма широкого круга задач, от управления программным обеспечением до настройки WiFi и блокировки доменов. Они и будут предметом данного очерка.

Вступление

Как уже было сказано, фирменный инструментарий дистрибутива Mint охватывает весьма широкий круг задач и потому представлен большим количеством отдельных утилит, которые обнаруживаются в любой из его редакций, располагаясь в каталоге /usr/bin. Полный их список включает более 20 исполняемых файлов вида mint*. Большинству из них соответствует пункт в разделе Администрирование главного меню Cinnamon:


Изображение154

Фирменные инструменты Mint будут рассмотрены на примере среды Cinnamon. Однако десктопная специфика касается только способа их запуска из главного меню. Сами же инструменты идентичны во всех редакциях дистрибутива Mint.

Рассмотрение фирменного инструментария целесообразно начать с менеджера программ, как наиболее востребованного его компонента.

Менеджер программ mintinstall

Менеджер программ mintinstall занимает центральное положение в наборе фирменного инструментария дистрибутива Mint. Он принадлежит к классу самых «высокоуровневых» инструментов для управления пакетами, которые можно назвать интегрированными центрами приложений, о чём подробнее будет сказано в одном из последующих очерков.

Как только что было сказано, mintinstall можно запустить одноимённой командой из терминального окна или строки минитерминала. А можно обратиться к главному меню Cinnamon, где он обнаруживается в разделе Администрирование. Однако залезать в него не обязательно — пиктограмма запуска Менеджера приложений вынесена в левую колонку быстрого запуска второй сверху:


Изображение155

Будучи запущенным тем или иным способом, mintinstall для начала запрашивает пароль пользователя, после чего предстаёт перед его взором в следующем виде:


Изображение156

Первое, что обращает на себя внимание — минималистичный дизайн: никаких баннеров, новинок, рекомендаций. Только поле поискового запроса, пиктограммы категорий софта и строка состояния текущих действий (сразу после запуска, разумеется, пустая). И потому mintinstall не вызывает визуального отторжения.

В обращении mintinstall столь же прост, как и внешне. А обращение с ним, разумеется, начинается с поиска нужного пакета. Сделать это можно, во-первых, просматривая категории, например Офис:


Изображение157

Однако это не самый простой путь. Во-первых, просматривать списки категорий (а они включают в себя от пары сотен до 4-5 тысяч позиций) — не самое весёлое занятие. Во-вторых, оно осложняется ещё и тем, что пакеты в этих списках отсортированы не по алфавиту, а по количеству полученных отзывов. В-третьих, критерии отнесения пакета к той или иной категории не всегда понятны. Так, категория Офис включает в себя не только собственно офисные пакеты, но и, скажем, текстовые редакторы, в том числе и такие, которые обычно относятся к классу системных приложений, например, vim и nano, и даже к инструментам программирования, вроде текстового редактора Geany, в некоторых кругах именуемого интегрированной средой разработки (IDE).

Впрочем, Geany мы не увидим ни в категории Офис , ни в категории Программирование. Ибо, и это в четвёртых, есть ещё и категория Избранное, куда попадают пакеты с наибольшим количеством отзывов в своих «законных» категориях. Именно к этой категории и удостоился чести быть причисленным Geany, имеющий на момент сочинения этих строк 473 отзыва:


Изображение158

Поэтому, если известно имя пакета (или хотя бы фрагмент имени), проще воспользоваться полем поискового запроса. Таким образом пакет Geany находится мгновенно — а если после его нахождения нажать кнопку Показать все результаты, то будет выведен и список всех его плагинов:


Изображение159

По умолчанию поиск в mintinstall простой, но его легко сделать инкрементным (как — скажу чуть позже). И тогда с каждым набранным символом список соответствий сокращается. Например, при поиске пакета Shutter, предназначенного для изготовления скриншотов (иллюстрации ко всем заметкам сделаны именно им), это выглядит так:


Изображение160

Нужно только учитывать, что порядок вывода пакетов — не по соответствию имени введённым в поле поиска символам, а опять же по количеству отзывов.

Впрочем, по умолчанию поиск осуществляется по соответствию не только имени пакета, но также и кратким описаниям, которые могут быть даже на русском языке. Это можно видеть на примере поиска пакета aisleriot, представляющего собой коллекцию пасьянсов:


Изображение161

Следует помнить, что поиск — регистро-зависимый. Это можно продемонстрировать на примере поиска пакетов выпадающих терминалов. Если в поле поиска ввести слово Выпадающий, мы увидим пакет выпадающего терминала Guake:


Изображение162

А по ключевому слову выпадающий обнаружится совсем другой выпадающий терминал, Tilda:


Изображение163

Если дважды кликнуть на строке с именем найденного пакета, появится страница с его описанием. Нередко оно будет на русском языке, и может содержать картинки:


Изображение164

Картинки кликабельны, так что их можно вывести «крупным планом»:


Изображение165

Здесь же можно прочитать и отзывы о пакете, если таковые имеются:


Изображение166

А можно также и оставить свой отзыв. Правда, для этого надо предварительно зарегистрироваться в сообществе пользователей (как — расскажу позже).

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

Столь же молчаливо будут установлены и все необходимые зависимости, поэтому с их списком лучше ознакомиться заранее. Например, для игры blockout2 он выглядит так:


Изображение167

После установки пакета на его странице появляется кнопка Удалить очевидного назначения, которое также претворяется в жизнь без всяких вопросов. Нужно только учитывать, что пакеты, установленные как зависимости удаляемого, удалены не будут, их придётся вычищать или по списку по списку из раздела Подробности, или другими средствами. Первый вариант — рискованный, так как при этом можно затронуть зависимости других пакетов. Второй же лежит вне темы данного очерка — о нём будет говориться в своё время. Так что для удаления пакетов Менеджером программ лучше просто не пользоваться, за исключением очень простых или хорошо известных применителю случаев.

Кроме строки поиска, mintinstall имеет ещё и меню. Где в пункте Вид определяется, выводить ли Доступные приложения, Установленные приложения, или, как по умолчанию, те и другие:


Изображение168

В пункте Правка — три подпункта: Настройки поиска, Доступ к аккаунту в сообществе и Источники приложений:


Изображение169

В первом из них, во-первых, определяется, искать ли только в кратких описаниях пакетов (отмечено по умолчанию) или также в подробных, а во-вторых — включить инкрементный поиск (Поиск при вводе):


Изображение170

Про аккаунт в сообществе Linuxmint я расскажу в маленькой интермедии. А пункт Источники приложений вызывает отдельную утилиту software-sources, которая будет рассмотрена последующем за ней очерке.

Интермедия об аккаунте в сообществе

Как мы только что видели, для того, чтобы оставить отзыв о пакете в Менеджере программ, необходимо открыть аккаунт в сообществе Linux Mint. Для этого надо пройти к пункту меню Правка -> Ваш аккаунт, который вызовет панель с предложением к авторизации:


Изображение171

Нетрудно догадаться, что если аккаунта ещё нет — следует пойти по указанному там адресу. После чего приглашение к авторизации откроется уже в браузере:


Изображение172

Кнопка Register находится на видном месте. Нажав её, можно видеть регистрационную форму:


Изображение173

Заполнение полей — очевидно, кроме последнего, Registration Code. Чтобы получить его, нужно открыть тот самый экран приветствия, который был виден при первом запуске свежеинсталлированного Mint’а. И показ которого, скорее всего, был тогда же и отключён. Однако его можно вызвать в любой момент — это такой же компонент фирменного инструментария, как и все остальные из рассматриваемых в этом очерке. Делается это либо из терминала вводом команды

$ mintwelcome

либо через главное меню Параметры -> Экран приветствия:


Изображение174

Теперь остаётся только найти пиктограмму с подписью Чат-комната, в эту самую комнату войти и в свободной (но желательно вежливой) форме на английском языке запросить код для регистрации. Практически мгновенно от пользователя mintbotd придёт ответ, гласящий, что код выслан в личном сообщении. Откуда он и вставляется в регистрационную форму, после чего регистрация мгновенно совершается.

Теперь можно вернуться к форме, вызванной из Менеджера программ, авторизоваться там и оставлять отзывы в своё удовольствие. Причём устанавливать программу, на которую даётся отзыв, совсем не обязательно. А вот оценку ей надо дать непременно.

Разумеется, аккаунт в сообществе нужен не только для того, чтобы оставлять отзывы на пакетах. Будучи членом сообщества, можно получать доступ к тому, что создаёт его мозг (Клемент Лефевр) на ранних стадиях разработки. И даже поучаствовать в тестировании.

Менеджер репозиториев software-sources

А теперь вернёмся в Менеджер программ с другой целью — проследовать в пункт его меню Правка -> Источники приложений. Через него вызывается самостоятельная утилита фирменного набора, mintsources, она же software-sources (первое имя — символическая ссылка на второе). В разделе Администрирование главного меню ей соответствует пункт Источники приложений (это и есть официальное название программы, менеджер репозиториев — моя отсебятина, придуманная единообразия ради). Наконец, плюс к упомянутой возможности вызова software-sources из Менеджера программ, пиктограмма запуска её есть и в секции Администрирование Системных настроек Cinnamon.

Вне зависимости от способа запуска, после ввода пароля открывается окно software-sources с пятью страницами, переключение между которыми осуществляется экранными кнопками. На первой странице, именуемой Официальные репозитории, выбираются зеркала двух основных репозиториев — собственного и репозитория Ubuntu (вся базовая часть Mint берётся из последнего). Здесь же отмечается, следует ли использовать бэкпорты, нестабильные пакеты, а также исходники:


Изображение175

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


Изображение176


Изображение177

Использование «обратно портированных» (backport) и нестабильных (romeo) пакетов разработчиками настоятельно не рекомендуется, и по умолчанию эти ветви репозиториев отключены. Попытка активировать любую из них вызывает предупреждение, для бэкпортов такое:


Изображение178

А для нестабильных пакетов — такое:


Изображение179

Не вижу оснований не прислушаться к этим предупреждениям — в любом случае, и к бэкпортам, и к нестабильным пакетам следует подходить индивидуально, а не устанавливать их все гуртом.

Отключено также использование ветки репозитория, содержащей исходные тексты пакетов. Активация её не несёт никакой опасности, и потому не сопровождается предупреждением. Просто доступ к исходникам нужен далеко не всем применителям, а лишь тем, кто пересобирает пакеты с каким-либо своими специфическими опциями.

Вторая страница — PPA-репозитории, то есть дополнительные PPA-репозитории из централизованного хранилища всех пакетов, собранных независимыми разработчиками и майнтайнерами:


Изображение180

PPA-репозитории предназначены для Ubuntu и её прямых родственников (вроде Kubuntu и Xubuntu). Но, поскольку Mint с Ubuntu полностью обратно совместим, пакеты эти обычно (если не вообще всегда) можно использовать и в нём. По крайней мере, я не только не сталкивался с какими-либо проблемами, но и не слышал о таковых. Для доступа к PPA-репозиториям фирма Canonical разработала специальную систему с web-интерфейсом — Launchpad.

Для подключения дополнительного репозитория его сначала нужно отыскать на Launchpad’е и определить его ppa-имя. Например, для PPA-репозитория с пакетами поддержки файловой системы ZFS оно будет таким: ppa:zfs-native/stable. Затем кнопкой Добавить новый… вызывается панель, в соответствующее поле которой это имя вписывается:


Изображение181

Нажатие кнопки OK вызывает панель с информацией о репозитории:


Изображение182

И после подтверждения своих намерений новый репозиторий появляется в общем списке.

В большинстве случаев при подключении PPA-репозиториев автоматически подключаются и их ветки с исходниками (в русском переводе почему-то называемые Источниками) .

На странице Дополнительные репозитории аналогичную процедуру можно выполнить для репозиториев произвольных, в том числе и локальных:


Изображение183

Страница Проверка подлинности ключей предназначена для хранения ключей к подключённым репозиториям — в большинстве случаев они вносятся в список автоматически:


Изображение184

Наконец, на странице Maintenance можно произвести исправление проблем с локальными кешами пакетов, буде таковые возникнут (у меня пока не возникало) и их очистку от продуктов жизнедеятельности при установке пакетов:


Изображение185

В правом верхнем углу окна программы можно видеть кнопку Обновить кэш. К ней следует обращаться после любых действий с репозиториями — это приведёт локальный кэш пакетов в актуальное состояние.

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

Менеджер обновлений mintupdate

После рассмотрения Менеджера программ и Менеджера репозиториев резонно перейти к средствам, обеспечивающим обновление системы. Таковым в фирменном наборе инструментов Mint является Менеджер обновленийmintupdate. По умолчанию он включается в автозапуск, и потому применителю не нужно беспокоиться о его запуске: пиктограмма его сидит в трее, изменяя свой вид в зависимости от доступности обновлений: в виде буковки i на голубом фоне в случае их наличия, и в виде зелёной «галочки» — если система обновлений не требует. Соответствующие подсказки всплывают и при наведении курсора мыши на пиктограмму:


Изображение186


Изображение187

При доступности обновлений получить визуальное представление о них можно, щёлкнув мышью на пиктограмме. После этого будет выведен список пакетов, которые могут быть обновлены в данный момент времени:


Изображение188

Строго говоря, начиная с Mint 17.1, вывод не совсем попакетный: в одной строке списка может быть сгруппировано несколько родственных пакетов, которые друг без друга всё равно не устанавливаются, например — cinnamon и cinnamon-common. Эту группировку не следует путать ни с зависимостями, ни с метапакетами — она делается исключительно для компактности представления и лёгкости восприятия.

Далее, некоторых пояснений требуют первые две колонки. Первая — тип обновления. Их два — стандартно обновляемые пакеты по выходе их новой сборки или версии (отмечены серой стрелкой) и обновления безопасности, ликвидирующие выявленные «дыры» в них (отмечены красным восклицательным знаком).

Во второй колонке указывается уровень безопасности обновления пакетов. Здесь под безопасностью понимается не вероятность использования их злодеями, а то, как обновление пакета может повлиять на общую стабильность системы. Уровней безопасности в этом смысле пять:

  1. сертифицированные пакеты — обычно те, что непосредственно поддерживаются майнтайнерами Mint;

  2. рекомендуемые пакеты — проверены и одобрены разработчиками этого дистрибутива;

  3. безопасные пакеты — не проверялись разработчиками, но нарушение стабильности системы при их обновлении очень маловероятно;

  4. небезопасные пакеты потенциально могут повлиять на стабильность системы;

  5. опасные пакеты при некоторых условиях могут привести к нестабильности системы.

Забегая вперёд, приведу скриншот окна настройки параметров Менеджера обновлений, наглядно иллюстрирующий сказанное:


Изображение189

По умолчанию для обновления (третья колонка) отмечаются пакеты уровней 1-3. Для пакетов уровней 4-5 это нужно сделать принудительно. Если оно, конечно, нужно. Разработчики Mint считают, что решение об обновлении таких ключевых пакетов, как ядро, главная системная библиотека glibc и так далее, применитель должен принимать осознанно. Характерно, что режима автоматического обновления в Mint не предусмотрено как класса.

Само по себе обновление выполняется нажатием экранной кнопки Установить обновления и начинается после ввода пользовательского пароля. Развернув пункт Show individual files, можно наблюдать за ходом процесса в деталях (если, конечно, больше заняться нечем):


Изображение190

По завершении процесса окно обновлений предлагается закрыть:


Изображение191

Как я уже говорил, Mint не предлагает автоматического обновления пакетов — Менеджер обновлений нужно запустить руками, или описанным выше способом, или из контекстного меню по щелчку правой кнопкой мыши на его пиктограмме в системной трее:


Изображение192

Из него же можно получить доступ к настройкам mintupdate (пункт Параметры), о которых я скажу чуть позже, и к журналу обновлений (пункт Информация):


Изображение193

Меню менеджера обновлений не дублирует кнопки на его панели инструментов. Через пункт меню Файл можно выйти из программы. Пункт Правка содержит подпункты Параметры — это настройка политики обновлений, до чего я скоро доберусь, и Источники приложений — это вызов того самого software-sources, о котором шла речь в предыдущем разделе. А в пункте Вид можно, во-первых, включить или отключить вывод каких-то колонок:


Изображение194

Во-вторых, можно просмотреть историю обновлений:


Изображение195

И в-третьих, можно получить информацию об установленном ядре и доступных для обновления версиях:


Изображение196

Что такое Информация — я только что говорил. Так что можно вернуться в пункт Правка, где обратиться к подпункту Параметры. Скриншот первой вкладки вызываемого при этом окна я уже приводил, когда говорил об уровнях безопасности. Осталось только добавить, что здесь для пакетов 4-го и 5-го уровней можно включить отметку к обновлению «на постоянной основе». А можно сделать это для всех пакетов, обновляемых по типу обновления безопасности (другой, той, которая от злодеев).

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


Изображение197

Со вкладками Метод обновления и Игнорируемые пакеты всё понятно без комментариев:


Изображение198


Изображение199

Вкладка Значки — это своего рода легенда (то есть условные обозначения): как выглядит пиктограмма Менеджера обновлений в зависимости от состояния системы и выполняемых им действий:


Изображение200

Как и всякие условные обозначения, каждое из представлений пиктограммы можно изменить (только нужно ли?).

На этом разговор о Менеджере обновлений считаю законченным. Следующим номером нашей программы будет рассказ о визуализаторах вывода.

Средства визуализация пакетов

В качестве завершающего штриха в рассказе о mint-инструментах для работы с файлами скажу пару слов об утилитах mint-search-apt и mint-show-apt. Они предназначены для визуального представления результатов поиска пакетов и вывода информации о них. В сущности, это графические фронт-энды для вывода команд CLI apt search и apt show, соответственно (о которых будет в другом очерке). Подчеркну — именно вывода: сами эти утилиты запускаются из командной строки терминала или из минитерминала.

Команда mint-search-apt в качестве аргумента принимает имя пакета или его фрагмент: поиск введённой последовательности символов осуществляется только в именах пакетов. После чего результат поиска выводится во вновь открывающемся окне. Например, ответ на команду

$ mint-search-apt geany

будет таким:


Изображение201

Теоретически двойной клик на имени найденного пакета должен привести к его инсталляции. Однако в реальности последует лишь сообщение об ошибке:


Изображение202

Утилита apt-cache show в качестве аргумента требует имени пакета, после чего в отдельном окне выводит информацию о нём. Например, после команды

$ mint-show-apt geany

оно будет выглядеть следующим образом:


Изображение203

Обе рассматриваемые утилиты входят в пакет mintinstall, который был разработан задолго до появления интегрированной команды apt, о которой будет говориться в очерке про пакетный менеджмент. И в те не столь далёкие времена их применение было оправдано. Ныне же, как мне кажется, использование их большого смысла не имеет. Хотя кому-то, может, и понравится вывод найденных пакетов и информации о них в графическом окне. Почему я и уделил им немного внимания.

Этой заметкой завершается описание фирменных утилит Mint’а, так или иначе связанных с управлением пакетами. Следующий раздел — о резервном копировании.

Средство резервного копирования mintbackup

От средств работы с пакетами плавно переходим к средствам работы с файлами. А тут одно из наипервейших дел — резервное копирование. Для чего в составе фирменного инструментария Mint имеется утилита mintbackup. В разделе Администрирование главного меню она так и называется — Резервное копирование. И, после ввода пароля, предстаёт в таком вот виде:


Изображение204

Для начала выполняется резервное копирование, для которого указываются исходный и целевой каталоги, а также дополнительные параметры — простое копирование, архив tar, tar.bz2 или tar.gz, условия перезаписи:


Изображение205

Далее определяются исключения из исходного каталога, не подлежащие архивированию (если, конечно, они нужны):


Изображение206

После этого выводится результирующая информация о будущем архиве:


Изображение207

А затем нажатие кнопки Применить вызывает начало процесса:


Изображение208

Завершение которого знаменуется таким сообщением:


Изображение209

Здесь следует нажать кнопку Закрыть — правда, это приведёт и к закрытию программы, но выбора всё равно нет.

То есть всё просто до банальности — и ничего такого, чего нельзя было бы сделать с помощью утилиты tar и её опций. Но всё это представлено в наглядной форме, избавляющей от необходимости ломать голову над последними. Иными словами, в этой своей части утилита mintbackup заслуживает рекомендации к применению.

Не менее проста и полезна утилита mintbackup во второй своей части, сохраняющей список установленных пакетов. Здесь всего-то и требуется, что указать целевой каталог:


Изображение210

Затем, при желании, просмотреть список пакетов, установленных в системе:


Изображение211

После чего нажать кнопку Применить — и дождаться появления сообщения об успешном завершении процесса:


Изображение212

После чего в целевом каталоге обнаруживается файл вида software_selection_alv-desk@2014-12-14-1850-package.list. Каковой является самым обычным текстовым файлом, содержащим список установленных пакетов:

accountsservice install

acl     install

add-apt-key     install

adobe-flashplugin       install

aisleriot       install

Пакеты по этому списку могут быть установлены на любой другой машине. Так что и от mintbackup нет никакого вреда, окромя пользы.

Программа записи USB mintstick

Как известно, оптические приводы постепенно отмирают. И на смену им приходят USB flash и SD-карты. Единственная сфера, где до некоторого времени оптические накопители были не всегда заменимы — это установка системы на чистую машину. Однако ныне все современные дистрибутивы Linux’а или BSD-системы распространяются в виде так называемых гибридных образов, допускающих их запись на твердотельные носители. Что повлекло за собой появление большого числа программ, призванных выполнить эту процедуру.

Имеется такая утилита и в составе фирменного инвентаря Mint’а. Это mintstick, которая в главном меню находится в разделе Стандартные под именем Создание загрузочного USB-носителя. И после запуска предстаёт перед глазами применителя в таком виде:


Изображение213

Дальнейшие действия очевидны: надо выбрать записываемый образ и указать, куда он должен быть записан (воткнутая флешка или SD-карта предлагается по умолчанию):


Изображение214

После этого потребуется ввести пароль и подождать завершения процесса, о чем будет сообщено дополнительно:


Изображение215

В поле Подробности будут указаны имена файла образа и целевого устройства:


Изображение216

Всё. Можно либо повторить процедуру для другого образа или устройства, либо закрыть программу.

Хотелось бы ещё проще? Не получится — проще уже некуда.

Языковые настройки — mintlocale

В очерке о настройках Cinnamon упоминался модуль Языки в секции Параметры его Системных настроек. И, поскольку он, собственно, принадлежит к семейству фирменных утилит Mint (под именем mintlocale), было обещано рассказать о нём в соответствующее время. Время это наступило.

Модуль Языки можно запустить как из панели Системных настроек, так и из секции Параметры главного меню. Он выполняет двоякую функцию. Во-первых, здесь можно изменить собственно язык интерфейса и прочие параметры, объединяемые понятием locale (формат даты, представление чисел, единицы измерения etc.). При выборе русского в качестве языка инсталляции всё это будет русским Российским (интерфейс, разумеется, русифицируется в меру испорченности перевода):


Изображение217

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


Изображение218

Главная особенность нового языкового модуля (он появился в Mint 17.1) — разделение групп параметров Language и Region (в русском переводе — Язык и Область/Край, соответственно). Первая определяет переменные LANG и LC_TIME, то есть собственно язык интерфейса и местное время. Группа же параметров Region задаёт значения всех остальных локально-зависимых переменных — LC_NUMERIC, LC_MONETARY, LC_PAPER, LC_NAME, LC_ADDRESS, LC_TELEPHONE, LC_MEASUREMENT и LC_IDENTIFICATION (представление чисел, единица бабла, формат бумаги, и так далее).

Разнесение переменных по группам может показаться спорным, как и его аргументация Клементом (типа специально для отъезжающих за границу). Однако сама по себе идея отделения языка интерфейса от прочего локально-зависимого хозяйства весьма здрава, особенно если язык этот — смесь нижегородского с оксфордским. Что же до местного времени… С каждым очередным самым последним переводом часов оно теряет всё больше смысла. Так что не пора ли жить по Гринвичу? Вполне реализуемо, как можно видеть на следующем скриншоте:


Изображение219

Вторая функция mintlocale — определение так называемого метода ввода. Поддержка их также впервые появилась в Mint 17.1. Методы ввода (Input Method) — это системы обеспечения ввода символов, отсутствующих на клавиатуре от слова «вааще». Например, китайских иероглифов и символов всех генетически связанных с ними систем письма. И потому, конечно, жизненно необходимы жителям соответствующих стран.

Однако мы, индоевропейцы, семиты, тюрки и многие другие, выступая как единый советский народ, не испытываем в них ни малейшей потребности. И потому то, что реально ни один метод ввода не включён (разработчики объясняют это недостатком сил), огорчать нас не должно. Напротив, скорее радовать. Ибо попытки майнтайнеров некоторых дистрибутивов включать поддержку какого-либо из этих методов (мне приходилось сталкивать с IBus), да ещё и по умолчанию, нам, применителям, не давало ничего, кроме лишних проблем.

Менеджер драйверов и интегрированное видео AMD

Последний из фирменных инструментов Mint, о котором я хотел сказать пару слов — Менеджер драйверов, он же mintdrivers, предназначенный для управления проприетарными драйверами, например, для видеокарт. Правда, мой личный опыт общения с ним оказался неудачным, но это связано с моим «железом», а не собственно с программой. Так что просто опишу последовательность действий, проиллюстрировав её скриншотами.

Запуск утилиты происходит из секции Администрирование главного меню, где она носит имя Менеджер драйверов. После чего на экране появляется (в моём случае с интегрированным процессорным видео Radeon HD 7500G) такая картинка:


Изображение220

Представляется очевидным, что для установки проприетарного драйвера достаточно вместо первой строки отметить третью и нажать кнопку Применить изменения. Только я это сделал — как процесс пошёл:


Изображение221

Шёл процесс довольно медленно, так как кроме собственно драйвера fglrx в ходе его устанавливались lib32gcc1, dkms и ещё куча зависимостей, а также регенерация /boot/initrd.img. По завершении всего этого исходная картинка приняла следующий вид:


Изображение222

Заодно был создан и файл /etc/X11/xorg.conf с описанием конфигурации видеосистемы. Что в моём случае, правда, не помогло: после рестарта машина отказалась загружаться, выдав чёрный экран без возможности переключения в текстовую консоль и реакции на комбинацию из трёх пальцев. Пришлось перезагружаться в recovery mode и заниматься ликвидацией этого безобразия — но это совсем другая история.

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

На этом я пока поставлю точку в описании фирменного инструментария дистрибутива Mint. За бортом остались ещё несколько утилит, повода обращаться к которым у меня не было, и потому ничего сказать про них я не могу. В их числе:

  • mintWifi — средство настройки соответствующего соединения; но у меня на Ноутбучке WiFi волшебным образом заработал сам собой, без всяких настроек;

  • mintupload-manager — средство управления закачками на сервера, применения которому я не нашёл;

  • mintnanny — блокировщик доменов; без надобности, ибо я не депутат госдумы, чтобы мне везде мерещилась банда педофилов с ихней порнографией.

Что же до утилит mint-make, mint-batch-make, mint-compress, mint-decompress, о назначении которых можно догадаться по их именам, то к ним я обращусь, когда и если (если и когда) в этом возникнет практическая необходимость.

Прочие настройки

В предыдущих очерках говорилось о штатных инструментах для настройки дистрибутива Mint и его среды Cinnamon. Чтобы закончить с этой тему, скажу несколько слов об инструментах конфигурирования не то чтобы нештатных, но непосредственно ни к дистрибутиву, ни к среде не привязанных. И к которым приходится обращаться не так уж часто.

Редактор dconf

Редактор dconf появился в GNOME 3 и ныне применяется для низкоуровнего конфигурирования, кроме родительсккой среды, также в Unity, MATE и Cinnamon. Он позволяет напрямую редактировать всю базу конфигурации, как общесистемную, так и штатных пользовательских приложений. И, хотя делает это и не самым простым способом, но даёт доступ к тем настройкам, которые разработчики сред посчитали недостойными внимания конечных пользователей. Или, скорее, решили, что народу они не нужны.

Правда, в Cinnamon таких замаскированных настроек очень мало. И если в Unity обращаться к Редактору dconf приходится постоянно, а в MATE — периодически, то в нашей среде у меня поводы для запуска этой утилиты возникали буквально считанные разы.

Запускается эта утилита, кстати, через пункт Редактор dconf в секции Администрирование главного меню, после чего предстаёт в таком виде:


Изображение223

Каждый пункт во фрейме слева разворачивается каскадом вложенных пунктиков и подпунктиков, имя которым далеко превышает легион. И описывать которые я не буду. А дам пару практических рецептов для включения некоторых опций, недоступных через Системные настройки среды Cinnamon.

Ранее я упоминал, что в текущей версии Cinnamon возможность сохранения сеанса из пункта Автостарт изъята. Но в Редакторе dconf она осталась. И доступ к ней осуществляется по схеме org.cinnamon.SessionManager, где следует включить параметр (в терминологии dconf — ключ) auto-save-session:


Изображение224

Не так давно мы весьма подробно рассмотрели конфигурирование раскладок клавиатуры и их переключателей через соответствующий модуль Системных настроек Cinnamon. И пришли к выводу, что тут можно настроить всё, что только душе угодно. Тогда же было упомянуто, что всё то же самое можно проделать и в Редакторе dconf. Для чего достаточно проследовать по org.gnome.libgnomekbd.keyboard и заполнить желаемым образом поля layouts, model и options:


Изображение225

Как заполнить — описывать не буду, потому что через модуль Клавиатура в Системных настройках это сделать проще. А вот если пройти по схеме org.gnome.libgnomekbd.desktop, то можно включить ключ load-exta-items:


Изображение226

Это обеспечит загрузку редко используемых раскладок клавиатуры. В частности, для русской раскладки окажутся доступными дополнительные варианты — те, что пыведены курсивом:


Изображение227

В русскоязычном окружении этот ключ практического значения не имеет, но для всяких прочих языцей — может пригодиться. Например, для программирования на APL:


Изображение228

Впрочем, более никаких практических задач для решения в Редакторе dconf я не придумал.

Mint и консоль

Всё, что было сказано о конфигурировании Mint в предыдущих очерках, относилось к настройкам графических сред, даже конкретно одной представительницы их — Cinnamon. Но ведь в Linux’е есть ещё и «текстовый» режим, то есть консоль. «Текстовый» в кавычках — потому что, конечно, чисто текстовой консоли нынче не найти, наверное, ни в одном дистрибутиве, везде frame buffer — но уж такова традиция.

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

$ date

выводятся настоящие русские буквы, а не квадратики или кракозябры.

Повторяю, вряд ли кто будет сочинять в консоли многотомные романы на русском языке — в основном в текстовом режиме приходится загружаться при всякого рода сбоях. Но иногда приходится. Аварийные работы тоже лучше выполнять в комфортной и приятной для глаз обстановке. Да и вообще, как говорил штабс-капитан Мышлаевский, в казарме должен быть порядок, А текстовая консоль большинства современных дистрибутивов от порядка далека.

К чести Mint надо сказать, что этот дистрибутив принадлежит как раз к тем редким, у которых консоль русифицирована «искаропки». Русские буквы здесь и правильно выводятся, и правильно вводятся. Причём вводятся в том самом варианте русской раскладки клавиатуры, который был задан при инсталляции системы, и переключатель раскладок (по комбинации Alt+Shift) оказывается таким же, как в графическом режиме. В общем, оказывается, что приложить руки к улучшательству есть где. Ибо у применителя всё должно быть прекрасно — в том числе и консоль.

Особенно раздражает отсутствие поддержки мыши — без неё работа в консоли, даже аварийно-спасательная, становится мучительной. Ибо мышь в консоли — устройство не указательно-позиционирующее, а копировально-вставляющее. Достаточно выделить мышью фрагмент экрана, как он попадает в экранный буфер, откуда может быть вставлен в любое место, в том числе и в другую виртуальную консоль, щелчком средней кнопки мыши. Функция, незаменимая при правке конфигов — а ведь аварийно-спасательные работы обычно к ней и сводятся.

Поясню (как ни странно, нынче это надо пояснять), что на современных колесовых мышах роль средней кнопки почти всегда выполняет это самое колёсико. А на ноутбучных тачпадах тот же эффект достигается одновременным нажатием обеих кнопок. Правда, что делать на входящих в моду ноутбуках с однокнопочными тачпадами — не знаю; разве что, не покупать их…

Из поставленных задач по улучшательству консоли проще всего решается первоочередная — включение службы консольной мыши, сиречь gpm. Для этого нужно, как это ни парадоксально, установить пакет gpm:

$ sudo apt install gpm

Если сделать это, находясь в чистой консоли (а перключиться в любую из них можно по комбинации клавиш Control+Alt+F#, # — от 1 до 6; возврат в графический сеанс — Alt+F8), то немедленно после завершения установки можно будет увидеть курсор мыши в виде прямоугольничка. И теперь, по крайней мере, не придётся при всяких ремонтно-восстановительных работах вводить много лишних символов — в распоряжении применителя описанный выше «мышиный» буфер.

Следующая задача на очереди — установка удобочитаемого экранного шрифта. Проще всего она решается утилитой dpkg-reconfigure. Вызванная в таком виде

$ sudo dpkg-reconfigure console-setup

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


Изображение229

Затем спросит об используемой таблице символов:


Изображение230

Потом последует предложение выбрать шрифт:


Изображение231

Далее будет проведён маленький ликбез о консольных шрифтах и условиях их использования:


Изображение232

Не советую им пренебрегать — после этого легче сделать осознанный выбор матрицы шрифта (типографские термины к консольным шрифтам не применимы):


Изображение233

После этого происходит выход из интерфейса утилиты, и всё заказанное претворяется в действительность. Процесс этот связан с регенерацией initrd, так что его результат можно будет увидеть только после рестарта — с которым, впрочем, не обязательно торопиться.

Третья задача очень важна для меня — но возможно, что большинству применителей решать её не придётся. Я использую сочетание варианта Typewriter Legacy для кириллической раскладки и CapsLock в качестве переключателя латиница/кириллица. Когда-то эта была стандартная комбинация (именно такова была первая русская раскладка для UNIX-косоли, созданная Андреем Черновым aka ache), но ныне воспринимается как экзотика. И её «спаривание» для консоли Linux требует некоторых усилий. В частности, в большинстве дистрибутивов мне приходилось прибегать к раскладке, изготовленной собственноручно.

А вот в Mint эти усилия минимальны. Я имел не один раз повод радостно сообщить, что выбранная при установке раскладка клавиатуры и один из её вариантов (среди которых имеется и Typewriter Legacy) наследуется не только Иксами, но и консолью установленной системы. Правда, с переключением раскладок по Alt+Shift, порождённым каким-то умником в недрах Microsoft’а вместе с раскладкой winkeys (также одной из самых неудобных, какую только можно придумать).

Однако задача с изменением переключателя решается очень просто: достаточно отредактировать файл /etc/default/keyboard. Он практически точно совпадает с клавиатурной секцией старого /etc/X11/xorg.conf или современного /etc/X11/xorg.conf.d/10-keymap.conf, и по умолчанию выглядит так:

XKBMODEL=»pc105″

XKBLAYOUT=»us,ru»

XKBVARIANT=»,typewriter-legacy»

XKBOPTIONS=»grp:alt_shift_toggle,grp_led:scroll»

Так что в нём достаточно заменить значение переключателя alt_shift_toggle на желаемое, например, для меня — на caps_toggle. После чего можно с чистым сердцем перегружаться и, авторизовавшись в любой текстовой консоли, любоваться красивыми шрифтами семейства Terminus, созданными Димитром Жековым, набирать русские буквы в привычной раскладке и, при необходимости, копировать набранное из консоли в консоль через «мышиный» буфер.

GRUB2: восстановление загрузчика

В заключение всей «конфигурационной солянки» — пара слов о загрузчике GRUB2. Материалов в Сети на эту тему немерянно (одним из самых полезных мне представляется вот этот), и пересказывать их я не намерен. А остановлюсь только на восстановлении загрузчика в случае его порчи по каким-либо причинам.

Есть несколько методов восстановления GRUB2, я опишу тот, который представляется мне самым простым.

Для начала надо иметь Live-носитель Mint в любом виде — DVD-, флешки, SD-карты, каковой помещается куда следует. При рестарте машины, обычно в момент появления логотипа производителя, нужно успеть нажать клавишу быстрого выбора загрузочного устройства — для современных ASUS’овских «матерей» это F8, для ASRock’овских — F11, для прочих — см. документацию. И в появившемся меню выбрать нужный пункт, он обычно называется явным образом. Происходит загрузка Live-среды, каковая в нашем случае представлена Mint с Cinnamon-окружением.

Далее следует опознать имя файла устройства, несущего корневой раздел системы, загрузчик которой подлежит восстановлению — подчёркиваю, требуется имя устройства, а не раздела. Это можно сделать просмотром вывода либо команды

$ sudo fdisk -l

либо команды

$ ls /dev/sd*

Предположим для определённости, что это устройство /dev/sda. Теперь корневой раздел монтируется в файловую систему Live-среды. Прще всего сделать это через Nemo — в его боковой панели, в секции Носители, отражаются все присутствующие в машине дисковые устройства. И достаточно выбрать пункт Присоединить контекстного меню или просто «левокликнуть» на соответствующем имени. Теперь главное — определить точку монтирования. В Mint (как и во всех Ubuntu’идах) временно смотированные устройства попадают в каталог /media/username, устройства с меткой — в подкаталог с её именем, без оной — в подкаталог с универсальным идентификатором устройства (UID), это полуметровая зубодробительная последовательность букв и цифр.

А вот теперь — собственно восстановление загрузчика. Оно выполняется одной командой:

$ sudo grub-install —root-directory=/media/username/mount_point /dev/sda

Здесь mount_point — метка диска или его очень простой UID вроде d55aebcb-7e7d-4d34-aff4-ed6e494e9b7f. Автодополнение в этом случае не работает, однако, даже если устройство не «помечено», его UID можно взять из файла /etc/mtab, описывающего временно смонтированные устройства, или, открыв его в Nemo, из адресной строки последнего.

На этом дело восстановления загрузчика закончено — можно перезагружаться в нормальном режиме.

Основы командного интерфейса

Поскольку не исключена вероятность, что эту книгу будут читать и совсем начинающие применители Linux’а вообще, тех, для кого Mint оказался первым дистрибутивом этой операционной системы, в этом очерке будут даны некоторые общие сведения об интерфейсе командной строки (CLI — Command Line Interface). Тем более, что это потребуется уже ближайшее время, в очерках, посвящённых управлению пакетами.

Введение в CLI

CLI представляет собой базу, для которой GUI всякого рода являют лишь оболочку. Всякое действие в linux-системе может быть выполнено прямой командной директивой. И его же можно осуществить путем манипулирования объектами. Например, копирование файлов выполняется соответствующей командой — cp, это первый способ. Но его же можно осуществить перетаскиванием мышью объекта, представляющего наш файл зрительно, из того места, где он находился ранее, туда, где мы хотим видеть его копию, а это уже второй способ.

То есть манипуляция объектами в GUI — это обычно более или менее опосредованное выполнение соответствующих данному действию команд. Почему основные навыки работы с CLI не помешают даже тому пользователю, который не вылезает из графической среды. Ибо сфера применения CLI не ограничивается «голой» консолью. Он же используется в эмуляторах терминала в графическом режиме оконной среды X. Более того, в настоящее время это основная среда для применения командного интерфейса — к текстовой консоли обычно обращаются только в аварийных ситуациях.

CLI в большинстве случаев обеспечивается классом программ, именуемых командными интерпретаторами, командными процессорами, командными оболочками или по простому шеллами (shell).

Как легко догадаться по одному из определений, кроме предоставления пользовательского интерфейса, шеллы выполняют и вторую функцию — служат интерпретаторами собственных языков программирования. На этом основывается классификация шеллов — они разделяются на две группы, обычно именуемые Bourne-shell совместимые и C-shell совместимые. В силу ряда причин в качестве стандарта принята одна из оболочек первой группы — так называемый POSIX-шелл. Правда, он представляет собой чистую абстракцию, однако большинство используемых в Unix’ах оболочек с этим стандартом совместимы. А системная оболочка Mint, Dash, довольно точно воспроизводит и его функциональность. И потому все примеры, иллюстрирующие принципиальные вопросы CLI, будут базироваться на наиболее используемых командах, построенных в соответствие с правилами POSIX-шелла.

Командная строка

Основой командного интерфейса является командная строка, начинающаяся с приглашения для ввода. Далее он будет обозначаться милым сердцу россиянина символом длинного зеленого друга — $, если речь идёт о сеансе обычного пользователя, или символом решётки — #, для приглашения строки в сеансе администратора. Это — чистая условность: вид приглашения может быть настроен в широких пределах, причём по разному в разных оболочках. Об этом мы поговорим, когда речь дойдёт до описания конкретного шелла — Zsh.

Командная строка — визуальное представление среды, в которой задаются основные элементы командного интерфейса: командные директивы с их аргументами и опциями.

Командная директива (или просто команда) — основная единица, посредством которой пользователь взаимодействует с шеллом. Она образуется по определенным правилам, именуемым синтаксисом. Синтаксис командной директивы определяется, в первую очередь, языком, принятым в данной командной оболочке. Кроме того, некоторые команды (не очень многочисленные, но весьма употребимые) имеют собственный, нестандартный синтаксис.

Однако в целом базовые правила построения команд имеют много общего. И именно эти базовые правила станут предметом данного раздела. Синтаксические особенности отдельных нестандартных команд будут оговариваться по ходу изложения.

Итак, командная директива образуется:

  • именем команды, однозначно определяющим ее назначение,

  • опциями, определяющими условия выполнения команды, и

  • аргументами — объектами, над которым осуществляются действия.

Очевидно, что имя команды является обязательным компонентом, тогда как опции и аргументы могут и отсутствовать (или подразумеваться в неявном виде по умолчанию).

ещё один непременный компонент командной директивы — это специальный невидимый символ конца строки: именно его ввод отправляет команду на исполнение. В обыденной жизни этот символ вводится нажатием и отпусканием клавиши Enter. Почему обычно и говорят: для исполнения команды нажмите клавишу Enter. Тот же эффект, как правило, достигается комбинацией клавиш Control+M. Символа конца командной строки, знаменующего исполнение команды, мы на экране не видим. Однако важно, что это — такой же символ, как и любой другой (хотя и имеющий специальное значение).

В подавляющем большинстве случаев опции (или их последовательности) задаются непосредственно за именем команды, а аргумент (или группа аргументов) команду завершает, хотя это правило имеет некоторые исключения. Вне зависимости от порядка опций и аргументов, принятых для данной команды, интерпретация их осуществляется слева направо.

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

Как уже говорилось, имя команды определяет выполняемые ею функции. Существуют команды, встроенные в оболочку, то есть не имеющие запускающих их исполняемых файлов, и команды внешние. В последнем случае имя команды однозначно указывает на имя исполняемого файла программы, выполняемой при отдаче соответствующей директивы. Часто встроенные и внешние команды одного назначения имеют одинаковые имена. В этом случае обычно предпочтительно использование встроенных команд — впрочем, они и вызываются в первую очередь. Для вызова одноимённой внешней команды её нужно задать с указанием пути. Так, директива

$ time search for Mint in path2/

вызовет для определения времени выполнения команды search (о ней будет рассказываться в следующем очерке) встроенную команду time. А в форме

$ /usr/bin/time search for Mint in path2/

будет задействована внешняя утилита с тем же именем. Кстати, это один из тех случаев, когда второй вариант может иногда оказаться предпочтительней: встроенная и внешняя команды имеют разные форматы вывода, причём в первой он зависит от используемой командной оболочки. И потому она не всегда подходит для прямого сравнения результатов — например, быстродействия в разных системах.

Определить, является ли данная команда встроенной в оболочку или внешней, можно с помощью встроенных команд type или which. Для встроенных команд вывод их будет таким:

$ type which

which is a shell builtin

$ which type

type: shell built-in command

Или, в некоторых случаях, таким:

$ which time

time: shell reserved word

$ type time

time is a reserved word

Для внешних команд любой из этих вариантов даст в выводе путь к исполняемому файлу:

$ which date

/bin/date

$ type date

/bin/date

Некоторые команды могут выступать под несколькими именами. Это связано с тем, что исторически в различных Unix-системах команды, исполнявшие одинаковые функции, могли получать разные названия. В каждой конкретной системе обычно используется только одна из таких команд-дублеров. Но при этом имена дублирующих команд также могут присутствовать в системе — для совместимости. Не следует думать, что это две различные программы одного назначения: как правило, такая синонимичность команд реализуется посредством механизма ссылок (links) или псевдонимов (alias), о которых речь пойдёт позднее.

Иногда команда, вызванная через имя своего синонима, может отличаться по своей функциональности от самой же себя, вызванной под родным именем. В этом случае говорят о эмуляции одной команды другой. Типичный пример — командная оболочка /bin/bash в большинстве дистрибутивов Linux имеет своего дублера — /bin/sh; вызванная таким образом, она воспроизводит базовую функциональность стандарта POSIX-шелла.

Автодополнение

Для правильного применения команд, конечно же, нужно знать их имена и назначение. Однако нас никто не заставляет напрягать пальцы вводом имени команды полностью. Потому что тут на помощь приходит великий метод автодополнения.

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

Большинство употребимых команд POSIX-систем — коротки и мнемонически прозрачны. И может показаться. что не такое уж это облегчение — заменить ввод двух-трех символов нажатием табулятора (а то ещё и неоднократным). Однако, когда речь дойдет до аргументов команд — тут вся мощь автодополнения станет явной.

И ещё маленькое отступление. Автодополнение — стандартная возможность Bash и всех других командных оболочек, относимых к категории развитых. Но как раз в стандарте POSIX эта возможность не предусмотрена, и потому POSIX shell ее лишён. Нет этой функции и в Dash — системной командной оболочке Mint. Которая, впрочем, в интерактивном режиме не используется.

Ещё один способ облегчения ввода команд — обращение к их истории, о чём разговор будет несколько позже.

Опции

Указания только имени команды достаточно для выполнения некоторых из них. Типичный пример — команда ls (от list), предназначенная для просмотра имен файлов (строго говоря, содержимого каталогов). Данная без аргументов, она выводит список имен файлов, составляющих текущий каталог, представленный в некоторой форме по умолчанию, например, в домашнем каталоге пользователя это будет выглядеть примерно так:

$ ls

Desktop/    Downloads/   Music/  Pictures/  Templates/

Documents/  lost+found/  mytmp/  Public/    Videos/

Исполнение же многих других команд невозможно без указания опций и (или) аргументов. Для них в ответ на ввод одного её имени часто следует не сообщение об ошибке (или не только оно), но и краткая справка по использованию команды. Например, в ответ на ввод команды для создания каталогов mkdir (от make directory) последует следующий вывод:

usage: mkdir [-pv] [-m mode] directory …

Для одних опций достаточно факта присутствия в командой директиве, другие же требуют указания их значений (даваемых после опции обычно через знак равенства). В приведённом примере команды mkdir к первым относятся опции -v (или —verbose), предписывающая выводит информацию о ходе выполнения команды (запомним эту опцию — в том же смысле она используется чуть ли не во всех командах Unix), и -p, которая позволяет создать любую цепочку промежуточных каталогов между текущим и новообразуемым (в случае их отсутствия).

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

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

Продемонстрирую это на примере опций все той же команды mkdir. Полный их список будет следующим:

-m, —mode=MODE установить код доступа

        (как в chmod)

-p, —parents не выдавать ошибок,

        если существует, создавать

        родительские каталоги,

        если необходимо

-v, —verbose печатать сообщение

        о каждом созданном каталоге

—help показать помощь и выйти

—version  вывести информацию

        о версии и выйти

Очевидно, что для опции —version краткая форма совпала бы с таковой для опции —verbose, и потому первая существует только в полной форме. А вот для опции —help краткая форма в большинстве команд возможна, и она выглядит как -h. Более того, во многих командах вызов помощи может быть вызван посредством опции -?. К слову сказать — приведенный выше список опций команды mkdir получен именно таким способом.

Раз уж зашла речь об опциях —version и -h (—help, -?), давайте и их запомним на будущее. Это — так называемые стандартные опции GNU, в число коих входит и опция -v, —verbose. Назначение «длинной» их формы (—version, —help, —verbose) идентично почти во всех командах, краткой — во многих.

Опять-таки, из того же примера видно, что опции в односимвольной форме предваряются единичным символом дефиса и могут быть даны единым блоком, без пробелов:

$ mkdir -vpm 777 dir/subdir

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

$ mkdir —parents —mode=777 dir/subdir

Загадочные семерки после опции -m (—mode) — это и есть те самые атрибуты доступа, данные в символьной нотации, о которых речь пойдёт в соответствующем разделе.

Опции команды именуются также флагами (реже ключами) или параметрами. Однозначной трактовки этих терминов нет. Однако обычно под флагами подразумеваются опции, не требующие указания значений. Термин параметр же применяется к опции, такового требующей, и объединяет опцию и ее значение. Правда, мне встречалось определение параметра как совокупности опций и аргументов, но я буду придерживаться приведенных определений.

Порядок опций, если их приводится более одной, для большинства команд не существенен. Хотя, например, для команды tar, создающей файловые архивы, опция -f, значением которой является имя создаваемого или распаковываемого архива, традиционно указывается последней. И, к слову сказать, именно эта команда — одна из немногих, опции которой не обязаны предваряться символами дефиса. Так, директивы

$ tar cf filename.tar dir

и

$ tar -cf filename.tar dir

абсолютно равноценны: и та, и другая создает единый архивный файл filename.tar из отдельных файлов каталога dir.

Особый смысл имеет символ удвоенного дефиса , если после него не следует никакой опции: таким образом обозначается конец списка опций, и все последующие, отделённые пробелом, символы интерпретируются как аргументы. Одинарный же дефис с последующим пробелом, напротив, подменяет аргументы команды, то есть в качестве таковых рассматривается стандартный ввод: знание этого нам потребуется, когда речь дойдёт до командных конвейеров.

Пример: опции команды ls

Опции определяют условия выполнения команды. На предыдущей странице был приведён пример команды ls без опций. Однако на самом деле отсутствием опций при ней определяется вид выводимого списка по умолчанию — как многоколочночного списка, состоящего из имен файлов без учета т.н. скрытых файлов (а таковыми являются файлы, имена которых начинаются с символа точки, почему они ещё называются dot-файлами), без каких-либо их атрибутов и без визуального различия файлов различных типов.

Различные же опции команды ls определяют состав и формат выводимого списка файлов. Так, в форме

$ ls -a

она обеспечивает вывод списка имен всех файлов текущего каталога, включая
скрытые файлы вида .* (символ * здесь обозначает шаблон имени, соответствующий любому количеству любых символов — в том числе и нулевому, то есть отсутствию оных), символы текущего (./ каталога и

каталога родительского (../).

В форме

$ ls -l

дается вывод списка имен файлов в «длинном» формате (отсюда название опции -l — от long), то есть с указанием атрибутов доступа, принадлежности, времени модификации, размера и некоторых других характеристик:

drwxrwxr-x. 14 alv alv 4,0K Мар 14 08:40 current/

drwxr-xr-x.  2 alv alv 4,0K Фев  8 11:28 Desktop/

drwx——.  5 alv alv 4,0K Мар 11 18:34 priv/

Форма

$ ls -F

позволяет получить список файлов с символьным различением файлов различных типов. Например, имя каталога будет выглядеть как dirname/, имя исполнимого файла — как filename* (здесь звездочка — не шаблон имени, а символическое обозначение исполняемого файла), и так далее.

Я столь подробно остановился на команде ls не только из-за многочисленности ее опций: это — одна из самых употребимых команд для просмотра файловой системы. И, должным образом настроенная (в том числе и с помощью приведенных опций), она дает ничуть не менее информативную и зрительно выразительную картину, чем развитые файловые менеджеры типа Midnight Commander или многочисленные файловых менеджеры графического режима.

Аргументы

Таким образом мы подобрались к понятию аргументов командной директивы. Аргументами определяется, как правило, объект (или объекты) действия команды. В большинстве случаев в качестве аргументов команд выступают имена файлов и (или) пути к ним.

Выше говорилось, что при отсутствии аргументов команда ls выводит список имен файлов текущего каталога. Это значит, что текущий каталог выступает как заданный неявным образом (по умолчанию) аргумент команды ls. Если же требуется вывести список имен файлов каталога, отличного от текущего, путь к нему должен быть указан в качестве аргумента команды явно, например:

$ ls /usr/bin

Большинство команд допускает указание не одного, а нескольких (и даже очень многих) аргументов. Так, единой директивой вида

$ cp file1 file2 … fileN dir

можно скопировать (команда cp — от copy) сколько угодно файлов из текущего каталога в каталог dir (на самом деле на это «сколько угодно» накладываются некоторые теоретические ограничения, определяемые максимально возможной длиной командной строки, но практически предел этот очень далек).

Маленькое отступление. Упоминание команды cp — удобный случай чуть вернуться назад и рассмотреть одну очень важную опцию, почти универсальную для команд POSIX-систем. Для начала попробуем скопировать один каталог в другой:

$ cp dir1 dir2

Как вы думаете, что получится в результате? Правильно, сообщение о невозможности выполнения этой операции — примерно в таком виде:

cp: omitting directory ‘dir1’

поскольку команда cp в чистом виде для копирования каталогов не предназначена. Что делать? Очень просто — указать опцию -R (от Recursive; в большинстве систем проходит и опция -r с тем же смыслом, но первая форма работает абсолютно везде. В результате в каталог dir2 не только будут скопированы сам каталог dir1 и все входящие в него файлы, но и вложенные подкаталоги из dir1, если таковые имеются.

Маленькое уточнение: вполне возможно, что в дистрибутиве, который имеется в вашем распоряжении, проходит и копирование каталогов просто через cp, без всяких дополнительных опций. Это — потому, что команда cp часто определяется как псевдоним самой себя с опцией рекурсивного копирования, о чем скоро пойдет речь.

Вообще рекурсия (то есть определение некоего выражения через самого себя) — очень важное понятие в Unix, пронизывающее происходящие от нее системы насквозь. И послужившие даже базой для своеобразного хакерского юмора. Однако сейчас для нас важно только то, что рекурсия применима практически ко всем файловым операциям, позволяя распространить действие одной командной директивы не только на файлы данного каталога, но и на все вложенные подкаталоги и их содержимое.

Однако вернемся к аргументам. Действие некоторых команд неоднозначно в зависимости от аргументов, к которым она применяется. Например, команда mv служит как для переименования файлов, так и для их перемещёния в другой каталог. Как же она узнает, что ей делать в данном конкретном случае? Да именно по аргументам. Если дать ее в форме

$ mv filename1 filename2

то следствием будет переименование filename1 в filename2. А вот если первым аргументом указан файл, а вторым — каталог, например

$ mv filename dir

то результатом будет перемещёние filename из текущего каталога в каталог dir. К слову сказать, команды типа mv воспринимают разное количество аргументов в зависимости от того, какие они, эти аргументы. В первом примере аргументов может быть только два — имя исходного файла и имя файла целевого. Зато во втором примере в качестве аргументов можно задать сколько угодно файлов и каталогов (с учетом вышеприведенной оговорки относительно «сколько угодно») — все они будут перемещёны в тот каталог, который окажется последним в списке. То есть директивой:

$ mv file1 … fileN dir1 … dirM dirN

в каталог dirN будут перемещёны все файлы file1fileN и все каталоги dir1dirM. Характерно, что для этого команде mv, в отличие от команды cp, ей не требуется каких-либо дополнительных опций — она рекурсивна по самой своей природе.

Пути к файлам

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

Так, если пользователь находится в своем домашнем каталоге (абсолютный путь к нему обычно выглядит как /home/username), то просмотреть содержимое каталога /usr/bin он может двумя способами — тем, который был дан в предыдущем примере, или вот так:

$ ls ../../usr/bin

Первый путь в аргументе команды ls — абсолютный, отсчитываемый от корневого каталога, второй — задается относительно каталога текущего, ведь ../ — это родительский каталог для него.

Пути в аргументах команд могут быть весьма длинными. Например, чтобы просмотреть список шрифтов, применяемых в интерфейсе Cinnamon по умолчанию, нужно дать команду следующего вида:

$ ls /usr/share/fonts/truetype/noto

И читатель вправе спросить — неужели мне все это вводить вручную? Отнюдь — отвечу я ему. Потому что автодополнение, о котором упоминалось по ходу разговора об именах команд, действует также для путей в их аргументах — последовательным нажатием клавиши табуляции все недостающие символы будут добавляться

Ещё один способ избежать набора длинных путей к файлам — это определение переменной PATH. Внимательный читатель, вероятно, обратил внимание, что при наборе команды путь к исполняемому её файлу не указывается. Для внутренних команд причина понятна — они прошиты в самой оболочке. А как мы обходимся без указания путей к командам внешним? Неужели система мистическим чувством определяет, где они находятся?

Отнюдь, ни малейшей мистики, Просто каталоги, в которых находятся команды (а это, как правило, /bin, /sbin, /usr/bin, /usr/sbin) определены в качестве значений переменной PATH, о чём мы подробнее поговорим со временем.

Кое-что об исключениях

Итак, типичная форма POSIX-команды в обобщенном виде выглядит следующим образом:

$ command -[options] [arguments]

Из этого правила выбиваются немногочисленные, но весьма полезные и часто используемые команды. Однако и для таких команд с нестандартным синтаксисом устанавливаются те же компоненты — имя, опции, аргументы, хотя по ряду причин (в том числе исторических) порядок их может меняться.

Это можно проиллюстрировать на примере полезнейшей команды find, предназначенной для поиска файлов (и не только для этого — она являет собой почти универсальное орудие в деле всякого рода файловых манипуляций). В типичной своей форме она выглядит примерно следующим образом:

$ find dir -option1 value -option2 [value]

Здесь dir — каталог, в котором выполняется поиск, — может рассматриваться в качестве аргумента команды. Опция -option1 (обратим внимание, что здесь, не смотря на многосимвольность опций, они предваряются единичным символом дефиса) и ее значение value определяют критерий поиска, например, -name filename — поиск файла с указанным именем, а опция -option2 предписывает, что же делать с найденным файлом (файлами), например, -print — вывести его имя на экран. причём опция действия также может иметь значение. Например, значением опции -exec будет имя команды, вызываемой для обработки найденного файла (файлов). Так, директива вида

$ find ~/ -name *.tar -exec tar xf {} ;

требует отыскать в домашнем каталоге (~/), выступающем в качестве аргумента, файлы, имя которых (первая опция — критерий поиска) соответствует шаблону *.tar (значение первой опции), и выполнить (вторая опция — действия) в их отношении команду tar с собственными опциями, обеспечивающими распаковку архивов (значение второй опции). Интересно, что в этом контексте в качестве значений второй опции команды find выступает не только внешняя команда, но и все относящиеся к ней опции.

В последнем примере имеется несколько символов, смысл которых может показаться непонятным. Надеюсь, он прояснится достаточно скоро — в разговоре о регулярных выражениях.

Псевдонимы

Вернемся на минуту к команде ls. У читателя может возникнуть вполне резонный вопрос: а если я всегда хочу видеть ее вывод с символическим различением типов файлов, да ещё в «длинном» формате? Ну и без вывода скрытых файлов мне никак не прожить. И что же — мне каждый раз вводить кучу опций, чтобы получить столь элементарный эффект?

Отнюдь — ответил бы граф, стуча манжетами о подоконник. Потому что этот вопрос задавали себе многие поколения не только пользователей, но и разработчиков. И ответили на него просто — введением понятия псевдонима команды (alias).

Что это такое? В большинстве случаев — просто некоторое условное имя, подменяющее определённую команду с теми её опциями, которые мы используем чаще всего. Причём, что характерно, псевдоним команды может совпадать с ее именем. То есть, например, — набирая просто ls, мы получаем список файлов не в умолчальном формате, а в том, в каком угодно нам.

Устанавливаются псевдонимы очень просто — одноименной командой alias, в качестве аргументов которой выступают имя псевдонима и его значение, соединенные оператором присваивания (именуемым в просторечии знаком равенства). А именно, если мы хотим ныне, и присно, и во веки веков видеть вывод команды ls с символьным различением типов файлов, нам достаточно дать команду вроде следующей:

$ alias ls=’ls -F

Здесь следует обратить внимание на два момента: а) на то, что имя псевдонима совпадает с именем команды (что отнюдь не препятствует создания псевдонима типа ll=’ls -l’ специально для вывода файловых списков в длинном формате), и б) на одинарные кавычки, в которые заключено значение псевдонима. Смысл их станет ясен несколькими параграфами позже, а пока просто запомним, что кавычки (и именно одинарные) — обязательный атрибут команды установки псевдонима.

Таким образом мы можем наделать себе псевдонимов на все случаи жизни. В разумных пределах, конечно — иначе вместо упрощения жизни мы создадим себе необходимость запоминания множество невнятных сочетаний символов. Однако на наиболее важных (и обычно определяемых) псевдонимах я остановлюсь.

Вспомним команды типа cp и mv, которыми мы, в частности, можем скопировать или переместить какие-то файлы из каталога в каталог. А что произойдет, если чисто случайно в целевом каталоге уже имеются файлы, одноименные копируемым/перемещаемым? Произойдет штука, могущая иметь весьма неприятные последствия: файлы в целевом каталоге будут заменены новыми, теми, что копируются туда или перемещаются. То есть исходное содержание этих файлов будет утрачено — и безвозвратно, восстановить его будет невозможно никакими силами.

Разумеется, иногда так и нужно, например, при полном резервном копировании старые версии файлов и должны быть заменены их более свежими вариантами. Однако такое приемлемо далеко не всегда. И потому в большинстве команд, связанных с необратимыми изменениями файловой системы, предусматривается специальная опция — -i (или —interactive). Если задать эту опцию с командой cp или mv, то при совпадении имён исходного и целевого файлов будет запрошено подтверждение на выполнение соответствующего действия:

$ cp file1 file2

cp: overwrite  file2′?

И пользователь может решить, нужно ли ему затирать существующий файл, ответив yes (обычно достаточно y), или это нежелательно, и должно ответить no (а также просто n — или не отвечать ничего, это равноценно в данном случае отрицательному ответу).

Так вот, дабы не держать в голове необходимость опции -i (ведь, как я уже говорил, пропуск ее в неподходящий момент может привести к весьма печальным результатам), в подавляющем большинстве систем для команд cp и mv (а также для команды rm, служащей для удаления файлов — эта операция также практически необратима) определяются одноименные им псевдонимы такого вида:

$ alias cp=’cp -i’;

$ alias mv=’mv -i’;

$ alias rm=’rm -i’

Все это, конечно, очень благородно, заметит внимательный читатель. Но что, если мне заведомо известно, что сотни, а то и тысячи файлов целевого каталога должны быть именно переписаны новыми своими версиями? Что же, сидеть и, как дурак, жать на клавишу Y?

Не обязательно. Потому что все команды рассматриваемого класса имеют ещё опцию -f (в «длинной» своей форме, —force, она также практически универсальна для большинства команд). Которая, отменяя действие опции -i, предписывает принудительно переписать все файлы целевого каталога их обновленными тезками. И никто не мешает нам на этот случай создать ещё один псевдоним для команды cp, например:

$ alias cpf=’cp -f’

Правда, предварительно нужно убедиться, что в системе нет уже команды с именем, совпадающим с именем псевдонима — иначе эффект может быть весьма неожиданным (впрочем, это относится ко всем псевдонимам, не совпадающим с именами подменяемых команд).

Есть и другой способ обойти опции, установленные для команды-псевдонима: просто отменить псевдоним. Что делается командой обратного значения

$ unalias alias_name

То есть дав директиву

$ unalias cp

мы вернем команде копирования ее первозданный смысл. Ну а узнать, какие псевдонимы у нас определены в данный момент, и каковы их значения, ещё проще: команда

$ alias

без опций и аргументов выведет полный их список:

la=’ls -A’

less=’less -M’

li=’ls -ial’

ll=’ls -l’

ls=’ls -F —color=auto’

и так далее.

Когда я сказан о пользовании псевдонимами ныне, и присно, и вовек, — то был не совсем точен. Ныне, то есть в текущем сеансе пользователя — да, они работают. Однако после рестарта системы (или просто после выхода из данного экземпляра командной оболочки) они исчезнут без следа. Чтобы заданные псевдонимы увековечить, их нужно прописать в конфигурационном файле пользовательского шелла. Но этим мы займемся впоследствии. А пока обратимся к переменным.

Переменные

Переменные играют для аргументов команд примерно такую же роль, что и псевдонимы — для команд. То есть избавляют от необходимости мрачного ввода повторяющихся последовательностей символов. Конечно, это — далеко не единственное (а может быть, и не главное) назначение переменных, однако на данном этапе для нас наиболее существенное.

Что такое переменная? Ответ просто — некоторое имя, которому присвоено некоторое значение. Не очень понятно? — Согласен. Но, возможно, станет яснее в дальнейшем.

Имена переменных в принципе могут быть любыми, хотя некоторые ограничения также существуют. Я уже вскользь упоминал о переменных в разговоре про пути к файлам, где фигурировала переменная PATH. Когда дело дойлёт у нас до пользовательских аккаунтов, придётся поговорить о переменных SHELL, USER, HOME.

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

Таких встроенных переменных довольно много. Одна из первых по значению — всё та же переменная PATH. Это — список каталогов, в которых оболочка, в ответ на ввод пользователя в командной строке, ищет исполнимые файлы — то есть просто команды. Я уже обращал внимание, что во всех приведённых выше примерах имена команд указывались без всяких путей к ним (в отличие от файлов-аргументов, путь к которым — обязателен). Так вот, успех её поисков и определяется списком значений переменной PATH. Каковые могут быть просмотрены командой echo:

$ echo $PATH

Обратим внимание на то, что в качества аргумента команды выступает не просто имя переменной, а оно же, но предваренное символом доллара. Который в данном случае никакого отношения к приглашению командной строки не имеет, а предписывает команде echo подменить имя переменной ее значением (значениями). В большинстве дистрибутивов Linux случае вывод команды для пользователя будет в обязательном порядке включать такие каталоги:

/bin:/usr/bin:/usr/local/bin

Для администратора системы сюда обязательно добавятся каталоги /sbin, /usr/sbin и /usr/local/sbin. Остальные значения переменной PATH могут варьировать по умолчанию, а также задаваться пользователем (как — поговорим позже).

Обратим вниммание на одно важное обстоятельство: практически во всех дистрибутивах Linux и в более иных ОС в перечне значений переменной PATH  отсуствует текущий каталог

Тем временем вернемся к переменной HOME. Значение ее — полный абсолютный путь к домашнему каталогу пользователя. То есть, чтобы перейти в него, пользователю по имени alv вместо

$ cd /home/alv

достаточно набрать

$ cd $HOME

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

Кроме переменных, предопределенных в шелле, пользователю предоставляется почти полная свобода в определении переменных собственных. И вот тут-то и наступает ему обещанное облегчение при наборе аргументов команд.

Предположим, что у нас имеется глубоко вложенный подкаталог с данными, постоянно требующимися в работе. Чисто условно примем, что путь к нему — следующий:

/home/alv/data/all.my.works/geology/plate-tectonics

Весьма удручающе для набора, даже если исправно работать табулятором для автодополнения, не так ли? Прекрасно, упрощаем себе жизнь определением переменной:

$ plate=/home/alv/data/all.my.works/geology/plate-tectonics

Дело в шляпе, Теперь, если нам нужно просмотреть состав этого каталога, достаточно будет команды

$ ls $plate

А вызвать из него любой файл для редактирования можно так:

$ joe $plate/filename

Подобно псевдонимам, переменные, определенные таким образом (то есть просто в командной строке), имеют силу только в текущем сеансе работы — по выходе из оболочки они утрачиваются. Для того, чтобы они действовали перманентно, переменные должны быть прописаны в конфигурационном файле пользовательского шелла. Однако, в отличие от псевдонимов, и этого оказывается не всегда достаточно. Ибо переменная, определенная посредством

$ NAME=Value

работает не просто только в текущем сеансе — но ещё и только в конкретном экземпляре шелла. Почему и называется переменной оболочки — shell variable. Звучит это. быть может, пока не очень понятно. Однако практически любое действие в шелле — запуск команды или программы, например, — начинается с того, что оболочка, в которой это действие совершается, запускает новый экземпляр самой себя — дочерний шелл, или, как иногда говорят, субшелл.

Так вот, этот самый субшелл не наследует переменные родительской оболочки. И в итоге запущенная из командной строки программа ничего не будет знать, например, о путях к исполняемым файлам. Что автоматически ведет к невозможности запуска из нее команд просто по имени, без указания точного пути.

Чтобы избежать такой неприятной ситуации, было придумано понятие переменных окружения, или переменных среды — environment variable. Это — те переменные, которые наследуются от родительского шелла всеми дочерними программами. И чтобы сделать их таковыми, переменные следует экспортировать. Как? Командой export, которая может быть применена двояким образом. Можно сначала определить переменную:

$ NAME=Value

а затем применить к ней команду export:

$ export NAME

А можно сделать это в один прием:

$ export NAME=Value

Второй способ применяется, если нужно определить и экспортировать одну переменную. Если же за раз определяется несколько переменных:

$ NAME1=Value1;

$ NAME2=Value2;

…;

$ NAMEN=ValueN

то проще прибегнуть к первому способу, так как команда export может иметь сколько угодно аргументов:

$ export NAME1 NAME2 … NAMEN

Традиционно имена переменных окружения задаются в верхнем регистре, переменных оболочки — в нижнем.

Навигация и редактирование

Имя команды, ее опции и аргументы образуют т.н. командные «слова». В качестве словоразделителей выступают пробелы. Кроме того, как разделители «слов» интерпретируется ряд специальных символов — прямой слэш (/) — элемент пути к файлу, обратный слэш (\), служащий для экранирования специальных символов, и операторы командных конструкций, о которых будет сказано ниже.

В некоторых случаях имеет смысл различать «большое слово» и «малое слово». Первые разделяются пробелами, в качестве же вторых интерпретируются символы, лежащие между всеми другими словоразделителями.

Подчеркнем, что командное «слово» прямо не соотносится ни с опциями, ни с аргументами команды. Введение этого понятия призвано просто облегчить навигацию в командной строке и ее редактирование.

Ибо одно из великих достижений командного интерфейса POSIX-систем, заценить которое могут в полной мере только те, кто застал времена «черного DOS’а», — это возможность перемещёния внутри командной строки и внесения необходимых изменений в имя команды, ее опции и аргументы. Делается это различными способами.

Самый привычный и, казалось бы, очевидный способ — использование клавиш перемещёния курсора Left, Right, End и Home, действующих (хотя и не всегда) в командной строке точно так же, как и в каком-нибудь ворд-процессоре для Windows (клавиши Up, Down, PageUp, PageDown зарезервированы для других целей). То есть они позволяют перемещаться на один символ влево и вправо. в начало и конец командной строки. А если добавить сюда ещё клавиши Delete и Backspace, позволяющие удалять символы в позиции курсора или перед ней — то, казалось бы, чего ещё желать?

Оказывается — есть чего, и самый очевидный способ навигации и редактирования оказывается не самым эффективным. Для начала заметим, что в общем случае привычные клавиши перемещёния курсора и редактирования в POSIX-системах не обязаны работать также, как они делают это в DOS/Windows. Это зависит от многих причин, в том числе и исторических. Ведь POSIX-системы по определению предназначены работать на любых практически машинах (в том числе и на тех, клавиатуры которых клавиш управления курсором просто не имели).

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

Управляющие последовательности

Основные управляющиеся клавиши, которые используются в таких последовательностях (и имеются на клавиатурах почти любых машин — как говорят в таких случаях, в любых типах терминалов) — это клавиши Control и Meta.

Пардон — возразит внимательный читатель, — сколько я ни долблю по клавишам моей PC’шки, но клавиши Meta не замечал. Возражение принято, но: на PC-клавиатурах функции Meta выполняют либо а) нажатие и отпускание клавиши Escape, либо б) нажатие и удерживание клавиши Alt.

Впрочем, к этой теме я ещё вернусь. А пока достаточно нескольких простых рецептов, практически универсальных для любых командных оболочек в терминалах любых типов.

Рецепт первый: большая часть управляющих последовательностей состоит из сочетания клавиши Control и алфавитно-цифрового символа. Под сочетанием (или комбинацией, для чего я уже употреблял ранее символ плюс) понимается то, что, удерживая нажатой клавишу Control, мы одновременно нажимаем и какую-нибудь литерную или цифровую.

Так, действие клавишной комбинации Control+F (от Forward — в большинстве случаев регистр алфавитной клавиши управляющей последовательности значения не имеет) эквивалентно нажатию клавиши Right — это перемещёние на один символ вправо, комбинации Control+B (от Back) — нажатию Left (перемещёние на один символ влево). Комбинации Control+A и Control+E действуют аналогично Home и End, перемещая курсор в начало и конец командной строки, соответственно, Ну а с помощью комбинаций Control+D и Control+H можно удалить единичный символ в позиции курсора или перед ней (также, как и клавишами Delete и Backspace, соответственно).

Предвижу резонный вопрос: а какие достоинства в комбинации клавиш Control+Что_то по сравнению с элементарными End или Left? Конечно, одно достоинство — очевидно: при массовом вводе команд (а также, забегая вперед, замечу — и любых иных наборов символов, от исходных текстов до романов), при использовании keybindings руки не отрываются от основной (алфавитно-цифровой) части клавиатуры. И в итоге, по приобретении некоторого минимального навыка, дело движется ну гораздо быстрее. Обосновать тестами не могу (тут какая-нибудь физиометрия понадобится), но не верящим — предлагаю попробовать.

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

Например, комбинация Meta+F смещает курсор на одно «слово» вперед, та же Meta в сочетании с B — на одно слово назад, и так далее. Прошу обратить внимание: действие алфавитной клавиши в комбинации с Meta сходно по смыслу ее сочетанию с клавишей Control, но как бы «усилено»: последовательность Meta+D уничтожает не символ в позиции курсора, как это было бы для D в сочетании с Control, а все командное «слово».

Рассматривать ключевые последовательности подробно здесь я не буду: детали их действия зависят от командной оболочки и ее настроек. Отмечу только два существенных обстоятельства. Первое: keybindings предоставляют пользователю полный комплекс приемов для любых действий в командной строке — вплоть до преобразования регистров уже введенных символов и «слов» (из нижнего в верхний и наоборот), «перетасовки» символов в команде или ее аргументах, и так далее.

Значение управляющих последовательностей не ограничивается командной строкой — большинство популярных в POSIX-мире текстовых редакторов, от простых Nano или joe до грандиозного vim и монструозного emacs. построены по тому же принципу. Так что навыки, полученные при работе с keybindings, например, в Bash, весьма поспособствуют виртуозному освоению любого из этих инструментов.

И второе — действие ключевых последовательностей, как правило. не зависит не только от типа терминала и физического устройства клавиатуры, но и от ее раскладки — при переключении на кириллицу они будут работать столь же справно, как и в латинице.

История команд

Возможности навигации и редактирования строки особенно ярко проявляются в сочетании с другой замечательной особенностью, предоставляемой командными оболочками — доступом к истории команд. То есть: раз введенная в строке команда не уходит в небытие после исполнения, а помещается в специальный буфер памяти. Который, как и все в Unix’ах, именуется весьма незатейливо — буфер истории команд. Откуда команда (со всеми её опциями и аргументами) может быть извлечена для повторного использования. Или — для редактирования и исполнения в новой реинкарнации.

Буфер истории команд сохраняется в течении всего сеанса работы. Однако в большинстве случаев командные оболочки настраиваются так, что по выходе из сеанса буфер истории сохраняется в специальном файле в домашнем каталоге пользователя, и таким образом его содержимое оказывается доступным при следующем запуске шелла. Имя этого файла может быть различным в разных оболочках, но обычно включает компонент history (в Bash — ~/.bash_history).Так что, можно сказать, что введенным нами командам суждена вечная жизнь.

Конечно, не совсем вечная. И размер буфера истории команд, и количество строк в файле истории — величины конечные. Так что, если установленный предел превышен, то старые команды вытесняются более новыми. Однако и величину буфера, и количество строк в файле истории можно установить любыми. Разумеется, в разумных пределах — не знаю, существует ли принципиальное ограничение на их размер, за исключением объёма памяти и дискового пространства. А если учесть, что и из буфера, и из памяти с помощью соответствующих настроек (со временем я расскажу, каких) можно исключить дубликаты и ещё кое-какой мусор — то мое заявление о вечной жизни команд не выглядит столь уж преувеличенным.

Универсальное средство доступа к буферу истории команд — специальная команда, встроенная во все шеллы, таковой поддерживающие — history (в большинстве дистрибутивов Linux она по умолчанию имеет псевдоним — h). Данная без опций, эта команда выводит полный список команд в их исторической (издревле к современности) последовательности, или некоторое количество команд, определенных соответствующими настройками (о которых будет говориться позднее).

В качестве опции можно указать желаемое количество одновременно выведенных команд. Например, директива

$ history -2

выведет две последние команды из буфера истории вместе с их номерами:

1023  joe shell.html

1024  less ~/.zshrc

Любая из команд в буфере истории может быть повторно запущена на исполнение. Для этого достаточно набрать в командной строке символ ! (восклицательный знак) и затем, без пробела — номер команды в списке буфера. Например,

$ !1023

для приведенного выше примера повторно откроет файл shell.html в текстовом редакторе joe.

Другой способ доступа к командам из буфера истории — комбинации клавиш Control+P и Control+N, служащие для последовательного его просмотра (как бы «пролистывания») назад и, соответственно, вперед (разумеется, если есть куда). Они дублируются клавишами управления курсором Up и Down (назад и вперед, соответственно). Кроме того, последовательности Meta+< и Meta+&rt; обеспечивают переход к первой и последней команде в буфере истории.

Любая извлеченная (с помощью стрелок или управляющими последовательностями) из буфера истории в текущую строку команда может быть повторно запущена на исполнение — нажатием клавиши Enter или дублирующей ее комбинацией Control+M. причём предварительно ее можно отредактировать — изменить опции, или аргументы, — точно так же, как и только что введенную.

Поиск в истории

Во всех современных «развитых» шеллах предусмотрены средства поиска команды в буфере истории — простым перебором (обычно Meta+P — назад и Meta+N — вперед).

Впрочем, не смотря на громкое название, обычный поиск ничем практически не отличается от пролистывания исторического списка курсорными стрелками. Что при обширной истории команд может быть весьма утомительным. И потому для ее облегчения предусмотрена такая интересная возможность, как наращиваемый поиск (incremental search) нужной команды в буфере истории по одному (или нескольким) из составляющих ее символов.

Выполняется инкрементный поиск так: после нажатия (при пустой командной строке) клавишной комбинации Control+R появляется предложение ввести алфавитный символ (или — последовательность символов произвольной длины), заведомо входящий в состав требуемой команды:

$ bck-i-search: _

Ввод такого символа выведет последнюю из команд, его содержащих. При этом введенный символ будет отмечен знаком курсора. Он не обязан входить в имя команды, но может быть составляющим ее опций или аргументов (имени файла или пути к нему, например). Следующее нажатие Control+R зафиксирует курсор на предыдущем символе, в пределах этой же или более ранней по списку команды, и т.д. Однако вместо этого в строке поиска можно вводить дополнительные символы, детализирующие условия поиска команды (или — ее опций и аргументов).

Процедуру поиска можно продолжать вплоть до достижения требуемого результата — то есть нахождения той команды, которая нужна именно сейчас. Нажатие клавиши Enter в любой из этих моментов запускает найденную (то есть помещённую в командную строку) команду на исполнение, с завершением поиска. Поиск обрывается также и нажатием комбинации Control+C. Перед запуском найденная команда может быть отредактирована стандартными средствами — с использованием управляющих последовательностей.

Регулярные выражения

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

Собственно говоря, этой цели служили почти все приемы, описанные выше. Осталось осветить немногое. А именно — регулярные выражения, реализуемые с помощью т.н. специальных символов (или метасимволов).

Элементарная, и весьма частая, в духе школьных, задача: из каталога dir1 требуется скопировать все файлы в каталог dir2. Так неужели все они должны быть перечислены в качестве аргументов команды cp? Нет, нет, и ещё раз нет. Ибо для этой цели придуманы шаблоны имен файлов. Самый часто используемый из них — специальный символ * (вроде бы я о нем уже говорил?). Он подменяет собой любое количество любых символов (в том числе — и нулевое, то есть отсутствие символов вообще). То есть для решения предложенной задачи нам достаточно дать команду:

$ cp dir1/* dir2

Чуть усложним условия: к копированию из dir1 предназначены не все файлы, а только html-документы, традиционно имеющие суффикс html. Решение от этого не становится сложнее:

$ cp dir1/*html dir2

Однако тут можно вспомнить, что html-документы могут иметь и расширение htm. Не пропустим ли мы их таким образом при копировании? Таким — безусловно, пропустим. Однако нам на помощь придет другой шаблон — символ ?. А соответствует он любому единичному символу (или — его отсутствию, т.е. символу null). И значит, если команда из примера будет модифицирована таким образом:

$ cp dir1/*htm? dir2

то она гарантированно охватит все возможные маски html-документов.

Вроде все хорошо. Однако нет: из каталога dir1 нам нужно скопировать только три определенных файла — file1, file2, file3. Не придется ли каждый из них указывать в командной строке с полным путем (а ведь они могут быть и в глубоко вложенном подкаталоге типа dir1/dir11/dir111)? Все равно не придется, на столь хитрую… постановку задачи у нас есть прием с левой резьбой — символы группировки аргументов, обозначаемые фигурными скобками. Что на практике выглядит так:

$ cp path/{file1,file2,file3} dir2

И приведет к единоразовому копированию всех трех файлов в каталог dir2. Заметим, что сгруппированные аргументы разделяются запятыми без пробелов. И ещё: в оболочке Bash группируемые аргументы придется полностью вводить руками. Но вот в Zsh на них распространяется возможность автодополнения, да и запятая после каждого имени появляется автоматически (и столь же автоматически исчезает при закрытии фигурной скобки).

Группировка аргументов может быть сколь угодно глубоко вложенной. Так, команда

$ mkdir -p dir1/{dir11/{dir111,dir112},dir12/{dir121,dir122}}

в один заход создаст трехуровневую структуру каталогов внутри текущего — если только не забыть про опцию -p, которая предписывает создавать промежуточные подкаталоги в случае их отсутствия.

И ещё несколько примеров. Регулярное выражение для диапазона — то есть вида […], подменяет любой из символов, заключенных в квадратные скобки. Символы эти могут даваться списком без пробелов (например, выражение [12345] соответствует любому символу от 1 до 5) или определяться в диапазоне, крайние значения которого разделяются дефисом без пробелов (эквивалентное первому выражение — [1-5]). Кроме того, символ ^, предваряющий список или диапазон, означает отрицание: выражение [^abc] подменяет любой символ, исключая символы a, b и c.

Последние примеры регулярных выражений могут показаться надуманными. Однако представим. что в том же каталоге dir1, кроме html-документов, содержатся также файлы изображений в различных форматах — GIF, JPEG, TIFF и так далее (традиционно имеющие одноименные расширения). И все они должны быть скопированы в каталог dir2, а вот как раз html-файлы нам в данный момент без надобности. No problemas, как говорят у них:

$ cp dir1/*[^html] dir2

И в каталоге dir2 окажется все содержимое каталога dir1, за исключением html-файлов.

Экранирование

Из приведённых примеров можно видеть, что метасимволы, образующие регулярные выражения, интерпретируются командной оболочкой особым образом, не так, как обычные алфавитно-цифровые символы, составляющие, скажем, имена файлов.

В то же время собственно POSIX-системы накладывают на имена файлов очень мало ограничений. И в принципе система не запретит вам создать файл с именем, содержащим метасимволы. Другое дело, что работать с таким образом именованными файлами может быть сложно — командная оболочка будет пытаться интерпретировать их в соответствии с правилами для регулярных выражений.

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

Вспомним, что MS Word в качестве имени файла спокойно берёт первую фразу документа. А если это — вопрос? И тогда завершающий имя символ ? будет в шелле интерпретироваться как шаблон, а не как элемент имени. Думаю, не нужно обладать очень развитым воображением, чтобы представить последствия. Что делать в таких ситуациях? Для их разрешения резонными людьми придумано было понятие экранирования.

Начнём с первого примера использования экранирования — разрыва длинных строк. Командные директивы, с многочисленными их опциями, особенно в полной форме, и аргументами могут оказаться весьма длинными, не укладывающимися в пределы экранной строки. Правда, обычно командная оболочка по умолчанию настраивается с разрешением так называемого word wrapping‘а (то есть переноса «слов» команды без обрыва строки — последнее, как мы помним, достигается нажатием клавиши Enter или комбинации Control+M и приводит к немедленному исполнению введённой команды. Если ввод ее не окончен — последует сообщение об ошибке). Однако перенос «слов» при этом происходит, как бог на душу положит. И в результате командная директива теряет читабельность и становится сложной для понимания.

Тут-то и приходит на помощь понятие экранирования, упомянутое абзацем выше. Знак экранирования — обратный слэш (\), — превращает символ, имеющий специальное значение, например, упоминавшийся ранее шаблон в именах файлов — *, в самую обычную звездочку. А раз конец строки — тоже символ, хотя и специальный, то и он доступен для экранирования. Так что если завершить введённый фрагмент команды обратным слэшем (некоторые оболочки требуют предварить его пробелом, и лучше так и делать, хотя в Bash или Zsh пробел не обязателен), после чего нажать Enter, то вместо попытки исполнения будет образована новая строка. в которой можно продолжать ввод. Вид приглашения к вводу при этом изменится — это будет так называемое вторичное приглашение командной строки, и его представление настраиваемо, также как и вид приглашения первичного.

Возвращаемся к экранированию обратным слэшем. Действие его распространяется только на непосредственно следующий за ним символ. Если символы, могущие быть воспринятые как специальные, идут подряд, каждый из них должен предваряться обратным слэшем.

У обратного слэша есть ещё одна интересная особенность — я назвал бы ее инвертированием специального значения символов. Для примера: некая последовательность цифр (например, 033), введенная в командной строке, будет воспринята как набор обычных символов. Однако она же может выступать как код какого-либо символа (в частности, 033 — код символа Escape в восьмеричной системе счисления). И подчас возникает необходимость ввода таких кодов (тот же код для Escape, скажем, затруднительно ввести каким-либо иным образом).

И вот тут обратный слэш проявляет свое инвертирующее действие: последовательность \033 будет восприниматься уже не как набор символов, а как код символа Escape (обратим внимание, что тут достаточно единичного слэша). Непосредственно в командной строке такой способ инвертированного экранирования, по понятным причинам, обычно не используется, но находит широкое применение в сценариях.

О кавычках

Есть и экраны, распространяемые на все, что заключено внутри них. Это — кавычки, двойные и одинарные: большая часть символов между ними утрачивает свое специальное значение. Но не все: в двойных кавычках сохраняют специальное значение метасимволы $ и \, а также обратные кавычки (`), о назначении которых я скажу чуть позже. То есть в них сохраняется возможность, с одной стороны, получения значений переменных (как мы помним, с помощью $ИМЯ). А с другой стороны, если нам требуется дать символ бакса в его прямом и привычном значении, у нас есть возможность заэкранировать его обратным слэшем. И если потребуется вывести на экран сообщение «с вас, уважаемый, пятьсот баксов», то это можно сделать таким образом:

$ echo «с вас, уважаемый, \$500»

ещё одно широко применяемое использование двойных кавычек — экранирование пробелов, предотвращающих разбиение аргументов команды на отдельные «слова». Правда, в случае с командой echo это, как правило, не требуется (хотя настоятельно рекомендуется экранировать ее аргумент таким образом). Однако представьте, что в качестве аргумента команды копирования и перемещёния выступает файл, переписанный с Windows-машины. Ведь там пробелы в именах — вещь обычная. Тут-то экранирование двойными кавычками и придется к месту.

Из сказанного понятно, почему двойные кавычки именуются ещё неполными, или не строгими — они все же допускают внутри себя использование символов со специальными значениями. В противоположность им, кавычки одинарные носят имя строгих, или полных. Потому что между ними утрачивают специальное значение все метасимволы, кроме их самих — в том числе и символ единичного экранирования. В итоге они используются там, где гарантированно требуется отсутствие специальных символов. Если вы помните, мы применили строгие кавычки при установке псевдонимов. Они же часто оказываются обязательными при определении переменных.

Завершая тему экранирования, осталось сказать только об обратных кавычках. Их функция очень узка: они служат для экранирования команд. То есть, скажем, команда

$ echo date

в полном соответствие со своим именем, просто выведет нам собственный аргумент:

date

Однако если аргумент команды закрыть обратными кавычками, то date будет воспринято как имя команды, подлежащей исполнению. И результат этого исполнения (то есть текущая дата и время — а именно для их получения и предназначена команда date) будет замещать имя команды в выводе echo:

$ echo `date`

Втр Дек 16 11:45:12 MSK 2003

Если вспомнить, что обратные кавычки сохраняют свое специальное значение внутри кавычек двойных, становится ясной польза от их применения: они незаменимы в тех случаях, когда требуется вывод результатов работы одной команды внутри другой. К как в нашем примере с выводом даты, если его (вывод) следует включить в некое выдаваемое командой echo сообщение.

Конечно, в описанном случае добиться той же цели можно было бы гораздо легче — просто командой date. Однако представьте, что у нас возникло желание одновременно и получить сведения о количестве пользователей в системе (для чего предназначена команда who). Тут-то и выясняется. что проще всего это сделать командой типа следующей:

$ echo «На момент `date` в системе

        зарегистрированы `who`»

Ответом на что будет сообщение, подобное тому, что часто можно наблюдать на главной странице многих сайтов:

На момент Сб. дек. 20 06:05:56 MSK 2014 в системе

зарегистрированы alv      tty8         2014-12-15 00:34 (:0)

alv      pts/1        2014-12-15 00:34 (:0)

alv      pts/5        2014-12-19 09:37 (:0)

А теперь последнее, чем и закроем тему регулярных выражений вообще. В этом разделе рассматривалось использование метасимволов в командной оболочке (конкретно, в данном случае. в Dash, Bash и Zsh). В других оболочках применение метасимволов и условия их экранирования могут несколько отличаться. И к тому же многие запускаемые из строки шелла команды могут иметь свои правила построения регулярных выражений. Так что в итоге их форма определяется сочетанием особенностей конкретной оболочки и команды, из неё запущенной. Все это при необходимости будет оговариваться в дальнейшем.

А пока переходим к рассмотрению командных конструкций — одной из тех особенностей CLI, которая определяет мощь и универсальность этого интерфейса.

Вводные слова о командных конструкциях

Надеюсь, из того, что было рассказано на предшествующих страницах, посвящённых CLI, читателю стало ясно, что подавляющее большинство команд в POSIX-системах очень просты по сути и предназначены для выполнения какого-либо одного элементарного действия.

То есть команда cp умеет только копировать файлы, команда rm — только удалять их, но зато делают они это хорошо. Подчас — через чур хорошо, что мог ощутить на себе каждый, кому «посчастливилось» по ошибке выдать директиву вроде

$ rm -Rf *

Для тех, кто не испытал этого волнительного ощущения, поясню: результатом будет полное и безвозвратное уничтожение всех файлов от текущего каталога вниз (включая подкаталоги любой степени вложенности).

А если задать ту же команду от лица администратора, то, в зависимости от текущего положения на файловом древе, можно нечувствительно удалить что угодно, вплоть до системы целиком: одна из причине, почему повседневные действия не следует выполнять под root’ом.

Собственно, разделение любой задачи на серию элементарных операций — это и есть основной принцип работы в POSIX-системах, тот самый пресловутый Unix-way, о котором столько говорят его приверженцы.

Однако вслед за этапом решительного размежевания (эх, неистребимы в памяти нашего поколения слова товарища Ленина) должен наступить этап объединения, как за анализом явления следует синтез эмпирических данных о нём. И целям такого объединения служат командные конструкции.

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

Совместное выполнение команд

Простейшая командная конструкция — это выполнение команды в фоновом режиме, что вызывается вводом символа амперсанда после списка опций и (или аргументов):

$ command [options] [arguments] &

В Bash и Zsh пробел перед символом амперсанда не обязателен, но в некоторых шеллах он требуется, и потому лучше возвести его ввод (как и во всех аналогичных случаях) в ранг привычки. После этого возвращается приглашение командной строки и возможен ввод любых других команд (в том числе и фоновых). Команды для параллельного исполнения можно задать и в той же строке:

$ command1 & command2 & … & commandN

В результате все команды, перечисленные в строке, кроме той, что указана последней, будут выполняться в фоновом режиме.

Существуют и конструкции для последовательного выполнения команд. Так, если ряд команд разделен в строке символом точки с запятой (;)

$ command1 ; command2 ; … ; commandN

то сначала будет выполнена команда command1, затем — command1 и так далее. Молчаливо предполагается, что каждая из этих команд может иметь любое количество опций и аргументов. И, опять-таки, обрамление ; пробелами не обязательно во многих командных оболочках. Сами по себе команды не обязаны быть связанными между собой каким-либо образом — в сущности, это просто эквивалент последовательного их ввода в командной строке:

$ command1

$ command2

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

Однако возможна ситуация, когда результаты предыдущей команды из такой конструкции используются в команде последующей. В этом случае ошибка исполнения любой составляющей команды, кроме последней, делает невозможным продолжение работы всей конструкции. Что само по себе было бы ещё полбеды — однако в некоторых ситуациях исполнение последующей команды возможно только при условии успешного завершения предыдущей.

Характерный пример — сборка программы из ее исходных текстов, включающая три стадии — конфигурирование, собственно компиляцию и установку собранных компонентов. Что обычно выполняется последовательностью из трёх команд:

$ ./configure

$ make

$ make install

Ясно, что если конфигурирование завершилось ошибкой, то компиляция начаться не сможет и, соответственно, потом нечего будет устанавливать. И потому объединение их в последовательную конструкцию вида

$ ./configure ; make ; make install

может оказаться нецелесообразным.

Однако для предотвращения таких ситуаций в конструкции из взаимосвязанных команд существует другой оператор, обозначаемый удвоенным символом амперсанда — &&. Он указывает, что последующая команда конструкции должна исполняться только в том случае, если предыдущая завершилась успешно:

$ ./configure && make && make install

На практике обе приведённые в качестве примера конструкции дадут один и тот же результат — разумеется, если все составляющие их команды будут выполнены без ошибок. Однако в ряде иных случаев различие между этими конструкциями может быть существенным.

Впрочем, предусмотрена и командная конструкция, в которой последующей команде предписано исполняться в том и только в том случае, если предыдущая команда завершилась неудачно. Она имеет вид

$ command1 || command2

и может служить, в частности, для вывода сообщений об ошибках.

Перенаправление

Следующая командная конструкция — это так называемое перенаправление ввода/вывода. Чтобы понять,что это такое, нужно помнить две вещи:

  1. любая команда получает данные для своей работы (например, список опций и аргументов) со стандартного устройства ввода (которым в первом приближении будем считать клавиатуру), а результаты своей работы представляет на стандартном устройстве вывода (коим договоримся считать экран монитора);

  2. POSIX-системах любое устройство — не более чем имя специального файла, именуемого файлом устройства.

Таким образом, ничто не запрещает нам подменить специальный файл устройства ввода или устройства вывода любым иным файлом (например, обычным текстовым). Откуда и будут в этом случае браться входные данные или куда будет записываться вывод команды.

Перенаправление вывода команды обозначается следующим образом:

$ command > filename

или

$ command >> filename

В первом случае (одиночный символ >) вывод команды command образует содержимое нового файла с именем filename, не появляясь на экране. Или, если файл с этим именем существовал ранее, то его содержимое подменяется выходным потоком команды (точно также, как при копировании одного файла в другой, уже существующий). Почему такое перенаправление называется замещающим (или перенаправлением в режиме замещёния).

Во втором же случае (двойной символ >>) происходит добавление вывода команды command в конец существующего файла filename (при отсутствии же его в большинстве случаев просто образуется новый файл). И потому это называется присоединяющим перенаправлением, или перенаправлением в режиме присоединения.

Перенаправление ввода выглядит так:

$ command < filename

Простейший случай перенаправления вывода — сохранение результата исполнения команды в обычном текстовом файле. Например, конструкция

$ ls dir1 > list

создаст файл, содержанием которого будет список файлов каталога dir1. А в результате выполнения конструкции

$ ls dir2 >> list

к этому списку добавится и содержимое каталога dir2.

При перенаправлении ввода команда получает данные для своей работы из входящего в командную конструкцию файла. Например, конструкция

$ sort < list

выведет на экран строки файла list, отсортированных в порядке возрастания значения ASCII-кода первого символа, а конструкция

$ sort -r < list

осуществит сортировку строк того же файла в порядке, обратном алфавитному (вернее, обратном порядку кодов символов, но это нас в данном случае не волнует).

В одной конструкции могут сочетаться перенаправления ввода и вывода, как в режиме замещёния, так и в режиме присоединения. Так, конструкция

$ sort -r < list > list_r

не только выполнит сортировку строк файла list (это — назначение команды sort) в обратном алфавитному порядке (что предписывается опцией -r, происходящей в данном случае от reverce), но и запишет ее результаты в новый файл list_r, а конструкция

$ sort -r < list >> list

добавит по-новому отсортированный список в конец существующего файла list.

Конвейеры

Возможности построения командных конструкций не ограничиваются перенаправлением ввода/вывода: результаты работы одной команды могут быть переданы для обработки другой команде. Это достигается благодаря механизму программных каналов (pipe) или конвейеров — последний термин лучше отражает существо дела.

При конвейеризации команд стандартный вывод первой команды передается не в файл, а на стандартный ввод следующей команды. Простой пример такой операции — просмотр списка файлов:

$ ls -l | less

Перенаправление вывода команды ls, то есть списка файлов, который при использовании полного формата записи (опция -l) может занимать многие экраны, на ввод команды less позволяет просматривать результат с ее помощью постранично или построчно в обоих направлениях.

Конвейеризация команд может быть сколь угодно длинной. Возможно также объединение конвейеризации команд и перенаправления в одной конструкции. Кроме того, команды в конструкции могут быть сгруппированы с тем, чтобы они выполнялись как единое целое. Для этого группа команд разделяется символами ; и пробелами, как при последовательном выполнении команд, и заключается в фигурные скобки. Так, если нам требуется перенаправить вывод нескольких команд в один и тот же файл, вместо неуклюжей последовательности типа

$ command1 > file ; command2 >> file ; … ; commandN >> file

можно прибегнут к более изящной конструкции:

$ { command1 ; command2 ; … ; commandN } > file

Как и многие из ранее приведённых примеров, этот может показаться надуманным. Однако представьте, что вам нужно создать полный список файлов вашего домашнего каталога, разбитый по подкаталогам, да ещё и с комментариями, в каком подкаталоге что находится. Конечно, можно вывести состав каждого подкаталога командой ls, слить их воедино командой cat (она предназначена, в частности, и для объединения — конкатенации, — файлов, и речь о ней будет позже), загрузить получившееся хозяйство в текстовый редактор или ворд-процессор, где добавить необходимые словеса. А можно — обойтись единой конструкцией:

$ { echo «List of my files» ;  > echo «My text» ;

        ls text/* ;  > echo «My images» ;

        ls images/* ;  > echo «My audio» ;

        ls audio/* ;  > echo «My video» ;

        ls video/* } > my-filelist

И в результате получить файл такого (условно) содержания, которое мы для разнообразия просмотрим с помощью только что упомянутой команды cat (благо и для просмотра содержимого файлов она также пригодна):

$ cat my-filelist

List of my files

My text

text/text1.txt text/text2.txt

My images

images/img1.tif images/img2.tif

My audio

audio/sing1.mp3 audio/sing2.mp3

My video

video/film1.avi video/film2.avi

Понятие о фильтрах

С понятием командных конструкций тесно связано понятие программ-фильтров. Это — команды, способные принимать на свой ввод данные с вывода других команд, производить над ними некоторые действия и перенаправлять свой вывод (то есть результат модификации полученных данных) в файлы или далее по конвейеру — другой команде.

Программы-фильтры — очень эффективное средство обработки текстов, и в своё время мы к ним вернемся для подробного изучения. Пока же важно отметить, что в качестве фильтров могут работать не все команды. Например, команды find или grep фильтруют имена файлов или фрагменты их содержимого, а команда ls фильтром не является.

Сценарии оболочки

Наш затянувшийся разговор о командах и командном интерфейсе подходит к концу. И в заключение этого раздела — ещё немного терпения. Потому что было бы несправедливо не уделить чуть-чуть места тому, что придает командному интерфейсу POSIX-систем его несравненную гибкость и универсальность. Заодно способствуя закоснению пользователя в смертном грехе лености. Итак — слово о сценариях оболочки.

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

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

В самом простом случае сценарий — это просто одна или несколько команд или (и) командных конструкций с необходимыми опциями и аргументами, сохраненные в виде обычного именованного текстового файла. И предназначены они в первую очередь для автоматизации часто исполняемых рутинных операций, в частности, ввода длинных последовательностей в командной строке.

Создание пользовательского сценария — просто, как правда. Для этого всего и нужно:

  • создать командную конструкцию, достойную увековечивания;

  • поместить ее в простой текстовый файл;

  • по потребности и желанию снабдить комментариями;

  • тем или иным способом запустить файл на исполнение.

С принципами создания команд и командных конструкций мы в первом приближении разобрались раньше. А вот способов помещёния их в файл существует множество. Можно просто ввести (или вызвать из буфера истории) нужную команду и оформить ее как аргумент команды echo, вывод которой перенаправить в файл:

$ echo «cp -rf workdir backupdir» > mybackup

Таким образом мы получили простейший скрипт для копирования файлов из рабочего каталога в каталог для резервного хранения данных, что впредь и будем проделывать регулярно (не так ли?).

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

$ cat > myarchive

и нажимаем Enter. После этого команда остается в ожидании ввода данных для помещёния их в новообразованный файл. Не обманем ее ожиданий и проделаем это. причём можно не жаться и выполнить ввод в несколько строк, например:

cd $HOME/archivedir tar cf archive.tar

        ../workdir gzip archive.tar

Завершив ввод тела скрипта, все той же клавишей Enter открываем новую строку и набираем комбинацию Control+D, выдающую символ окончания файла.

В результате получаем сценарий для архивирования в специально предназначенном для этого каталоге archivedir наших рабочих данных (командой tar), а заодно и их компрессии (командой gzip) — в Unix, в отличие от DOS/Windows, архивирование и компрессия обычно рассматриваются как разные процедуры.

Наконец, сценарий можно создать в любом текстовом редакторе. но это не так интересно — по крайней мере, пока. Да и стоит ли вызывать редактор ради двух-трёх строк?

Комментариями в шелл-сценариях считаются любые строки, начинающиеся с символа решетки (#) — они не учитываются интерпретатором и не принимаются к исполнению. Хотя комментарий может быть начат и внутри строки — важно только, что между символом # и концом её больше ничего не было бы. Ясно, что комментарии — элемент для скрипта не обязательный, но очень желательный. Хотя бы для того, чтобы не забыть, ради чего этот сценарий создавался.

Но одна строка, начинающаяся символом решётки, в сценарии практически обязательна. И должна она быть первой и выглядеть следующим образом:

#!/path/shell_name

В данном случае восклицательный знак подчеркивает, что предваряющий его символ решетки (#) — не комментарий, а указание (т.н. sha-bang) на точный абсолютный путь к исполняемому файлу оболочки, для которой наш сценарий предназначен, например,

#!/bin/sh

для POSIX-шелла, или

#!/bin/bash

для оболочки Bash. Здесь следует подчеркнуть, что шелл, для которого предназначается сценарий, отнюдь не обязан совпадать с командной оболочкой пользователя. И полноты картины для замечу, что указание точного имени интерпретатора требуется не только для шелл-скриптов, но и для программ на любых языках сценариев (типа Perl или Python).

Так что по хорошему в обоих приведенных выше примерах ввод команд сценария следовало бы предварить строкой sha-bang. Конечно, отсутствие имени командной оболочки в явном виде обычно не помешает исполнению шелл-сценария: для этого будет вызван системный командный интерпретатор по умолчанию — в Mint /bin/dash. Однако если сценарий предназначен для другой командной оболочки, то без sha-bang он может исполняться неправильно (или не исполняться вообще).

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

$ bash scriptname

Далее, для вызова скриптов существует специальная встроенная команда оболочки, обозначаемая символом точки. Используется она аналогично:

$ . ./scriptname

с тем только исключением, что тут требуется указание текущего каталога в явном виде (что и символизируется ./).

Однако наиболее употребимый способ запуска сценариев — это присвоение его файлу так называемого атрибута исполнения. Эта процедура волшебным образом превращает невзрачный текстовый файлишко во всамделишную (хотя и очень простую) программу.

Так вот, после присвоения нашему сценарию бита исполнения запустить его можно точно также, как любую другую команду — просто из командной строки:

$ ./scriptname

Опять же — в предположении, что сценарий находится в текущем каталоге (./), иначе потребуется указание полного пути к нему. Что, понятно, лениво, но решается раз и навсегда: все сценарии помещаются в специально отведенный для этого каталог (например, $HOME/bin), который и добавляется в качестве ещё одного значения переменной PATH данного пользователя.

Понятие о функциях

И уж совсем в заключение этого раздела осталось сказать пару слов о функциях командной оболочки. Это — такая же последовательность команд (или даже просто одиночная команда), как и сценарий, но — не вынесенная в отдельный исполняемый файл, а помещённая в тело другого скрипта. В коем она опознаётся по имени, и может быть выполнена неоднократно в ходе работы этого скрипта.

Главное отличие функции от сценария — в том, что она выполняется в том же процессе (и, соответственно, экземпляре шелла), что и заключающий её сценарий. Тогда как для каждого скрипта, вызываемого из другого сценария, создаётся отдельный процесс, порождающий собственный экземпляр шелла. Это может быть важным, если в сценарии определяются некоторые переменные, которые имеют силу только в нём самом.

Функции не обязательно помещаются внутрь сценария — их можно собрать в некоторые отдельные файлы, которые именуются библиотеками функций и могут быть использованы по мере надобности.

Ранее на протяжении всего повествования неоднократно упоминались (и будут упоминаться впредь) системные библиотеки, в частности, главная библиотека glibc. Так вот, это — точно такие же сборники функций, правда, не командной оболочки, а языка Си, и, соответственно, хранящиеся не в виде текстовых файлов, а в бинарном, откомпилированном, виде.

Настройка шелла

Во всех дистрибутивах Linux в качестве пользовательской командной оболочки по умолчанию выступает Bash, и Mint здесь не исключение. Так что, хотя автор этих строк не является ни её любителем, ни, тем более, знатоком, совсем обойти её вниманиемне мог. Так что ниже даётся мини-очерк настройки этого шелла.

Оболочка Bash поддерживает все интерактивные возможности, столь важные для пользователя, как то: автодополнение для команд и путей к файлам, историю оных (включая средства инкрементного поиска), мощные возможности навигации и редактирования командной строки.

Важно, что существует дополнительный пакет bash-completion: установка его обогащает базовую оболочку множеством опциональных средств настройки автодополнения (в том числе и для командных аргументов). Правда, чтобы эта дополненная оболочка была по настоящему удобной и функциональной, нужно приложить некоторые усилия по её настройке, чем мы сейчас и займёмся.

Схема настройки bash предусматривает наличие пары файлов /etc/profile и /etc/bashrc (для логин-шелла и просто интерактивного его экземпляра), а также соответствующих им пользовательских конфигов — ~/.bash_profile и ~/.bashrc. При авторизации первым в любом случае считывается общесистемный профильный файл /etc/profile, вслед за ним — пользовательский профильный файл ~/.bash_profile, после чего происходит обращение к ~/.bashrc. Файл /etc/profile может занимать особое положение — в него часто помещают переменные окружения (например, локально-зависимые), которые должны быть общими для всех пользователей данной системы. Пользовательские же настройки определяются в файлах ~/.bash_profile и ~/.bashrc. Обычно в ~/.bash_profile определяются переменные окружения, которые должны действовать для всех дочерних процессов, а в ~/.bashrc — параметры, всегда требуемые в интерактивном режиме (например, псевдонимы).

Редактирование командной строки в bash обеспечивается отдельным пакетом — библиотекой функций readline. Она имеет собственные конфигурационные файлы, общесистемный /etc/inputrc и пользовательский ~/.inputrc.

Впрочем, в большинстве современных дистрибутивов Linux, ориентированных на графический режим и, следовательно, использование эмулятора терминала с интерактивным шеллом, не являющимся, тем не менее, шеллом пользовательским (login shell), ~/.bash_profile играет сугубо служебную роль, и содержимое его сводится к отработке файла ~/.bashrc:

# include .bashrc if it existsif [ -f ~/.bashrc ]; then

 

. ~/.bashrc

 

fi# set PATH so it includes user’s private bin if it existsif [ -d ~/bin ] ; then

 

PATH=~/bin:»${PATH}»

 

fi

Именно в ~/.bashrc и выполняются при этом все пользовательские настройки.

Большинство настроек Bash по умолчанию разумны, и потому наличные в данном дистрибутиве файлы вполне могут быть взяты за основу. Однако путём некоторых несложных действий их можно дополнить, увеличив удобство интерактивного использования командной оболочки.

По умолчанию в Bash автодополнение клавишей табулятора не работает, например, в аргументах многих команд, таких, как sudo или man.

Решается эта задача очень просто: достаточно файл ~/.bashrc внести следующие строки:

# enable bash completion in interactive shells

if [ -f /etc/bash_completion ]; then

 . /etc/bash_completion

fi

После этого автодополнение будет работать буквально везде, где только можно себе представить, например, после набора dpkg —sea и нажатия табулятора получится dpkg —search.

Если в файл /etc/inpurc (или в ~/inpurc) добавить такие строки:

«e[A»: history-search-backward

«e[B»: history-search-forward

то набор части команды, например, cd /, и последующий перебор стрелками <Up> и <Down> истории команд повлечёт извеление из буфера истории только тех из них, которые начинаются на cd /.

Утилиты CLI

В этом очерке будут рассмотрены утилиты командной строки разного назначения — комплекс так называемых классических UNIX-утилит в их современных свободных реализациях, используемых в дистрибутивах Linux, в том числе и в Mint.

Самая главная команда

Эта рубрика посвящена самой главной команде — man, а также сопутствующим ей материям. Содержание её — не информация о тех или иных командах, или свойствах системы, а метаинформация: информация о том, как получить нужную информацию. То есть выработке некоторых навыков, которые у применителя Linux должны быть доведены до уровня рефлексов.

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

Команда man предназначена для вызова экранной документации в одноименном формате (Manual Pages, что на Руси ласково переводится как «тетя Маня»). А такая man-документация почти обязательно сопровождает любую уважающую себя программу для POSIX-систем. И устанавливается в принудительном порядке при инсталляции соответствующей программы в любом случае — разворачивается ли она из бинарного тарбалла или собирается из исходников.

Для файлов man-документации предназначен специальный каталог. Обычно это /usr/share/man, разделяемый на подкаталоги, соответствующие восьми нумерованным группам. Назначение этих групп следующее:

  1. man1 — команды и прикладные программы пользователя;

  2. man2 — системные вызовы;

  3. man3 — библиотечные функции;

  4. man4 — драйверы устройств;

  5. man5 — форматы файлов;

  6. man6 — игры;

  7. man7 — различные документы, не попадающие в другие группы (в том числе относящиеся к национальной поддержке);

  8. man8 — команды администрирования системы.

Кроме того, имеется несколько подкаталогов с локализованными man-страницами, в том числе и русскоязычными, имеющими ту же структуру, хотя и обычно не полную. Так, подкаталог с русскоязычными страницами, /usr/share/man/ru, включает в себя только группы man1, man5, man7 и man8.

Нас, применителей, в первую очередь интересуют команды из 1-й и, поскольку на персоналке каждый юзер — сам себе админ, из 8-й групп, хотя и об остальных категориях забывать не следует, иногда позарез нужные сведения отыскиваются в самой неожиданной из них.

Внутри групповых подкаталогов можно увидеть многочисленные файлы вида filename.#.gz. Последний суффикс свидетельствует о том, что man-страница упакована компрессором gzip. Цифра после имени соответствует номеру группы (то есть в подкаталоге man1 это всегда будет единица). Ну а имя man-страницы совпадает с именем команды, которую она описывает. Если, конечно, речь идет о команде — в разделе 2 оно будет образовано от соответствующего системного вызова, в разделе 2 — от имени функции, и так далее. Но пока нас интересует только информация о командах, так что дальше я этого оговаривать не буду.

Для вызова интересующей документации требуется дать команду man с аргументами — номером группы и именем man-страницы, например:

$ man 1 ls

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

$ man ls

после чего можно будет лицезреть примерно такую картину:

LS(1)   FSF     LS(1)

NAME

        ls — list directory contents

SYNOPSIS

        ls [OPTION]… [FILE]…

DESCRIPTION

        List  information  about

        the FILEs (the current directory by default).

        Sort entries alphabetically if none

        of -cftuSUX nor —sort.

То есть в начале man-страницы даются имя команды, которую она описывает (ls), ее групповая принадлежность (1 — пользовательские команды) и авторство (в данном случае — FSF, Free Software Foundations), или название системы. После чего обычно дается обобщенный формат вызова (SYNOPSIS) и краткое описание.

Следующая, основная, часть man-страницы — описание опций команды, и условия их применения. Далее иногда (но, к сожалению, не всегда) следуют примеры использования команды (Examples) в разных типичных ситуациях. В заключении, как правило, даются сведения о найденных ошибках (Bug Report) и приведен список man-страниц, тематически связанных с данной (See also), с указанием номера группы, к которой они принадлежат, иногда — историческая справка, а также указываются данные об авторе.

Большинство man-страниц занимают более одного экрана. В этом случае возникает необходимость перемещёния по экранам и строкам — т.е. некоторая навигация. Сама по себе команда man не отвечает не только за навигацию по странице. но даже за ее просмотр. Для этой цели она неявным образом вызывает специальную программу постраничного просмотре — т.н. pager (это — совсем не то, чем дети лохов в песочнице ковыряются). В Linux таковым по умолчанию выступает уже известная нам команда less, но на эту роль можно назначить также more или most — это делается указанием значения соответствующей переменной, например:

export PAGER=most

в конфигурациооном файле пользователя.

Обращение к man-страницам позволяет получить практически исчерпывающую информацию по любым командам, но только в том случае, если пользователь знает название той команды, которая требуется в данном случае. А если он только в общих чертах представляет, что это команда должна делать?

Что ж, тогда можно прибегнуть к поиску man-страниц по ключевым словам, отражающим требуемые функции. Чему призвана служить опция -k команды man. Например, директива

$ man -k print

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

Исчерпывающим руководством по использованию системы Manual Pages является ее собственная man-страница. Доступ к ней осуществляется по команде

$ man man

которая выводит на экран man-страницу, содержащую описание команды man (эко загнул, а?):

MAN(1)  FreeBSD General Commands Manual MAN(1)

 

NAME

        man — format and display the on-line

        manual pages

 

SYNOPSIS

        man [-adfhkotw] [-m machine]

        [-p string] [-M path] [-P pager]

        [-S list] [section] name …

 

DESCRIPTION

     Man formats and displays the on-line manual pages.

        …

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

Управляющие последовательности команды less для большинства навигационных действий весьма разнообразны, но в принципе разделяются на две группы: чисто буквенные и состоящие из комбинаций Control+литера. Так, переместиться на одну строку вперед можно просто нажатием клавиши j, на одну строку назад — клавиши k, сместиться на экранную страницу — с помощью клавиш f (вперед) и b (назад). Однако того же результата можно доиться комбинациями клавиш Control+n и Control+p для построчного перемещёния и Control+v и Control+и — для постраничного (вперед и назад, соответственно).

Аналогично и для большинства других действий (смещёние на половину экранной страницы, например: Control+D и d — вперед, Control+U и u — назад) можно обнаружить минимум одну альтернативную пару управляющих последовательностей. Регистр символов обычно значения не имеет. Одно из исключений — нажатие клавиши g перемещает к первой строке man-страницы, клавиши G — к последней.

Наличие двух типов управляющих последовательностей может показаться излишним усложнением, однако имеет глубокое внутреннее обоснование. За исключением некоторых отщепенцев (в числе коих и автор этих строк), подавляющее большинство записных юниксоидов пользуются одним из двух редакторов — Vim или emacs.

Оба эти редактора относятся к категории командных. То есть все действия по редактированию осуществляются в них обычно не выбором пунктов из меню, а прямыми командными директивами, примерно как в командной строке оболочки. Так вот, одно из кардинальных различий между Vim и emacs — различие управляющих последовательностей для навигации по тексту и его редактированию. vi-образный стиль навигации основан на однобуквенных командных аббревиатурах (команды типа j или k пришли в less именно оттуда). Стиль emacs же подразумевает последовательности, образованные сочетанием клавиши Control и различных алфавитно-цифровых комбинаций.

Поскольку эффективное использование любого редактора командного стиля подразумевает доведенное до автоматизма использование управляющих последовательностей, переключение с vi-стиля на стиль emacs в этом деле может быть просто мучительным. Вот и предусмотрели разработчики pager’ов, в своей заботе о человеке, возможность использования и того, и другого стиля — кто к чему привык.

Раз уж зашла речь о стилях управляющих последовательностей… В большинстве командных оболочек такое переключение между стилями управления также возможно. Только не параллельное, а альтернативное. И устанавливается оно в конфигурационных файлах пользовательского шелла.

Возвратимся, однако, к нашей man-документации. Для навигации по странице можно использовать и обычные клавиши управления курсором, клавиши PgUp/PgDown, а также некоторые другие. Например, нажатие Enter приводит к смещёнию на одну строку вперед (аналогично клавише Down, а клавиши Spacebar — на один экран вперед (подобно PgDown.

Однако это — не лучший способ навигации. Потому что управляющие последовательности (не зависимо, в стиле ли vi, или в стиле emacs) обладают дополнительной полезной возможностью: они понимают числовые аргументы. То есть если мы нажмем клавишу с цифрой 5, а вслед за ней — клавишу J, то мы сместимся на пять строк вперед, комбинация 3+K — на три страницы назад, и так далее.

Есть и возможность поиска внутри man-страницы. Для этого нажимается клавиша прямого слэша (/), после чего вводится искомое слово (последовательность символов). Для выхода из просмотра man-страницы предусмотрена клавиша q. Кроме того, можно использовать и почти универсальную комбинацию для прекращения выполнения программ — Control+C. Заканчивая разговор об управляющих последовательностях, ещё раз подчеркну: все они относятся не к самой команде man, а к той программе-пейджеру, которая ею вызывается для просмотра.

Команда sudo

Команда sudo — вторая по важности команда в Mint. Это — основной способ получения прав администратора обычным пользователем. А по умолчанию — так просто единственный, ибо при инсталляции этого дистрибутива пароль root’а не задаётся и, соответственно, доступа к аккаунту «чистого» суперпользователя нет (хотя при желании его можно получить). Команда эта дополняется утилитами visudo и sudoedit. Это узкоспециализированные средства для редактирования общесистемных конфигурационных файлов (в том числе и конфига самой sudo) обычным пользователем. Главные особенности sudo таковы:

  1. во-первых, sudo по умолчанию требует указания пароля того пользователя, который получает права другого, а не пароля того, чьи права приобретаются; правда, это может быть изменено;

  2. Во-вторых, действие sudo распространяется по умолчанию только на одну команду — ту, которая указывается в качестве ее аргумента; хотя и такое поведение можно изменить с помощью соответствующих опций, о чём будет сказано позднее;

  3. в-третьих, sudo обеспечивает более гибкое разграничение доступа пользователей к административным правам — не только разрешая или запрещая получение оных, но и позволяя выполнять только определённый круг действий.

Этим достигается две цели: а) возможность выполнения пользователем административных действий без сообщения ему суперпользовательского пароля (и даже, как в Mint, при его отсуствтии), и б) снижение риска повредить систему вследствие забывчивости. Да, есть ещё и третья, дополнительная возможность, предоставляемая sudo — протоколирование действий, выполненных в режиме администратора.

В элементарном виде применение команды sudo — элементарно же просто: требуется лишь указать в качестве ее аргумента имя команды, требующей исполнения, со всеми необходимыми последней опциями и аргументами. После этого запрашивается пароль запустившего её пользователя — и команда исполняется. Например, команда

$ sudo fdisk -l /dev/sda

данная от лица обычного пользователя, выведет информацию об указанном дисковом устройстве точно так же, как и данная root’ом.

В должным образом настроенной оболочке Bash в отношении команд-аргументов и путей — аргументов последних, будет действовать автодополнение по нажатию клавиши Tab. Как добиться от Bash столь образцового поведения — говорилось в предыдущем очерке.

Если от лица алминистратора нужно выполнить подряд несколько команд, делать это следует быстро — введенный первый раз пароль по умолчанию «действует» в течении 5 минут. То есть в течении этого времени в ответ на команду sudo пароль повторно запрашиваться не будет.

Период действия пароля для команды sudo можно увеличить, уменьшить или вообще ликвидировать, чтобы аутентификация запрашивался всегда. Это достигается редактированием конфигурационного файла утилиты, к чему мы вернёмся чуть позже.

Аналогичным образом пользователь может отредактировать общесистемный конфигурационный файл, например:

$ sudo nano -w /etc/fstab

Впрочем, для редактирования общесистемных конфигов предназначена специальная команда sudoedit (или просто sudo с опцией -e). Она не требует указания имени вызываемого для этой цели редактора: в качестве такового используется значение переменной EDITOR из окружения того пользователя, который ее вызвал. Если эта переменная не определена — а это обычно делается в профильных файлах регистрационной оболочки пользователя, — для редактирования вызывается редактор Vim (в своей упрощенной ипостаси, эмулирующей классический vi).

Как это ни парадоксально, команда sudo не исключает запуска администраторского сеанса внутри обычного пользовательского. Потому что с ее помощью можно запустить su:

$ sudo su

И это — даже в тех дистрибутивах, где root-аккаунта как бы и нет; точнее, по умолчанию нет его пароля (к ним, как уже было сказано, относится Mint). Но и задать пароль «настоящего» администратора не запрещается — для этого достаточно дать команду

$ sudo passwd

чтобы в дальнейшем использовать команду su обычным образом. Правда, не уверен, что это стоит делать. Потому что для перманентного владения правами адмнистратора команда sudo предусматривает «идеологически правильный» метод, и даже не один. Это — опции -s и -i, пролонгирующие, хотя и несколько по разному, действие команды sudo на неопределённый срок, вплоть до завершения «вторичного сеанса» командой exit.

Опция -s, открывая вторичный сеанс root’а, сохраняет все переменные окружения первоначального пользователя. Однако, если к ней добавить опцию -H, то переменные эти будут заново считаны из профильных файлов домашнего каталога администратора, то есть /root, как при запуске интерактивного экземпляра шелла. Однако каталог, бывший текущим в момент ввода команды, при этом не изменится, как не изменится и вид приглашения командной строки.

Опция же -i полностью воспроизводит root-окружение, запуская его командную оболочку как регистрационную (login shell). Разумеется, при этом и текущий каталог меняется на /root, а приглашение командной строки приобретает вид, описанный в соответствующей переменной профильного файла администраторского шелла, то есть /root/.bashrc. Правда, в Mint и его по умолчанию нет.

На практике разница между обеими формами обретения перманентных прав администратора не велика. А вот то, что при использовании опций -H нахождение в перманентно административном режиме никак внешне не проявляется, чревато ошибками. И делает в большинстве случаев применение опции -i предпочтительным.

Возможности sudo не ограничиваются запуском команд от лица администратора: задав опцию -u username, их можно выполнить и от лица того пользователя, чей логин задан в качестве её значения. Это может быть полезным при просмотре или копировании dot-файлов и dot-каталогов другого пользователя, часто открытых для чтения и изменения только их хозяину.

К слову сказать, команду sudo можно запустить так, чтобы она запрашивала пароль пользователя, от имени которого будет выполняться команда (например, администратора), а не того, кто требует его полномочий. Для этого существует опция -targetpw. А чтобы сделать требование root’ового пароля постоянным, достаточно определить, например, псевдоним типа

alias sudo=’sudo -targetpw’

Команда sudo имеет ещё немало опций — выше я привёл только те, которые мне приходилось использовать. Остальные легко посмотреть в man sudo. Из не перечисленных упомяну ещё опцию -b, предписывающую запускать «подсудную» команду в фоновом режиме. Она может быть полезна при выполнении долговременных действий, например, при копировании образов USB на флэшку командой dd.

Таким образом, команда sudo даёт пользователю практически неограниченные полномочия как для любых общесистемных действий, так и для манипуляции чужими пользовательскими данными. В связи с этим зададимся вопросами:

  • любой ли пользователь может получить права администратора через команду sudo, и

  • все ли действия по администрированию он может ее посредством выполнить?

Если говорить о семействе Ubuntu (в том числе и дистрибутиве Mint), в котором механизм этот был впервые задействован из «коробки» — то «из коробки» же ответ на первый вопрос будет отрицательным, на второй — положительным. А вообще это зависит от настроек программы sudo, которые описываются в файле /etc/sudoers. И в нем можно задать правила, допускающие к исполнению определенных команд только отдельных пользователей. В обобщенном виде это выглядит так:

username        host = command

Здесь, как нетрудно догадаться, username — имя пользователя, для которого устанавливается данное правило, host — имя машины, с которой он может к этому правилу прибегнуть, command — конкретная команда, использование которой разрешается данному пользователю с данной машины. Команда должна быть дана с указанием полного абсолютного пути (то есть /sbin/fdisk, а не fdisk). Поле описания команд может включать несколько значений, разделенных запятыми, например:

username        ALL = /sbin/fdisk,/bin/mount

В Ubuntu’идах по умолчанию правила доступа пользователей к административным привилегиям описываются так:

# User privilege specificationroot

ALL=(ALL) ALL

# Members of the admin group may gain root privileges

%admin  ALL=(ALL) ALL

То есть пользователь root, как ему и положено, может исполнять любые команды с любых хостов. А вот получить права его могут только пользователи, входящие в группу admin. Пользователь, создаваемый в ходе обычной установки, автоматически становится членом этой группы — и потому все административные права ему доступны без всяких дальнейших настроек. Однако прочие пользователи, чьи аккаунты будут созданы в последствие, этой привилегии лишены. Если, конечно, они не были специально включены в группу admin.

В более иных дистрибутивах, не использующих sudo «из коробки», потребуется редактирование её конфигурационного файла — того самого /etc/sudoers, о котором упоминалось выше.

Файл /etc/sudoers — обычный текстовый, и, соответственно, его можно редактировать в любом текстовом редакторе (или, скажем, средствами ed или sed). Однако при этом существует определённый риск что-нибудь напортачить (за счёт обычных опечаток), вплоть до того, что полностью закрыть самому себе доступ к привилегиям суперпользователя. Конечно, ситуации эти поправимы — например, через перезагрузку в однопользовательском режиме. Однако, лучше в них не попадать. И потому более надёжным средством модификации /etc/sudoers будет использование специально предназначенной для того утилиты — visudo.

Утилита visudo не делает ничего сверхъестественного — она просто открывает /etc/sudoers в текстовом редакторе, описываемом переменной EDITOR суперпользователя (если таковая не определена, им будет опять же классический vi — отсюда и название) и позволяет его отредактировать обычным образом, после чего выйти из редактора с сохранением результатов штатными его средствами. Однако перед этим результат редактирования проверяется на корректность. И если обнаруживается нарушение синтаксиса, принятого для /etc/sudoers, выдается соответствующее предупреждение. После которого можно вернуться к редактированию, отказаться от сделанных изменений или все-таки принять их (разумеется, под личную ответственность).

Утилита visudo не гарантирует стопроцентного успеха редактирования. Так как проверяет только соответствие синтаксиса, но не «правильность самих правил». То есть если ошибка будет допущена в указании пути к нужной для данного правила команде — эта команда через sudo не сработает.

Впрочем, на деле это выглядит обычно гораздо проще и совсем не страшно. Так, можно было бы предоставить себе по блату возможность использовать sudo без пароля. Для этого потребовалось бы придать строке, описывающей привилегии группы admin такой вид:

%admin        ALL=(ALL)       NOPASSWD: ALL

А можно ограничиться более «долгоиграющим» действием пароля, вписав изначально отсутствующую строку

Defaults    timestamp_timeout=10

где значение таймаута указано в минутах. Если же изменить его на ноль —

Defaults    timestamp_timeout=0

то пароль будет запрашиваться каждый раз при обращении к команде sudo.

Можно, напротив, отключить тайаут на действие sudo, ввдя для него отрицательное значение:

Defaults    timestamp_timeout=-1

В этом случае пароль будет запрошен только при первом вызове этой команды.

Более пристальное вглядывание в файл /etc/sudoers легко подскажет возможности дать определённым пользователям или группам только ограниченный набор прав. Впрочем, тут уже начинаются тонкости всамделишнего администрирования.

Создание файлов и каталогов

В следующих мини-очерках будут рассмотрены основные команды, предназначенные для файловых операций, вместе с их наиболее используемыми опциями. Чтобы не повторяться, напомню, что почти все описанные ниже команды имеют три стандартные опции (т.н. GNU Standard Options): —help для получения помощи, —version для вывода информации о текущей версии, и [пробел], символизирующая окончание перечня опций (т.е. любой символ или их последовательность после неё интерпретируются как аргумент). Так что далее эти опции в описаниях команд фигурировать не будут.

Для создания обычных (regular) файлов могут использоваться команды touch, cat и tee. Первая из указанных команд в форме

$ touch filename

просто создает файл с именем filename и без всякого содержимого. Кроме того, с помощью специальных опций она позволяет устанавливать временные атрибуты файла, о чем я скажу чуть позже.

Для чего может потребоваться пустой файл? Например, для создания скелета web-сайта с целью проверки целостности ссылок. Поскольку число аргументов команды touch не ограничено ничем (вернее, ограничено только максимальным количеством символов в командной строке), это можно сделать одной командой:

$ touch index.html about.html content.html […]

Можно, воспользовавшись приемом группировки аргументов, заполнить файлами все подкаталоги текущего каталога:

$ touch dirname1/{filename1,filename2}

        dirname2/{filename3,filename4}

и так далее. Правда, сама команда touch создавать подкаталоги не способна — это следует сделать предварительно командой mkdir (о которой — чуть ниже).

Для создания пустого регулярного файла может быть использована также команда cat (хотя основное ее назначение — слияние нескольких файлов, о чем будет говориться со временем). Для этого нужно просто перенаправить ее вывод в файл:

$ cat > filename

затем создать новую строку (нажатием клавиши Enter) и ввести символ конца файла (комбинацией клавиш Control+Z). Разумеется, предварительно в этот файл можно и ввести какой-нибудь текст, однако это уже относится к управлению контентом, о чем речь будет впереди.

Интересно создание файлов с помощью команды tee. Смысл ее — в раздвоении выходного потока, выводимого одновременно и на стандартный вывод, и в файл, указанный в качестве ее аргумента. То есть если использовать ее для создания файла с клавиатуры, это выглядит, будто строки удваиваются на экране. Но это не так: просто весь вводимый текст копируется одновременно и на экран, и в файл. И потому ее удобно применять в командных конструкциях, когда требуется одновременно и просмотреть результаты исполнения какой-либо команды, и запечатлеть их в файле:

$ ls dir | tee filename

По умолчанию команда tee создает новый файл с указанным именем, или перезаписывает одноименный, если он существовал ранее. Однако данная с опцией -a, она добавляет новые данные в конец существующего файла.

Команда mkdir создает файл особого типа — каталог, содержимым которого является список входящих в него файлов. Очевидно, что список этот в момент создания каталога должен быть пуст, однако это не совсем так: любой, даже пустой, каталог содержит две ссылки — на каталог текущий, обозначаемый как ./ (т.е. сам на себя) и на каталог родительский, ../ (т.е тот, в список файлов которого он включается в момент создания).

Команда mkdir требует обязательного аргумента — имени создаваемого каталога. Аргументов может быть больше одного — в этом случае будет создано два или больше поименованных каталогов. По умолчанию они создаются как подкаталоги каталога текущего. Можно создать также подкаталог в существующем подкаталоге:

$ mkdir parentdir/newdir

Если же требуется создать подкаталог в каталоге, отличном от текущего, — путь к нему требуется указать в явном виде, в относительной форме:

$ mkdir ../dirname1/dirname2

или в форме абсолютной:

$ mkdir /home/username/dirname1/dirname2

В произвольном, отличном от текущего, каталоге можно одной командой создать несколько подкаталогов, для чего нужно прибегнуть к группировке аргументов:

$ mkdir ../parentdir/{dirname1,dirname2,…,dirname#}

Такой прием позволяет одной командой создать дерево каталогов проекта. Например, скелет web-сайта, который потом можно наполнить пустыми файлами с помощью команды touch.

А опций у команды mkdir — всего две (за исключением стандартных опций GNU): —mode (или -m) для установки атрибутов доступа и —parents (или -p) для создания как требуемого каталога, так и родительского по отношению к нему (если таковой ранее не существовал). Первая опция используется в форме

$ mkdir —mode=### dirname

или

$ mkdir -m ### dirname

Здесь под ### понимаются атрибуты доступа для владельца файла, группы и прочих, заданные в численной нотации (например, 777 — полный доступ на чтение, изменение и исполнение для всех). Не возбраняется и использование символьной нотации: команда

$ mkdir -m a+rwx dirname

создаст каталог с теми же атрибутами полного доступа для всех.

Опция —parents (она же -p) позволяет создавать иерархическую цепочку подкаталогов любого уровня вложенности. Например,

$ mkdir -p dirlevel1/dirlevel2/dirlevel3

в один заход создаст в текущем каталоге цепочку вложенных друг друга подкаталогов. Разумеется, и здесь с помощью группировки аргументов можно создать несколько одноранговых подкаталогов:

$ mkdir -p dirlevel1/dirlevel2/{dirlevel31,…,dirlevel3#}

Аттрибуция файлов

Следующая группа команд предназначена для атрибуции файлов. В ней — chmod, chown, chgrp, umask, а также уже затронутая ранее команда touch.

Команды chown и chgrp служат для изменения атрибутов принадлежности файла — хозяину и группе: очевидно, что все, не являющиеся хозяином файла, и не входящие в группу, к которой файл приписан, автоматически попадают в категорию прочих (other).

Формат команды chown — следующий:

$ chown newowner filename

По соображениям безопасности, достаточно очевидным, изменить хозяина файла может только суперпользователь. Пользователь обычный в подавляющем большинстве случаев автоматически становится хозяином всех им созданных (и скопированных) файлов, и избавиться от этого бремени, как и от родительского долга, не в состоянии.

А вот изменить групповую принадлежность своих файлов (т.е. тех, в атрибутах принадлежности он прописан как хозяин) пользователь вполне может. Команда:

$ chgrp newgroup filename

от его лица припишет файл filename к группе newgroup. Однако и здесь есть ограничение — результат будет достигнут, только если хозяин файла является членом группы newgroup, иначе опять придется прибегнуть к полномочиям администратора.

Можно также одной командой сменить (только суперпользователю, конечно) и хозяина файла, и группу, к которой он приписан. Делается это так:

$ chown newowner:newgroup filename

Или так:

$ chown newowner.newgroup filename

Где, понятное дело, под именем newowner выступает новый хозяин файла, а под именем newgroup — новая группа, к которой он приписан.

В обеих командах вместо имени хозяина и группы могут фигурировать их численные идентификаторы (UID и GID, соответственно). Это имеет смысл, например, при совместном использовании файлов в разных операционных системах. Так, даже единственный пользователь имя_рек в каком-либо варианте Linux и в BSD по умолчанию имеет разные идентификаторы, и чтобы сделать его владельцем неких файлов и там, и там, именно численный идентификатор должен фигурировать в качестве параметра команды chown.

Для команд chown и chgrp поддерживается один и тот же набор опций. Наиболее интересны (и важны) две из них. Опция —reference позволяет определить хозяина файла и его принадлежность к группе не явным образом, а по образу и подобию файла, имя которого выступает в качестве значения опции. Так, команда

$ chown —reference=ref_filename filename

установит для файла filename те же атрибуты принадлежности (хозяина и группу), что были ранее у файла ref_filename. Это весьма полезно при массовой реатрибуции файлов, полученных из разных источников.

Опция -R (или —recursive) распространяет действие обеих команд не только на файлы текущего каталога (излишне напоминать, что в качестве аргументов команд могут использоваться маски типа *, *.ext, name.* и т.д.),
но и на все вложенные подкаталоги, вместе с входящими в них файлами. То есть пользователь может поменять групповую принадлежность всех файлов в своем домашнем каталоге одной командой:

$ chgrp -R newgroup ~/*

А суперпользователь тем же способом может установить единообразные атрибуты принадлежности «по образцу» для всех компонентов любого каталога:

$ chown -R —reference=ref_filename

        /somepath/somecat/*

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

$ chmod [атрибуты] filename

Атрибуты доступа могу устанавливаться с использование как символьной, так и цифровой нотации. Первый способ — указание, для каких атрибутов принадлежности (хозяина, группы и всех остальных) какие атрибуты доступа задействованы. Атрибуты принадлежности обозначаются символами u (от user) для хозяина файла, g (от group) — для группы, o (от other) для прочих и a (от all) — для всех категорий принадлежности вообще. Атрибуты доступа символизируются литерами r (от read), дающей право чтения, w (от write) — право изменения и x (от execute) — право исполнения.

Атрибуты принадлежности соединяются с атрибутами доступа символами + (присвоение атрибута доступа), (отнятие атрибута) или = (присвоение только данного атрибута доступа с одновременным отнятием всех остальных). Одновременно в строке можно указать (подряд, без пробелов) более чем один из атрибутов принадлежности и несколько (или все) атрибуты доступа.

Для пояснения сказанного приведу несколько примеров. Так, команда

$ chmod u+w filename

установит для хозяина (u) право изменения (+w) файла filename, а команда

$ chmod a-x filename

отнимет у всех пользователей вообще (a) право его исполнения (-x). В случае, если некоторый атрибут доступа присваивается всем категориям принадлежности, символ a можно опустить. Так, команда

$ chmod +x filename

в противоположность предыдущей, присвоит атрибут исполнения файла filename всем категориям принадлежности (и хозяину, и группе, и прочим).

С помощью команды

$ chmod go=rx filename

можно присвоить группе принадлежности файла filename и всем прочим (не хозяину и не группе) право на его чтение и исполнение с одновременным отнятием права изменения.

Наконец, команда chmod в состоянии установить и дополнительные атрибуты режима для файлов, такие, как биты SUID и GUID, или, скажем, атрибут sticky.

Приведенные примеры можно многократно умножить, но, думается, их достаточно для понимания принципов работы команды chmod с символьной нотацией атрибутов.

Цифровая нотация — ещё проще. При ней достаточно указать сумму присваиваемых атрибутов в восьмеричном исчислении (4 — атрибут чтения, 2 — атрибут изменения и 1 — атрибут исполнения; 0 символизирует отсутствие любых атрибутов доступа) для хозяина (первая позиция), группы (вторая позиция) и прочих (третья позиция). Все атрибуты доступа, оставшиеся вне этой суммы, автоматически отнимаются у данного файла. То есть команда

$ chmod 000 filename

означает снятие с файла filename всех атрибутов доступа для всех категорий принадлежности (в том числе и хозяина) и эквивалентна команде

$ chmod =rwx filename

в символьной нотации. А команда

$ chmod 777 filename

напротив, устанавливает для всех полный доступ к файлу filename. Для установки дополнительных атрибутов доступа в численной нотации потребуется указать значение четвертого, старшего, регистра. Так, команда для рассмотренного выше примера — присвоения атрибута суидности исполнимому файлу X-сервера, — в численной нотации будет выглядеть как

$ chmod 4711 /usr/X11R6/bin/XFree86

Как и для команд chown и chgrp, наиболее значимые опции команды chmod — это —reference и -R. И смысл их тот же самый. Первая устанавливает для файла (файлов) атрибуты доступа, идентичные таковым референсного файла, вторая — распространяет действие команды на все вложенные подкаталоги и входящие в них файлы.

Рекурсивное присвоение атрибутов доступа по образцу требует внимания. Так, если рекурсивно отнять для всего содержимого домашнего каталога атрибут исполнения (а он без соблюдения некоторых условий монтирования автоматом присваивается любым файлам, скопированным с носителей файловой структуры FAT или ISO9660 без расширения RockRidge, что подчас мешает), то тем самым станет невозможным вход в любой из вложенных подкаталогов. Впрочем, в параграфе про утилиту find будет показан один из способов борьбы с таким безобразием.

Как было упомянуто в предшествующей главе, для всех вновь создаваемых данным пользователем файлов можно установить некие умолчальные атрибуты доступа. Этой цели служит команда umask — в отличие от прочих, не самостоятельная утилита, а встроенная команда оболочки. Данная без аргумента, она выведет текущее значение субтрактивных (то есть отнимаемых от суммы) прав доступа для новообразуемых файлов:

$ umask

22

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

$ umask 000

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

Действие команды umask, данной таким образом, распространяется только на текущий сеанс работы. Поэтому обычно она включается в профильный файл пользовательской командной оболочки, определяя умолчальные права доступа на вечные времена.

Кроме атрибутов принадлежности и доступа, файлам свойственны ещё и атрибуты времени — времени доступа (atime), времени изменения метаданных (ctime) и времени изменения данных (mtime) файла. Они устанавливаются автоматически, в силу самого факта открытия файла (atime), смены любых атрибутов, например, доступа (ctime) или редактирования содержимого файла (mtime).

Однако бывают ситуации, когда автоматически установленные временные атрибуты требуется изменить. Причиной может быть сбой системных часов, в результате которого временные атрибуты создаваемых и модифицируемых файлов перестанут соответствовать действительности.

Казалось бы, чего страшного? Ан нет, фактор времени играет в Unix-системах очень существенную роль. Во-первых, команда make (а под ее управлением компилируются программы из исходников) проверяет временные атрибуты файлов (в первую очередь — атрибут mtime) и при их несоответствии может работать с ошибками. Ну и более обычная ситуация — на основе временных меток файлов можно эффективно осуществлять, скажем, резервное копирование. И потому желательно, чтобы они отражали реальное время создания и модификации файла.

Так вот, для изменения временных атрибутов файлов и предназначена в первую очередь команда touch, которую ранее мы использовали просто для создания пустого файла. Данная же с именем существующего файла в качестве аргумента —

$ touch exist_file

она присвоит всем его временным атрибутам (atime, ctime, mtime) значения текущего момента времени. Изменение временных атрибутов можно варьировать с помощью опций. Так, если указать только одну из опций -a, -c, или -m, то текущее значение времени будет присвоено только атрибуту atime, ctime или mtime, соответственно. Если при этом использовать ещё и опцию -d [значение], то любому из указанных атрибутов (или им всем) можно присвоить любую временную метку, в том числе и из далёкого будущего. А посредством опции -r filename файл-аргумент получит временные атрибуты, идентичные таковым референсного файла filename.

Навигация по файловой системе

Следующее, что необходимо применителю после создания файлов — ориентация среди существующего их изобилия.

Для начала при неплохо определиться со своим текущим положением в файловой системе. Этому послужит команда pwd. В ответ на нее выводится полный путь к текущему каталогу. Например, если текущим является домашний каталог пользователя, в ответ на:

$ pwd

последует

/home/username

Команда pwd имеет всего две опции: -L и -P. Первая выводит т.н. логический путь к текущему каталогу. То есть, таковым является, скажем, каталог /usr/src/vboxhost-4.3.20, являющий собой символическую ссылку на каталог /usr/share/virtualbox/src/vboxhost, то в ответ на

$ pwd -L

так и будет выведено

/usr/src/vboxhost-4.3.20

Впрочем, тот же ответ последует и на команду pwd без опций вообще. Если же дать эту команду в форме

$ pwd -P

то будет выведен путь к физическому каталогу, на который ссылается текущий, например:

/usr/share/virtualbox/src/vboxhost

Далее, по каталогам неплохо как-то перемещаться. Что делается командой cd. В отличие от прочих команд, рассматриваемых в этом разделе, это — внутренняя команда, встроенная во все командные оболочки — бесполезно было бы искать соответствующий ей исполняемый файл. Однако это не уменьшает ее важности. Использование ее очень просто —

$ cd pathname

где pathname — путь к искомому каталогу в абсолютной (относительно корня) или относительной (относительно текущего каталога) форме.

Определить местоположение команды (и вообще исполняемых файлов) в структуре файловой системы можно с помощью команды which (это также встроенная команда оболочки). В качестве аргумента ее можно указать одно или несколько имен файлов, в ответ на что будет выведен полный путь к каждому из них:

$ which tcsh zsh bash

/bin/tcsh

/bin/zsh

/bin/bash

При наличии одноимённых исполняемых файлов в разных каталогах по умолчанию будет выведен путь только к первому из них: для вывода всех файлов-«тезок» можно прибегнуть к опции -a. При этом не важно, будут это жёсткие или символические ссылки.

Более широкие возможности поиска — у команды whereis. По умолчанию, без опций, она для заданного в качестве аргумента имени выводит список бинарных файлов, man-страниц и каталогов с исходными текстами:

$ whereis zsh

zsh: /bin/zsh /etc/zsh /usr/lib/zsh /usr/share/zsh

/usr/man/man1/zsh.1.gz /usr/share/man/man1/zsh.1.gz

Соответствующими опциями можно задать поиск файлов одного из этих типов: -b — бинарных, -m — страниц руководств, -s — каталогов с исходниками. Дополнительные опции -B, -M, -S (в сочетании с опцией -f) позволяют определить исходные каталоги для их поиска.

Команды locate и mlocate осуществляют поиск всех файлов и каталогов, содержащих компонент имени, указанный в качестве аргумента и осуществляют вывод содержимого найденных каталогов. Так, в ответ на команду

$ locate zsh

будет выведен список вроде следующего:

/bin/zsh

/bin/zsh-4.0.6

/etc/zsh

/etc/zsh/zlogin

/etc/zsh/zshenv

/etc/zsh/zshrc

и так далее. Команда mlocate действует точно так же. Обе они при этом обращаются к базе данных /var/lib/mlocate/mlocate.db. Исходно эта база данных пуста — и перед использованием команды locate или mlocate должна быть наполнена содержанием. Для этого предназначен сценарий /usr/bin/updatedb.mlocate. Он извлекает сведения из базы данных установленных пакетов — /var/lib/dpkg. В Mint этот сценарий автоматически запускается ежедневно посредством cron, обеспечивая регулярное обновление поисковой базы.

Информация о файлах

Наиболее универсальным средством получения практически исчерпывающей информации о файлах является команда ls. Однако для этой цели существуют и другие команды.

Общая форма запуска команды ls

$ ls [options] names

где в качестве аргумента names могут выступать имена файлов или каталогов в любом количестве. Команда эта имеет многочисленные опции, основные из которых мы и рассмотрим.

Начать с того, что команда ls, данная без всяких опций, по умолчанию выводит только имена файлов, причём опуская т.н. dot-файлы, имена которых начинаются с точки (это — некие аналоги скрытых файлов в MS DOS и Windows). Кроме того, если в качестве аргумента указано имя каталога (или аргумент не указан вообще, что подразумевает текущий каталог), из списка имен его файлов не выводятся текущий (.) и родительский (..) каталог.

Для вывода всех без исключения имен файлов (в том числе и скрытых) предназначена опция -a. Смысл опции -A близок — она выводит список имен всех файлов, за исключением символов текущего (.) и родительского (..) каталога.

Кроме имени, любой файл идентифицируется своим номером inode. Для его вывода используется опция -i:

$ ls -i

12144 content.html

и так далее. Как и многие другие, команда ls обладает способностью рекурсивной обработки аргументов, для чего предназначена опция -R, выводящая список имен файлов не только текущего каталога, но и всех вложенных подкаталогов:

$ ls -R

unixforall:

about/  apps/     diffimages/  distro/  signature.html  sys/

anons/  content/  difftext/    gentoo/  statistics/     u4articles/

 

unixforall/about:

about_lol.html  about_lol.txt  index.html

 

unixforall/anons:

anons_dc.html

Опция же -d, напротив, запрещает вывод содержимого вложенных подкаталогов.

В выводе команды ls по умолчанию имена файлов разных типов даются абсолютно одинаково. Для их визуального различия используется опция -F, завершающая имена каталогов символом слэша, исполнимых файлов — символом звездочки, символических ссылок — «собакой»; имена регулярных файлов, не имеющих атрибута исполнения, никакого символа не включают:

$ ls -F

dir1/   dir2/   dir3@   file1   file2*  file3@

Другое средство для визуального различия типов файлов — колоризация, для чего применяется опция -G. Цвета шрифта, воспроизводящего имена, по умолчанию — синий для каталогов, лиловый (magenta) для символических ссылок, красный — исполнимых файлов, и так далее. Для файлов устройств, исполнимых файлов с атрибутом «суидности», каталогов, имеющих атрибут sticky, дополнительно колоризуется и фон, на котором выводится шрифта, воспроизводящий их имена. Подробности можно посмотреть в секции ENVIRONMENT man-страницы для команды ls. Впрочем, колоризация работает не на всех типах терминалов (и не во всех командных оболочках).

По умолчанию команда ls выводит список файлов в порядке ASCII-кодов первого символа имени. Однако есть возможность его сортировки в порядке времени модификации (-t), изменения статуса (-c) или времени доступа (-tu), а также в порядке, обратном любому из перечисленных (-r). Кроме того, опция -f отменяет какую-либо сортировку списка вообще.

Информацию об объёме файлов можно получить, используя опцию -s, выводящую для имени каждого файла его размер в блоках, а также суммарные объём всех выведенных файлов:

$ ls -s ../book

total 822

656 book.html

4 content1.html

86 var_part2.html

24 command.html

38 part2.html

6 command.txt

8 shell_tmp.html

Добавление к опции -s ещё и опции -k (то есть ls -sk) выведет всю ту же информацию в килобайтах.

Как можно видеть из всех приведённых выше примеров, списки файлов по команде ls выводится в многоколоночном виде (чему соответствует опция -C, однако указывать ее нет необходимости — многоколоночный вид принят для краткого формата по умолчанию). Но можно задать и одноколоночное представление списка посредством опции -1:

$ ls -1

dir1

dir2

dir3

file1

file2

file3

До сих пор речь шла о кратком формате вывода команды ls. Однако более информативным является т.н. длинный ее формат, вывод в котором достигается опцией -l и автоматически влечет за собой одноколоночное представление списка:

$ ls -l

total 8

drwxr-xr-x  2 alv  alv  512  8 май 18:04 dir1

drwxr-xr-x  3 alv  alv  512  8 май 17:43 dir2

lrwxr-xr-x  1 alv  alv    4  9 май 07:59 dir3 -> dir2

-rw-r—r—  1 alv  alv   14  8 май 10:39 file1

-rwxr-xr-x  1 alv  alv   30  9 май 08:02 file2

lrwxr-xr-x  1 alv  alv    2  8 май 10:57 file3 -> f1

Можно видеть, что по умолчанию в длинном формате выводятся:

  • сведения о типе файла ( — регулярный файл, d — каталог, l — символическая ссылка, c — файл символьного устройства, b — файл блочного устройства) и атрибуты доступа для различных атрибутов принадлежности (о чем было сказано достаточно);

  • количество жёстких ссылок на данный идентификатор inode;

  • имя пользователя — владельца файла, и группы пользователей, которой файл принадлежит;

  • размер файла в блоках;

  • время модификации файла с точностью до месяца, дня, часа и минуты (в формате, принятом в данной locale);

  • имя файла и (для символических ссылок) имя файла-источника.

Однако это ещё не всё. Добавив к команде ls -l ещё и опцию -i, можно дополнительно получить идентификатор inode каждого файла, опция -n заменит имя владельца и группу на их численные идентификаторы (UID и GUID, соответственно), а опция -T выведет в поле времени модификации ещё и годы, и секунды:

$ ls -linT

total 8

694402 drwxr-xr-x  2 1000  1000  512  8 май 18:04:56 2002 dir1

694404 drwxr-xr-x  3 1000  1000  512  8 май 17:43:31 2002 dir2

673058 lrwxr-xr-x  1 1000  1000    4  9 май 07:59:08 2002 dir3 -> dir2

673099 -rw-r—r—  1 1000  1000   14  8 май 10:39:38 2002 file1

673059 -rwxr-xr-x  1 1000  1000   30  9 май 08:02:23 2002 file2

673057 lrwxr-xr-x  1 1000  1000    2  8 май 10:57:07 2002 file3 -> f1

Разумеется, никто не запрещает использовать в длинном формате и опции визуализации (-F и -G), и опции сортировки (-r, t, tu), и любые другие, за исключением опции -C — указание ее ведет к принудительному выводу списка в многоколоночной форме, что естественным образом подавляет длинный формат представления.

Я столь подробно остановился на описании команды ls потому, что это — основное средство визуализации файловых систем любого Unix, при умелом использовании ничуть не уступающее развитым файловым менеджерам (типа Midnight Commander или Konqueror) по своей выразительности и информативности. И отнюдь не требующее для достижения таковых вбивания руками многочисленных опций: со временем будет показано, что соответствующей настройкой последних можно добиться любого «умолчального» вывода команды ls.

Существуют и другие команды для получения информации о файлах. Например, команда под характерным именем file с аргументом в виде имени файла в состоянии определить тип его, а также характер содержания с большой детальностью. Так, для регулярных файлов она распознает:

  • исполняемые бинарные файлы с указанием их формата (например, ELF), архитектуры процессора, для которых они скомпилированы, характер связи с разделяемыми библиотеками (статический или динамический);

  • исполняемые сценарии с указанием оболочки, для которой они созданы;

  • текстовые и html-документы, часто с указанием используемого набора символов.

Последнему, впрочем, для русскоязычных документов доверять особо не следует: кодировка KOI8-R в них вполне может быть обозвана ISO-8859.

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

Наконец, команда stat (это — встроенная команда оболочки), с именем файла в качестве аргумента, выводит большую часть существенных сведений о файле в удобном для восприятия виде, например, включая идентификатор inode, режим доступа (в символьной форме), идентификаторы владельца и группы, временные атрибуты, количество жёстких и символических ссылок.

Манипулирование файлами

Перейдем к манипуляциям с существующими файлами — копированию, перемещёнию, переименованию, удалению.

Начнем с копирования — это выполняется очень простой командой, cp, имеющей, однако, весьма разнообразные аспекты применения. В самом простом своем виде она требует всего двух аргументов — имени файла-источника на первом месте и имени целевого файла — на втором:

$ cp file_source file_target

Этим в текущем каталоге создается новый файл (file_target), идентичный по содержанию копируемому (file_source). То есть область данных первого будет дублировать таковую последнего. Однако области метаданных у них будут различны изначально. Целевой файл — это именно новый файл, со своим иднетификатором inode, заведомо иными временными атрибутами; его атрибуты доступа и принадлежности в общем случае также не обязаны совпадать с таковыми файла-источника.

Новый файл может быть создан и в произвольном каталоге, к которому пользователь имеет соответствующий доступ: для этого следует только указать полный путь к нему:

$ cp file_source dir/subdir/file_target

Если в качестве второго аргумента команды указано просто имя каталога, то новый файл будет создан в нем с именем, идентичным имени файла-источника. Однако подчеркну, что в любом случае копирования создается именно новый файл, никак после этого не связанный с файлом исходным.

Если в качестве последнего аргумента выступает имя каталога, он может предваряться любым количеством аргументов — имен файлов:

$ cp file1 file2 … file3 dir/

В этом случае в целевом каталоге dir/ будут созданы новые файлы,
идентичные по содержанию файлам file1, file2 и т.д.

Если в целевом (или текущем) каталоге уже имеется файл с именем, совпадающим с именем вновь создаваемого файла, он в общем случае будет без предупреждения заменен новым файлом. Единственное средство для предотвращения этого — задание опции -i (от interactive) — при ее наличии последует запрос
на перезапись существующего файла:

$ cp -i file1 file2

overwrite file2? (y/n [n])

Как говорилось в предыдущем очерке, командная оболочка моетт быть настроена так, чтобы по умолчанию не допускать перезаписи существующих файлов. Однако если такая потребность осознанно возникнет, это можно выполнить с помощью опции -f (от force). К слову сказать, она также аннулирует действие опции -i, например, при использовании ее в псевдониме команды cp.

Имя каталога может выступать и в качестве первого аргумента команды cp. Однако это потребует опции -R (иногда допустима и опция -r — в обоих случаях от recursive). В этом случае второй аргумент также будет воспринят как имя каталога, который не только будет создан при этом, но в нем также будет рекурсивно воспроизведено содержимое каталога источника (включая и вложенные подкаталоги).

При копировании файлов, представляющих собой символические ссылки, они будут преобразованы в регулярные файлы, копирующие содержимое файлов — источников ссылки. Однако при рекурсивном копировании каталогов, содержащих символические ссылки, возможно их воспроизведение в первозданном виде. Для этого вместе с опцией -R должна быть указана одна из опций -H или -L. Однако обе они при отсутствии -R игнорируются.

Как уже было сказано, создаваемые при копировании целевые файлы по умолчанию получают атрибуты доступа и времени, не зависящие от таковых файла-источника. Обычно они определяются значением переменной umask, заданной глобально, в профильном файле командной оболочки пользователя. Однако при желании атрибуты исходного файла можно сохранить в файле целевом — для этого предназначена опция -p. Разумеется, атрибуты эти будут сохранены только в том случае, это это допустимо целевой файловой системой: не следует ожидать, что атрибуты доступа и принадлежности будут сохранены при копировании на носитель с файловой системой FAT.

Для выполнения операции копирования файла он должен иметь атрибут чтения для пользователя, выполняющего копирование; кроме того, последний должен обладать правом на изменение каталога, в который производится копирование.

Следующие две часто используемые файловые операции — переименование и перемещёние, — выполняются одной командой, mv.

Как и при копировании, при перемещёнии и переименовании одноименные файлы, ранее существовавшие в целевом каталоге, затираются, замещаясь файлами-источниками без предупреждения. Чтобы этого не случилось, используется опция -i, требующая запрос на подтверждение действия. Напротив, опция -f в принудительном порядке перезаписывает существующий файл.

Операции копирования и перемещёния/переименования выглядят сходными, однако по сути своей глубоко различны. Начать с того, что команда mv не совершает никаких действий с перемещаемыми или переименовываемыми файлами — она модифицирует каталоги, к которым приписаны имена этих файлов. Это имеет два важных следствия. Во-первых, при перемещёнии/переименовании файлы сохраняют первозданными атрибуты доступа, принадлежности и даже времени изменения метаданных (ctime) и модификации данных (mtime) — ведь ни те, ни другие при перемещёнии/переименовании файла не изменяются.

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

Файлы приходится не только создавать, но иногда и удалять. Смысл удаления файлов аналогичен их перемещнию — с самими файлами при этом ничего не происходит, а изменяются содержащие их каталоги. Удаление файлов выполняется командой

$ rm filename

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

Командой rm файлы-аргументы будут удалены в общем случае без предупреждения. Подобно командам cp и mv, для команды rm предусмотрены опции -i (запрос на подтверждение) и -f (принудительное удаление вне зависимости от настроек оболочки).

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

$ rm -file

в ответ последует сообщение об ошибке типа

rm: illegal option — l

то есть имя файла будет воспринято как опция. Для предотвращения этого такое «неправильное» имя следует предварить символом двойного дефиса и пробелом, означающими конец списка опций:

$ rm — -file

В принципе, команда rm ориентирована на удаление обычных и прочих файлов, но не каталогов. Однако с опцией -d она в состоянии справиться и с этой задачей — в случае, если удаляемый каталог пуст. Наконец, опция -R (или -r) производит рекурсивное удаление каталогов со всеми их файлами и вложенными подкаталогами.

Это делает использование опции -R весьма опасным: возможно, набивший оскомину пример

$ rm -R /

когда при наличии прав суперпользователя уничтожается вся файловая система, и утрирован, но в локальном масштабе такая операция более чем реальна.

Специально для удаления каталогов предназначена команда

$ rmdir

которая способна удалить только пустой каталог. Кроме того, с опцией -p она может сделать это и в отношении каталогов родительских — но также только в том случае, если они не содержат файлов.

Кроме простого копирования файлов, существует команда для копирования с преобразованием — dd. Обобщенный ее формат весьма прост:

$ dd [options]

то есть она просто копирует файл стандартного ввода в файл стандартного вывода, а опции описывают условия преобразования входного потока данных в выходной. Реально основными опциями являются if=file1, подменяющая стандартный ввод указанным файлов, и of=file2, проделывающая ту же операцию со стандартным выводом.

А далее — прочие условия преобразования, весьма обильные. Большинство из них принимают численные значения в блоках:

  • опции ibs=n и obs=n устанавливают размер блока для входного и выходного потоков, bs=n — для обоих сразу;

  • опция skip=n указывает, сколько блоков нужно пропустить перед записью входного потока;

  • опция count=n предписывает скопировать из входного потока лишь указанное количество блоков, отсчитываемых с начала файла-источника.

Сфера применения команды dd далеко выходит за рамки простого копирования файлов. Например, именно с ее помощью изготавливаются загрузочные флешки и SD-карты, точные копии CD в файловой системе на винчестере, преобразуются шрифтовые файлы из одного формата в другой, и ещё многое. Эта же команда может применяться для резервного копирования данных.

Архивация…

Для пользователя Windows, привыкшего к программам типа Zip/WinZip и Rar/WinRar, архивация и компрессия неразрывны, как лошади в упряжке. Однако это — вполне разные действия.

Архивация — это сборка группы файлов или каталогов в единый файл, содержащий не только данные файлов-источников, но и информацию о них — имена файлов и каталогов, к которым они приписаны, атрибуты принадлежности, доступа и времени, что позволяет восстановить как данные, так и их структуру из архива в первозданном виде. Компрессия же предназначена исключительно для уменьшения объёма, занимаемого файлами на диске (или ином носителе).

Для архивации и компрессии предназначены самостоятельные команды. Хотя архивацию и компрессию можно объединить в одной конструкции или представить так, будто они выполняются как бы в едином процессе.

Традиционное и самое распространённое средство архивации в Unix-системах — утилита tar. Обобщенный формат ее таков:

$ tar [options] archiv_name [arguments]

где archiv_name — обязательный аргумент, указывающий на имя архивного файла, с которым производятся действия, определяемые главными опциями. Формы указания опций для команды tar очень разнообразны. Исторически первой была краткая форма без предваряющего дефиса, что поддерживается и поныне. Однако в текущих версиях команды в целях единообразия утверждена краткая форма с предваряющим дефисом или дублирующая ее полная форма, предваряемая двумя дефисами. Некоторые опции (например —help — получение справки об использовании команды) предусмотрены только в полной форме.

Главные опции и указывают на то, какие действия следует выполнить над архивом в целом:

  • создание архива (опция c, -c или —create);

  • просмотр содержимого существующего архива (опция t, -t или —list);

  • распаковка архива (опция x, -x, —extract или —get).

Легко понять, что при работе с архивом как целым одна из этих главных (т.н. функциональных) опций обязательна. При манипулировании же фрагментами архива они могут подменяться другими функциональными опциями, как то:

  • r (или —append) — добавление новых файлов в конец архива;

  • u (или —update) — обновление архива с добавлением не только новых, но и модифицированных (с меньшим значением атрибута mtime) файлов;

  • -A (—catenate или —concatenate) — присоединение одного архива к другому;

  • —delete — удаление именованных файлов из архива;

  • —compare — сравнение архива с его источниками в файловой системе.

Прочие (очень многочисленные) опции можно отнести в разряд дополнительных — они определяют условия выполнения основных функций команды. Однако одна из таких дополнительных опций — f (-f или —file), значение которой — имя файла (в том числе файла устройства, и не обязательно на локальной машине), также является практически обязательной. Дело в том, что команда tar (от tape archiv) изначально создавалась для прямого резервного копирования на стриммерную ленту, и именно это устройство подразумевается в качестве целевого по умолчанию. Так что если это не так (а в нынешних условиях — не так почти наверняка), имя архивного файла в качестве значения опции f следует указывать явно.

Проиллюстрируем сказанное несколькими примерами. Так, архив из нескольких файлов текущего каталога создается следующим образом:

$ tar cf arch_name.tar file1 … file#

Если задать дополнительную опцию v, ход процесса будет отображаться на экране — это целесообразно, и в дальнейших примерах эта опция будет использоваться постоянно.

С помощью команды tar можно заархивировать и целый каталог, включая его подкаталоги любого уровня вложенности, причём — двояким образом. Так, если дать команду

$ tar cvf arch_name.tar *

файлы каталога текущего каталога (включая подкаталоги) будут собраны в единый архив, но без указания имени каталога родительского. А командой

$ tar cvf arch_name.tar dir

каталог dir будет упакован с полным сохранением его структуры.

С помощью команды

$ tar xvf arch_name.tar

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

При извлечении файлов из архива никто не обязывает нас распаковывать весь архив — при необходимости это можно сделать для одного нужного файла, следует только указать его имя в качестве аргумента:

$ tar xvf arch_name.tar filename

Правда, если искомый файл находился до архивации во вложенном подкаталоге, потребуется указать и путь к нему — от корневого для архива каталога, который будет различным для двух указанных схем архивации. Ну а для просмотра того, каким образом был собран наш архив, следует воспользоваться командой

$ tar tf arch_name.tar

Если архив собирался по первой схеме (с именами файлов в качестве аргументов, вывод ее будет примерно следующим:

dir2/

dir2/file1

example

new

newfile

tee.png

При втором способе архивации мы увидим на выводе нечто вроде

dir1/

dir1/example

dir1/new

dir1/newfile

dir1/tee.png

dir1/dir2/

dir1/dir2/file1

В данном примере опция v была опущена. Включение ее приведет к тому, что список файлов будет выведен в длинном формате, подобном выводу команды ls -l:

drwxr-xr-x alv/alv      0 10 май 11:03 2002 dir2/

-rw-r—r— alv/alv      0 10 май 11:03 2002 dir2/file1

Команда tar имеет ещё множество дополнительных опций, призванных предотвращать перезапись существующих файлов, осуществлять верификацию архивов, учитывать при архивации разного рода временные атрибуты, вызывать для исполнения другие программы. К некоторым опциям я ещё вернусь после рассмотрения команд компрессии, другие же предлагается изучить самостоятельно, воспользовавшись страницей экранной документации man tar.

Здесь уместно добавить пару слов об утилите ar, предназначенной для создания архивов, их модификации, частичной экстракции из них файлов и полного развёртывания. Подобно tar, это — чистый архиватор, не выполняющий никакой компрессии. И, насколько я знаю, практически не используемый для архивирования данных, в частности, для резервного копирования. Но исторически сложилось так, что именно утилитой ar в конечном счёте упаковываются компоненты пакетов deb-формата, используемого в Mint (и многих других дистрибутивах).

… и компрессия

Утилита gzip — это традиционный компрессор Unix-систем, сменивший в сей роли более старую утилиту compress. Простейший способ её использования таков:

$ gzip filename

где в качестве аргументов будет выступать имя файла. При этом (внимание!) исходный несжатый файл подменяется своей сжатой копией, которой автоматически присваивается расширение *.gz.

В качестве аргументов может выступать и произвольное количество имен файлов — каждый из них будет заменен сжатым файлом *.gz. Более того, посредством опции -r может быть выполнено рекурсивное сжатие файлов во всех вложенных подкаталогах. Подчеркну, однако, что никакой архивации команда gzip не производит, обрабатывая за раз только единичный файл. Фактически форма

$ gzip file1 file2 … file#

просто эквивалент последовательности команд

$ gzip file1

$ gzip file2

$ gzip file#

Правда, объединение компрессированных файлов возможно методом конкатенации (с помощью команды cat) или посредством архивирования командой tar.

Команда gzip имеет и другие опции, указываемые в краткой (однобуквенной) или полной нотации. В отличие от tar, знак дефиса (или, соответственно, двойного дефиса) обязателен в обоих случаях. Так, опциями -1-9 можно задать степень сжатия и, соответственно, время исполнения процедуры: -1 соответствует минимальному, но быстрому сжатию, -9 — максимальному, но медленному. По умолчанию в команде gzip используется опция -6, обеспечивающая разумный компромисс между скоростью и компрессией.

Благодаря опции -d (—decompress) команда gzip может выполнить развертывание сжатого файла, заменяя его оригиналом без расширения *.gz. Хотя в принципе для этого предназначена команда gunzip:

$ gunzip file.gz

Использование этой команды настолько прозрачно, что я задерживаться на ней не буду. Замечу только, что утилита gzip интегрирована в архиватор tar, вызвываясь из него опцией z. То есть для создания компрессированного архива потребуется такая команда:

$ tar czf archive.tar.gz path2/

А для декомпрессии и развёртывания архива — такая:

$ tar xzf archive.tar.gz

В обоих случаях не принесёт вреда добавление опции v — она обеспечит вывод на экран сообщеня о ходе процесса.

В относительно недавнее время некоторое распространение получил компрессор bzip2, обеспечивающий большую (на 10-15%) степень сжатия, хотя и менее быстродействующий. Использование его практически идентично gzip, с деталями его можно ознакомиться с помощью страницы экранной документации man bzip2.

Итоговый компрессированный файл получает имя вида *.bz2 и может быть распакован командой bunzip2 (или командой bzip2 -d). Следует только помнить, что форматы *.gz и *.bz2 не совместимы между собой. Соответственно, первый не может быть распакован программой bunzip2, и наоборот.

Как и gzip, утилита bzip2 может быть вызвана из архиватора tar — при создании компрессированного архива так:

$ tar cjf archive.tar.bz2 path2/

А при развёртывании оного — эдак:

$ tar xjf archive.tar.bz2

Особо задерживаться на этой утилите не хочется ещё и потому, что, мне кажется, вскоре она выйдет из употребеления. Ибо, обеспечивая меньшую степень сжатия по сравнению с форматом xz (о котором сейчас будет речь), bzip2 отнюдь не превосходит его по скорости компрессии и декомпрессии. И там, где критично именно время упаковки (а также универсальность), будет по прежнему использоваться старый добрый gzip. Там же, где на первый план выходит степень сжатия, карты в руки новому формату xz. Который, кстати, на мощных машинах по скорости создания и распаковки вплотную приближается к gzip.

Реализацией формата xz является набор утилит XZ Utils, основанный на алгоритме LZMA (Lempel-Ziv-Markov chain-Algorithm). Сам по себе метод сжатия LZMA существует достаточно давно: он был разработан нашим соотечественником Игорем Павловым с использованием достижений предшественников, разработавших алгоритмы LZ77, LZ78 и LZV — что, впрочем, могло бы составить предмет отдельной истории, которую когда-нибудь кто-нибудь напишет.

А метод LZMA был задействован его автором в собственной же разработке — утилите компрессии 7-Zip для Windows, быстро снискавшей славу несравненного «сжимателя» файлов. Инструментарий для разработки программ, использующих данный метод (LZMA SDK) распространялся сначала на условиях лицензии GPL, что позволяло использовать его в соответствующих проектах (например, в GNU tar). Однако в конце 2008 года Игорь Павлов превратил его в общественное достояние (Public Domain). Вслед за чем был создан основанный на этом методе пакет LZMA Utils, немедленно встроенный в tar. Что сделало этот метод компрессии столь же простым и обыденным, как gzip или bzip2. И с тех пор эта возможность, после установки соответствующего пакета, присутствует во всех дистрибутивах Linux.

Правда, вслед за тем появился LZMA2, улучшенная версия того же алгоритма, обеспечивающий более высокую степень сжатия и лучшую поддержку многопоточности. А на его основе был создан пакет XZ Utils — именно он в настоящее время используется в Mint по умолчанию. И включает в себя такие команды:

xz — компрессор и, при указании опции —decompress, декомпрессор;

unxz — собственно декомпрессор;

xzcat осуществляет декомпрессию на стандартный вывод;

xzmore и xzless — pager’ы для lzma-компрессированных текстовых файлов;

xzgrep, xzegrep, xzfgrep — поиск текстовых фрагментов в xz-компрессированных файлах.

Последние три утилиты работают аналогично командам xzgrep, xzegrep, xzfgrep, применённым к некомпрессированным файлам. А команда xzcat является аналогом утилиты cat. Об этих четырёх командах будет подробно говориться в ближайших разделах.

Утилиты пакета XZ Utils могут, с некоторыми ограничениями, работать с файлами, запакованными старым методом LZMA1 (но не наоборот). Хотя сами по себе пакеты XZ Utils и LZMA Utils между собой конфликтуют.

Разумеется, поддержка XZ была немедленно встроена и в tar. Так что теперь для применения компрессии LZMA2 при создании tar-архива достаточно указать соответствующую опцию:

$ tar —create —xz —file filename.tar.xz path2/arch_dir

Или, в более употребимой простыми людьми краткой форме, так:

$ tar cJf filename.tar.lzma path2/arch_dir

где опция J и представляет собой алиас для полной формы -xz. Если присваивать архивному файлу суффикс по правилам утилиты tar, опцию J можно заменить на a (что эквивалентно полной форме —auto-compress), обеспечивающей определение типа компрессии по «расширению» *.xz. Более того, скажу по секрету: если архив именован по правилам, то можно опустить даже опцию —auto-compress — она и так будет задействована по умолчанию.

Распаковка xz-компрессированного архива выполняется в обратном порядке:

$ tar xJf filename.tar.xz

или
$ tar xaf filename.tar.xz

Метод LZMA и особенно LZMA2 вследствие эффективности компрессии быстро нашёл себе применение в сборке дистрибутивных пакетов: именно с его помощью в настоящее время сжимаются deb-пакеты Mint (и всех других дистрибутивов, использующих этот формат пакетов).

Утилита find и xargs при ней

На этих страницах речь пойдет о пакете, известном в проекте GNU как findutils. И в первую голову — о команде find (как, впрочем, и о тесно связанной с ней команде xargs). Столь высокая честь выпадает им потому, что посредством этих двух команд можно выполнить если не все, то изрядную задач, возникающих при работе с файлами.

Итак, апофеоз командного файлового менеджмента — утилита find. Строго говоря, вопреки своему имени, команда эта выполняет не поиск файлов как таковой, но — рекурсивный обход дерева каталогов, начиная с заданного в качестве аргумента, отбирает из них файлы в соответствие с некоторыми критериями и выполняет над отбракованным файловым хозяйством некоторые действия. Именно эту ее особенность подчеркивает резюме команды find, получаемое (в некоторых системах) посредством

$ whatis find

find(1)                  — walk a file hierarchy

что применительно случаю можно перевести как «прогулка по файловой системе».

Команда find по своему синтаксису существенно отличается от большинства прочих Unix-команд. В обобщенном виде формат ее можно представить следующим образом:

$ find аргумент [опция_поиска] [значение] [опция_действия]

В качестве аргумента здесь задается путь поиска, то есть каталог, начиная с которого следует совершать обход файловой системы, например, корень ее:

$ find / [опция_поиска] [значение]

        [опция_действия]

или домашний каталог пользователя:

$ find ~/ [опция_поиска] [значение]

        [опция_действия]

Опция поиска — критерий, по которому следует отбирать файл (файлы) из определенных в аргументе частей файловой системы. В качестве таковых могут выступать имя файла (-name), его тип (-type), атрибуты принадлежности, доступа или времени.

Ну а опция действия определяет, что же надлежит сделать с отобранными файлом или файлами. А сделать с ними, надо заметить, можно немало — начиная с вывода на экран (-print, опция действия по умолчанию) и кончая передачей в качестве аргументов любой другой команде (-exec).

Как можно видеть из примера, опция поиска и опция действия предваряются знаком дефиса, значение первой отделяется от ее имени пробелом.

Однако начнём по порядку. Опции поиска команды find позволяют выполнить отбор файлов по следующим критериям (символ дефиса перед опциями ниже опущен, но не следует забывать его ставить):

  • name — поиск по имени файла или по маске имени; в последнем случае метасимволы маски должны обязательно экранироваться (например, — name \*.tar.gz) или заключаться в кавычки (одинарные или двойные, в зависимости от ситуации); этот критерий чувствителен к регистру, но близкий по смыслу критерий iname позволяет производить поиск по имени без различения строчных и заглавных букв;

  • type — поиск по типу файла; этот критерий принимает следующие значения: f (регулярный файл), d (каталог), s (символическая ссылка), b (файл блочного устройства), c (файл символьного устройства);

  • user и group — поиск по имени или идентификатору владельца или группы, выступающим в качестве значения критерия; существует также критерии nouser и nogroup — они отыскивают файлы, владельцев и групповой принадлежности не имеющие (то есть тех, учетные записи для которых отсутствую в файлах /etc/passwd и /etc/group); последние два критерия в значениях, разумеется, не нуждаются;

  • size — поиск по размеру, задаваемому в виде числа в блоках или в байтах — в виде числа с последующим символом c; возможны значения n (равно n блоков), +n (более n блоков), -n (менее n блоков);

  • perm — поиск файлов по значениям их атрибутов доступа, задаваемых в символьной форме;

  • atime, ctime, mtime — поиск файлов с указанными временными атрибутами; значения временных атрибутов указываются в сутках (точнее, в периодах, кратных 24 часам); возможны формы значений этих атрибутов: n (равно указанному значению n*24 часа), +n (ранее n*24 часа), -n (позднее n*24 часа);

  • newer — поиск файлов, измененных после файла, указанного в качестве значения критерия (то есть имеющего меньшее значение mtime);

  • maxdepth и mindepth позволяют конкретизировать глубину поиска во вложенных подкаталогах — меньшую или равную численному значению для первого критерия и большую или равную — для второго;

  • depth — производит отбор в обратном порядке, то есть не от каталога, указанного в качестве аргумента, а с наиболее глубоко вложенных подкаталогов; смысл этого действия — получить доступ к файлам в каталоге, для которого пользователь не имеет
    права чтения и исполнения;

  • prune — позволяет указать подкаталоги внутри пути поиска, в которых отбора файлов производить не следует.

Кроме этого, существует ещё одна опция поиска — fstype, предписывающая выполнять поиск только в файловой системе указанного типа; очевидно, что она может сочетаться с любыми другими опциями поиска. Например, команда

$ find / -fstype ext3 -name zsh*

будет искать файлы, имеющие отношение к оболочке Z-Shell, начиная с корня, но только — в пределах тех разделов, на которых размещёна файловая система Ext3fs (на моей машине — это именно чистый корень, за вычетом каталогов /usr, /opt, /var, /tmp и, конечно же, /home.

Критерии отбора файлов могут группироваться практически любым образом. Так, в форме

$ find ~/ -name *.tar.gz newer filename

она выберет в домашнем каталоге пользователя все компрессированные архивы, созданные после файла с именем filename. По умолчанию между критериями отбора предполагается наличие логического оператора AND (логическое «И»). То есть будут отыскиваться файлы, удовлетворяющие и маске имени, и соответствующему атрибуту времени. Если требуется использование оператора OR (логическое «ИЛИ»), он должен быть явно определен в виде дополнительной опции -o между опциями поиска. Так, команда:

$ find ~/ -mtime -2 -o newer filename

призвана отобрать файлы, созданные менее двух суток назад, или же — позднее, чем файл filename.

Особенность GNU-реализации команды find (как, впрочем, и ее тезки из числа BSD-утилит) — то, что она по умолчанию выводит список отобранных в соответствии с заданными критериями файлов на экран, не требуя дополнительных опций действия. Однако, как говорят, в других Unix-системах (помнится, даже и в некоторых реализациях Linux мне такое встречалось) указание какой-либо из таких опций — обязательно. Так что рассмотрим их по порядку.

Для выведения списка отобранных файлов на экран в общем случае предназначена опция -print. Вывод этот имеет примерно следующий вид:

$ find . -name f* -print

./file1

./file2

./dir1/file3

Сходный смысл имеет и опция -ls, однако она выводит более полные сведения о найденных файлах, аналогично команде ls с опциями -dgils:

$ find / -fstype ext3 -name zsh -ls

88161  511 -rwxr-xr-x   1 root  root    519320 Ноя 23 15:50 /bin/zsh

Важное, как мне кажется, замечание. Если команда указанного вида будет дана от лица обычного пользователя (не root-оператора), кроме приведенной выше строки вывода, последуют многочисленные сообщения вроде

find: /root: Permission denied

указывающие на каталоги, закрытые для просмотра обычным пользователем, и весьма мешающие восприятию результатов поиска. Чтобы подавить их, следует перенаправить вывод сообщения об ошибках в файл /dev/null, то есть указать им «Дорогу никуда»:

$ find / -fstype ext3 -name zsh -ls 2> /dev/null

Идем далее. Опция -delete уничтожит все файлы, отобранные по указанным критериям. Так, командой

$ find ~ -atime +100 -delete

будут автоматически стерты все файлы, к которым не было обращения за последние 100 дней (из молчаливого предположения, что раз к ним три месяца не обращались — значит, они и вообще не нужны). Истреблению подвергнутся файлы в подкаталогах любого уровня вложенности — но не
включающие их подкаталоги (если, конечно, последние сами не подпадают под критерии отбора).

И, наконец, опция -exec — именно ею обусловлено величие утилиты find. В качестве значения ее можно указать любую команду с необходимыми опциями — и она будет выполнена над отобранными файлами, которые будут рассматриваться в качестве ее аргументов. Проиллюстрируем это на примере.

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

$ find ~/ -atime +100 -exec rm -i {} ;

В этом случае (вне зависимости от настроек псевдонимов командной оболочки) на удаление каждого отобранного файла будет запрашиваться подтверждение.

Обращаю внимание на последовательность символов {} \; (с пробелом между закрывающей фигурной скобкой и обратным слэшем) в конце строки. Пара фигурных скобок {} символизирует, что свои аргументы исполняемая команда (в примере — rm) получает от результатов отбора команды find, точка с запятой означает завершение команды-значения опции -exec, а обратный слэш экранирует ее специальное значение от интерпретации командной оболочкой.

Кроме опции действия -exec, у команды find есть ещё одна, близкая по смыслу, опция — -ok. Она также вызывает некую произвольную команду, которой в качестве аргументов передаются имена файлов, отобранные по критериям, заданным опцией (опциями) поиска. Однако перед выполнением каждой операции над каждым файлом запрашивается подтверждение.

Приведенный на предыдущей странице пример, хотя и вполне жизненный, достаточно элементарен. Рассмотрим более сложный случай — собирание в один каталог всех скриншотов в формате PNG, разбросанных по древу домашнего каталога:

$ find ~/ -name *.png -exec cp {} imagesdir ;

В результате все png-файлы будут изысканы и скопированы (или — перемещёны, если воспользоваться командой mv вместо cp) в одно место.

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

Зачем и отчего это нужно? Поясню на примере. Как-то раз, обзаведясь огромным по тем временам (40 Гбайт) винчестером, я решил собрать на него все нужные мне данные, рассеянные по дискам CD-R/RW (суммарным объёмом с полкубометра) и нескольким сменным винчестерам, одни из которых были отформатированы в FAT16, другие — в FAT32, третьи — вообще в ext2fs (к слову сказать, рабочей моей системой в тот момент была FreeBSD). Сгрузив все это богачество в один каталог на новом диске, я создал в нем весьма неприглядную картину.

Ну, во-первых, все файлы, скопированные с CD и FAT-дисков, получили (исключительно из-за неаккуратности монтирования, с помощью должных опций этого можно было бы избежать, но — спешка, спешка…) биты исполняемости, хотя были это лишь файлы данных. Казалось бы, мелочь, но иногда очень мешающая; в некоторых случаях это не позволяет, например, просмотреть html-файл в Midnight Commander простым нажатием Enter. Во-вторых, для некоторых каталогов, напротив, исполнение не было предусмотрено ни для кого — то есть я же сам перейти в них не мог. В третьих, каталоги (и файлы) с CD часто не имели атрибута изменения — а они нужны мне были для работы (в т.ч. и редактирования). Конечно, от всех этих артефактов можно было бы избавиться, предусмотрев должные опции монтирования накопителей (каждого накопителя — а их число, повторяю, измерялось уже объёмом занимаемого пространства), да я об этом и не подумал — что выросло, то выросло. Так что ситуация явно требовала исправления, однако проделать вручную такую работу над данными более чем в 20 Гбайт виделось немыслимым.

Да так оно, собственно, и было бы, если б не опция -exec утилиты find. Каковая позволила изменить права доступа требуемым образом. Итак, сначала отбираем все регулярные файлы и снимаем с них бит исполнения для всех, заодно присваивая атрибут изменения для себя, любимого:

$ find ~/dir_data -type f

        -exec chmod a-x,u+w {} ;

Далее — поиск каталогов и обратная процедура над итоговой выборкой:

$ find ~/dir_data -type d

        -exec chmod a+xr,u+w {} ;

И дело — в шляпе, все права доступа стали единообразными (и теми, что мне нужны). Именно после этого случая я, подобно митьковскому Максиму, проникся величием философии марксизма (пардон, утилиты find). А ведь это ещё не предел ее возможностей — последний устанавливается только встающими задачами и собственной фантазией…

Так, с помощью команды find легко наладить периодическое архивирование результатов текущей работы. Для этого перво-наперво создаем командой tar полный архив результатов своей жизнедеятельности:

$ tar cvf alldata.tar ~/*

А затем в меру своей испорченности (или, напротив, аккуратности), время от времени запускаем команду

$ find ~/ -newer alldata.tar

        -exec tar uvf alldata.tar {} ;

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

А пока — об ограничении возможностей столь замечательной сцепки команды find с опцией действия -exec (распространяющиеся и на опцию -ok). Оно достаточно очевидно: вызываемая любой из этих опций команда выполняется в рамках самостоятельного процесса, что на слабых машинах, как говорят, приводит к падению производительности (должен заметить, что на машинах современных заметить этого практически невозможно).

Тем не менее, ситуация вполне разрешима. И сделать это призвана команда xargs. Она определяется как построитель и исполнитель командной строки со стандартного ввода. А поскольку на стандартный ввод может быть направлен вывод команды findxargs воспримет результаты ее работы как аргументы какой-либо команды, которую, в свою очередь, можно рассматривать как аргумент ее самоё (по умолчанию такой командой-аргументом является /bin/echo).

Использование команды xargs не связано с созданием изобилия процессов (дополнительный процесс создается только для нее самой). Однако она имеет другое ограничение — лимит на максимальную длину командной строки. Во всех BSD-системах, которые мне довелось видеть, этот лимит составляет 65536, что определяется командой следующего вида:

$ sysctl -a | grep kern.argmax

И способы изменить этот лимит мне не известны — был бы благодарен за соответствующую информацию.

Команды обработки текстов: введение

Только что речь шла о командах, которые манипулируют файлами как целыми, не затрагивая их содержания (и, в общем случае, от такового не зависящих). Ныне же речь пойдет о командах, создающих и изменяющих внутреннее содержание файлов, правда, только текстовых.

Конечно, само по себе манипулирование файлами (копирование, перемещёние и т.д.) также подразумевает изменение содержания некоторых файлов, но только одного-единственного типа (а именно — каталогов), однако собственно внутренняя сущность обычных файлов при этом не изменяется. Предметом же настоящей интермедии будут штатные средства POSIX-систем, позволяющие в той или иной мере учитывать контент файлов и манипулировать им. Разумеется, манипулирование контентом возможно только для регулярных файлов. При этом многие их разновидности (бинарные файлы, файлы графических форматов и word-процессоров) требуют для изменения своего содержания специальных средств — а именно, компиляторов и прикладных программ, в которых они создавались. Однако здесь о них разговора не будет — ибо целью моей было продемонстрировать мощь обычных команд для решения многих пользовательских задач. Правда, на самом деле команды модификации контента действенны преимущественно для файлов текстовых.

Однако круг объектов таких команд не столь уж узок, как может показаться. Ведь именно в виде обычных текстовых файлов в ОС POSIX-семейства хранится масса общесистемной информации, исполняемых сценариев, баз данных атрибутов самых разных объектов. Далее — собственно нарративные тексты любого содержания: ведь чисто текстовый формат для них куда роднее, чем всякого рода *.doc и *rtf. Ну и никем не возбраняется использовать такие команды в отношении текстов с разметкой — HTML ли, XML, TeX или ещё чего. Так что поле приложения рассматриваемых команд — достаточно обширно.

Просмотр файлов

Однако прежде чем как-то манипулировать контентом файлов, желательно этот самый контент некоторым образом просмотреть. И тут можно вспомнить о команде cat, посредством которой мы некогда создавали файлы. Данная с именем файла в качестве аргумента, она выведет его содержимое на экран. Можно использовать и конструкцию перенаправления:

$ cat < filename

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

Недостаток команды cat как средства просмотра — невозможность перемещёния
по телу файла: выведя содержимое, она завершает свою работу. Конечно, «пролистывание» выведенного возможно, но — средствами системной консоли, а не самой команды.

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

В Unix-системах имеется две основные программы pager’а — more и less. Первая из них допускает только однонаправленный (вперед) просмотр и имеет слабые интерактивные возможности. Почему ныне и представляет лишь исторический интерес, так что о ней я говорить не буду. Тем более, что в современных свободных POSIX-системах она как таковая отсутствует: файл с именем /usr/bin/more, который можно обнаружить во FreeBSD и некоторых дистрибутивах Linux, на самом деле представляет собой жёсткую или символическую ссылку на ту же самую программу, что и команда less. Хотя эта программа проявляет несколько различные свойства, в зависимости от того, какой из указанных команд она вызвана, функции ее от этого не меняются. Так что дальше я буду говорить только о команде less.

Самый простой способ вызова команды

$ less filename

после чего на экран выводится содержимое файла, указанного в качестве аргумента, по которому можно перемещаться в обоих направлениях, как построчно, так и постранично. В нижней строке экрана можно видеть символ двоеточия — приглашения для ввода команд различного назначения. В частности, нажатие клавиши h выводит справку по использованию less, а клавиши q — выход из программы просмотра (или из просмотра справочной системы, если она была перед этим вызвана). Если команда была вызвана как more (это достигается ещё и специальной опцией — less -m), вместо символа двоеточия в нижней строке будет выведено имя файла с указанием процента просмотра:

command.txt 3%

что, однако, не воспрещает и здесь давать ее встроенные команды — вводом символа двоеточия (:) и закрепленной за командой литеры (или их сочетания).

Большинство встроенных команд less предназначено для навигации по телу файла. Осуществляется она несколькими способами:

  • с помощью стандартных клавиш управления курсором: PageDown или Spacebar (вперед на один экран), PageUp (назад на один экран), Down или Enter (вперед на одну строку), Up (назад на одну строку), Right (на пол-экрана вправо), Left (на пол-экрана влево);

  • с помощью предопределенных клавишных комбинаций, сходных с управляющими клавиатурными последовательностями командных оболочек и таких текстовых редакторов, как emacs и joe (хотя и не всегда с ними совпадающими): Control+V (на один экран вперед), EscapeV (на один экран назад), Control+N (на одну строку вперед), Control+P (на одну строку назад);

  • с помощью фиксированных символьных клавиш, иногда подобных таковым командного режима редактора vi: z и w (вперед и назад на один экран), e и y (вперед и назад на одну строку, можно использовать также привычные по vi клавиши j и k, соответственно), d и u (вперед и назад на пол-экрана).

Последний способ интересен тем, что допускает численные аргументы перед символьной командой: так, нажатие 3e приведет к перемещёнию на три строки вперед, а 2w — на два экрана назад.

Помимо «плавной», так сказать, навигации, можно перемещаться по файлу и скачками (jumping): нажатие клавиши с символом g (или последовательности Escape<) позволяет переместиться к первой строке файла, клавиши G (регистр важен! дублирующий вариант — Escape>) — к последней его строке, клавиши p
к началу файла.

Кроме навигации, имеется и возможность двустороннего поиска — в направлении как конца, так и начала файла. Для поиска вперед требуется ввести символ прямого слэша (/) и за ним — искомое сочетание символов. Поиск в обратном направлении предваряется символом вопроса (?). В обоих случаях в шаблоне поиска можно использовать стандартные регулярные выражения *, ?, [список_символов] или [диапазон_символов]. Нажатие клавиши n (в нижнем регистре) приводит к повторному поиску в заданном ранее направлении, клавиши N (в верхнем регистре) — к поиску в направлении противоположном.

Управляющие комбинации команды less могут быть переопределены с помощью команды lesskey. Формат ее

$ lesskey -o output input

В качестве входных данных выступает простой текстовый файл (по умолчанию — ~/.lesskey, однако его следует создать самостоятельно), описывающий клавишные последовательности в следующем, например, виде:

#command

\r        forw-line

\n        forw-line

k         back-line

Выходные данные — создаваемый из текстового двоичный файл, который собственно и используется командой less. Стандартное для него имя — ~/.less.

Команда less допускает одновременный просмотр нескольких файлов. Для этого ее следует вызвать в форме

$ less file1 file2 … file#

после чего между открытыми файлами можно переключаться посредством :n (к следующему файлу), :p (к предыдущему файлу), :x (к первому файлу). Путем нажатия :d текущий файл исключается из списка просмотра. Символ двоеточия во всех этих случаях вводится с клавиатуры в дополнение к приглашению на ввод
команд.

Команда less имеет великое множество опций — описание их на странице экранной документации занимает более дюжины страниц, поэтому задерживаться на них я не буду. Следует заметить только, что опции эти могут использоваться не только в командоной строке при запуске less, но и интерактивно — после символа дефиса в приглашении ввода. Так, указав там -m, можно включить т.н. промежуточный формат приглашения (с отображением процентов просмотренного объёма файла), а с помощью -M — длинный (more-подобный) формат, при котором в приглашении дополнительно указываются имя файла, его положение в списке загруженных файлов, просматриваемые ныне строки:

command.html (file 2 of 10) lines 1-29/1364 2%

Значение команд постраничного просмотра файлов ещё и в том, что именно с их помощью осуществляется доступ к экранной документации (man-страницам). Команда

$ man cmd_name

как было описано в предыдущей интермедии, на самом деле вызывает определенный по умолчанию pager для просмотра соответствующего файла /usr/share/man/man#/cmd_name.gz. Какой именно — определяется переменной PAGER в пользовательских настройках.

Кроме команд постраничного просмотра, существуют команды для просмотра фрагментарного. Это — head и tail, выводящие на экран некоторую фиксированную порцию файла, указанного в качестве их аргумента, с начала или с конца, соответственно. По умолчанию эта порция для обеих команд составляет десять строк (включая пустые). Однако ее можно переопределитьg произвольным образом, указав опции -n [число_линий] или -c [количество_байт]. Например, команда

$ head -n 3 filename

выведет три первые строки файла filename, а команда

$ tail -c 100 filename

его последние 100 байт. При определении выводимого фрагмента в строках название опции (n) может быть опущено — достаточно числа после знака дефиса.

Существуют и средства просмотра компрессированных файлов. Для файлов, сжатых программой gzip, можно использовать команды zcat и zmore, для спрессованных командой bzip2 — команду bzcat. Использование их ничем не отличается от аналогов для несжатых файлов — в сущности, именно они и вызываются для обеспечения просмотра. В случае команды zmore, как нетрудно догадаться, на самом деле используется команда less (сама по себе она аналога для компрессированных файлов не имеет).

Сравнение, объединение и деление файлов

Следующая важная группа операций над контентом файлов — сравнение файлов по содержанию и различные формы объединения файлов и их фрагментов. Начнем со сравнения. Простейшая команда для этого — cmp в форме

$ cmp file1 fil2

производит построчное сравнение файлов, указанных как первый и второй аргументы (а более их и не предусмотрено, все указанное после второго аргумента игнорируется). В случае идентичности сравниваемых файлов не происходит ничего, кроме возврата приглашения командой строки. Если же между файлами имеются различия, выводится номер первого различающегося символа и номер строки, в которой он обнаружен:

file1 file2 differ: char 27, line 4

Это означает, что различия между файлами начинаются с 27-го от начала файла символа (включая пробелы, символы конца строк и т.д.), который имеет место быть в строке 4. С помощью опций -l и -z можно заставить команду cmp вывести номера всех различающихся символов в десятичном или шестнадцатеричном формате, соответственно.

Более информативный вывод обеспечивает команда diff. Она также осуществляет построчное сравнение двух файлов, но выводит список строк, в которых обнаружены отличия. Например, для двух файлов вида

$ less file1

line 1

line 2

line 3

line 4

line 5

и

$less file2

line 1

line 2

line 3

line 3a

line 4

line 5

это будет выглядеть следующим образом:

$ diff file1 file2

3a4

> line 3a

Если различия будут выявлены более чем в одной строке, для каждого расхождения будет выведен аналогичный блок. Смысл его — в том, какие строки первого файла должны быть преобразованы, и как именно, для того, чтобы файлы стали идентичными. Первая линия блока вывода содержит номер строки первого файла, подлежащей преобразованию, номер соответствующей строки второго файла и обозначенное буквенным символом преобразование, во второй линии приведена собственно строка — предмет преобразования. Символы преобразования —
следующие:

  • a (от append) указывает на строку, отсутствующую в первом файле, но присутствующую во втором;

  • c (от change) фиксирует строки с одинаковым номером, но разным содержанием;

  • d (от delete) определяет строки, уникальные для первого файла.

То есть в данном примере для преобразования file1 в file2 в него после строки 3 должна быть вставлена строка 4 из второго файла, что символизирует вторая линия блока — > line 3a, где > означает строку из первого сравниваемого файла. Если же аргументы команды diff дать в обратном порядке, вывод ее будет выглядеть следующим образом:

$ diff file2 file1

4d3

< line 3a

показывающим, что для достижения идентичности из file2 должна быть удалена
четвертая строка (< line 3a, где < означает строку из второго файла). Если же произвести сравнение file1 с file3, имеющим вид

$ less file3

line 1

line 2

line 3a

line 4

line 5

то вывод команды

$ diff file1 file3

3c3

< line 3

> line 3a

будет означать необходимость замены третьей строки из file1 (символ <) на третью строку из file3 (символ >).

Такая форма вывода команды diff называется стандартной. С помощью опции -c можно задать т.н. контекстную форму вывода, при которой на экран направляется не только различающиеся строки, но и строки, их окружающие (то есть контекст, в котором они заключены):

diff -c file1 file2

*** file1       Sun May 12 11:44:44 2002

— file2       Mon May 13 15:17:27 2002

***************

*** 1,5 ****

— 1,6 —-

  line 1

  line 2

  line 3

+ line 3a

  line 4

  line 5

Количество строк контента задается опцией -C:

diff -C 1 file1 file2                                      ttyv1

*** file1       Sun May 12 11:44:44 2002

— file2       Mon May 13 15:17:27 2002

***************

*** 3,4 ****

— 3,5 —-

  line 3

+ line 3a

  line 4

В этом примере значение опции -C (единица) предписывает вывод по одной строке контекстного окружения вокруг различающейся строки. Сами же различающиеся строки помечаются следующим образом: знаком (минус, или дефис) — строки, подлежащие удалению из первого файла, знаком + (как в примере) — строки, которые должны быть добавлены, знаком ! — просто различающиеся строки.

Кроме контекстного формата, используется ещё и вывод в унифицированном формате, что предписывается опцией -U [значение], в качестве значения указывается число строк. В нем для обозначения изменяемых строк используются только символы + и , а сам вывод чуть короче, чем при использовании контекстного формата.

С помощью многочисленных опций команды diff сравнение файлов может быть детализовано и конкретизировано. Так, опция -b предписывает игнорировать «пустые» символы пробелов и табуляции в конце строк, а опция -w — вообще «лишние» пробелы (и те, и другие обычно имеют случайное происхождение). При указании опции -B игнорируются пустые строки, то есть не содержащие никаких иных символов, кроме перевода каретки; строки с символами табуляции или пробела как пустые не рассматриваются, для их игнорирования требуется опция -w. Благодаря опции -i при сравнении не принимается во внимание различие регистров символов, а опция -I regexp определяет регулярные вырвжения, строки с которыми также игнорируются при сравнении.

В качестве аргументов команды diff (одного или обоих) могут выступать также каталоги. Если каталогом является только один из аргументов, для сравнения в нем отыскивается файл, одноименный второму аргументу. Если же оба аргумента суть каталоги, в них происходит сравнение всех одноимённых файлов в алфавитном порядке (вернее, в порядке ASCII-кода первого символа имени, разумеется). Благодаря опции -r сравнение файлов может осуществляться и во вложенных подкаталогах.

Вывод команды diff может быть перенаправлен в файл. Такие файлы различия именуются diff-файлами или, применительно к исходным текстам программ, патчами (patches), о которых будет сказано несколько позже. Именно с помощью таких патчей обычно распространяются изменения к программам (дополнения, исправления ошибок и т.д.).

В принципе, команда diff и придумана была именно для сравнения файлов исходников, над которыми ведут работу несколько (в пределе — неограниченное количество, как в случае с Linux) человек. Однако невозбранно и ее использование в мирных целях — то есть для сравнения просто повествовательных текстов. Единственное, что следует понимать при этом абсолютно ясно — то, что diff выполняет именно построчное сравнение. То есть: сравнение последовательностей символов, ограниченных символами конце строки с обеих сторон. И, соответственно, непрерывная абзацная строка в стиле emacs и vi — совсем не то же самое, что строка, образуемая в редакторе joe на границе экрана. Впрочем, это — вопрос, к которому ещё не раз придется возвращаться.

Как уже было отмечено, команда diff осуществляет сравнение двух файлов (или — попарное сравнение файлов из двух каталогов). Однако, поскольку Бог, как известно, любит троицу, есть и команда diff3, позволяющая сранить именно три файла, указываемые в качестве ее аргументов. По действию она не сильно отличается от двоичного аналога. И потому изучение ее особенностей предлагается в качестве самостоятельного упражнения приверженцам троичной идеологии.

Существуют и средства для сравнения сжатых файлов. Это — zcmp и zdiff. Подобно командам просмотра, ими просто вызываются соотвествтующие команды cmp и diff. И потому использование их не имеет никаких особенностей.

От вопроса сравнения файлов плавно перейдем к рассмотрению способов их объединения. Для этого существует немало команд, из которых по справедливости первой должна идти команда cat, поскольку именно сие есть ее титульная функция (cat — от concatenation, сиречь объединения). Ранее уже упоминалось, что она способна добавлять информацию со стандартного ввода в конец существующего файла. Однако дело этим не ограничивается. В форме

$ cat file1 file2 … file# > file_all

она создает новый файл, включающий в себя содержимое всех файлов-аргументов (и именно в том порядке, в каком они приведены в командной строке). Операция, казалось бы, нехитрая — однако представьте, сколько действий потребовалось бы в текстовом процессоре (например, в Word’е) для того, чтобы создать синтетический вариант из полутора десятков фрагментов, раскиданных по разным каталогам?

А вот команда patch выступает в качестве диалектической пары для команды diff, именно она вносит в файл те изменения, которые документируются последней. Выглядит эта команда примерно так:

$ patch file1 diff_file

в ответ на что последует нечто вроде следующего вывода:

Hmm…  Looks like a normal diff to me…

Patching file file1 using Plan A…

Hunk #1 succeeded at 4.

done

В результате исходная версия file1 будет сохранена под именем file1.orig, а сам он преобразован в соответствие с описанием diff-файла. Возможна и
форма

patch < diff_file

В этом случае команда patch попытается сама определить имя файла-оригинала, и, если это ей не удастся, даст запрос на его ввод. Обращаю внимание на символ перенаправления ввода, поскольку если его опустить, имя dif-файла будет воспринято как первый аргумент команды (то есть имя файла-оригинала).

В качестве второго аргумента команды patch могут использоваться dif-файлы не только в стандартном, но и в контекстном или унифицированном формате. Это следует указать посредством опции -c или -u, соответственно.

Сочетание команд diff и patch очень широко используется при внесении изменений в исходные тексты программы. В частности, они применяются для внесения дистрибутив-специфичных изменений в deb-пакеты репозиториев Ununtu и Mint.

Не менее часто, чем в слиянии, возникает и необходимость в разделении файлов на части. Цели этой служит команда split. Формат ее:

$ split [options] filename [prefix]

В результате исходный файл будет разбит на несколько отдельных файлов вида prefixaa, prefixab и так далее. Значение аргумента prefix по умолчанию — x (то есть без его указания итоговые файлы получат имена xaa, xab и т.д.).

Опции команды split задают размер выходных файлов — в байтах (опция -b) или количестве строк (опция -l). Первой опцией в качестве единицы, кроме байтов, могут быть заданы также килобайты или мегабайты — добавлением после численного значения обозначения k или m, соответственно.

Команда split может использоваться для разбиения файлового архива на фрагменты, соответствующие размеру резервных носителей. Так, в форме

$ split -b 1474560 arch_name

она обеспечит разбиение архива на части, какждая из которых может быть записана на стандартную трехдюймовую дискету. А посредством

$ split -b 650m arch_name

архив можно подготовить к записи на носители CD-R/RW. Легко догадаться, что обратное слияние таких фрагментированных файлов можно выполнить командой cat.

В BSD-реализации команды split имеется опция -p (от pattern — шаблон), благодаря которой файл может быть разделена на фрагменты, ограниченные строками, содержащими текст, приведенный в качестве значения шаблона. Linux-реализация команды split таким свойством не обладает. Однако взамен этому в Linux есть команда csplit, именно для разделения файла по шаблону и предназначенная.

Показать, как она работает, проще всего на конкретном примере. Предположим, у нас имеется книга в формате Plain Text, состоящая из введения и 23 глав, которую надо разбить на соответствующее количество фрагментов. Для этого сочиняется такая командная конструкция:

$ csplit -f chapter mybook.txt ‘/Глава/’ {23}

Здесь опция -f задаёт маску имён файлов, на которые будет разбит исходный текст (то есть файл mybook.txt). Шаблон, по которому будет выполняться разбиение — слово Глава ограничено прямыми слэшами и заключено в «строгие» кавычки. А число в фигурных скобках указывает, сколько раз надо повторить процедуру разбиения по заданному шаблону. И в результате мы получаем серию файлов вида chapter##, где файл chapter00 будет включать текст от начала до первой строки со словом Глава (которая, как ни странно, будет главой первой), chapter01 — от строки Глава первая до Главы второй, и так далее. Исходный файл при этом останется в неприкосновенности.

Поиск в файлах: grep сотоварищи

В одном из предыдущих разделов говорилось о поиске файлов посредством команды find. Ныне же речь пойдет о поиске внутри файлового контента — то есть поиске текстовых фрагментов. Для этого в POSIX-системах используется семейство утилит grep — собственно grep, egrep и fgrep, несколько различющихся функционально. Впрочем, в большинстве систем все это суть разные имена (жёсткие ссылки) одной и той же программы, именуемой GNU-реализацией grep, включающей ряд функций, свойственных ее расширенному аналогу, egrep. Соответственно, поиск текстовых фрагментов в файлах может быть вызван любой из этих команд, хотя в каждом случае функциональность их будет несколько различаться.

Однако начнем по порядку. Самой простой формой команды grep является следующая:

$ grep pattern files

где pattern — искомая последовательность символов, а files — файлы, среди которых должен производиться поиск (или — просто одиночный файл). В указании
имен файлов допустимы обычные маски, например, командой

$ grep line ./*

будут найдены строки вида line во всех файлах текущего каталога. Шаблон для поиска не обязан быть односложным. Правда, если в нем используются последовательности символов, разделенные пробелами, последние должны тем или иным способом экранироваться, иначе в качестве шаблона будет воспринято только первое слово. Например, каждый пробел может предваряться символом обратного слэша (\), или просто все искомое выражение заключается в одинарные или двойные кавычки.

Шаблоны могут включать в себя регулярные выражения. причём список таковых для команды grep существенно шире, чем для команд манипулирования файлами. Так, кроме маски любой последовательности символов (*), любого одиночного символа (?), списка и диапазона символов ([a…z] и [a-z]), могут встречаться:

  • . (точка) — маска любого одиночного (но, в отличие от маски ?, обязательно присутствующего) символа; то есть при задании шаблона lin. будут найдены строки, содержашие line или lins, но не lin;

  • ^ и $ — маски начала и конца строки, соответственно: по шаблону ^line, будут найдены строки, начинающиеся с соответствующего слова, по шаблону же line$ — им заканчивающиеся;

  • маски повторения предыдущего шаблона, \{n\} — ровно n раз, \{n,\} — не менее n раз, \{,m\} — не более m раз, \{n,m\} — не менее n раз и не более m раз.

Маски повторения относятся к так называемым расширенным регулярным выражениям. Для их использования команда grep должна быть дана с опцией -e или в форме egrep — последняя часто определяется в общесистемном или пользовательском профильном файле как псевдоним команды grep:

alias grep=’egrep -s’

или

alias grep egrep

в оболочках семейств shell и csh, соответственно.

При этом становятся доступными и другие возможности поиска — например, нескольких текстовых фрагментов (соедниненных логическим оператором «ИЛИ») одновременно. Делается это двояко. Первый способ — просто перечисление искомых фрагментов, каждый из которых предваряется опцией -e (и при необходимости экранируется кавычками):

$ grep -e pattern1 -e pattern2 files

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

$ egrep ‘pattern1|pattern2’ files

Таким способом очень легко, например, составить оглавление для длинного текста (при наличии некоторой системы рубрикации в нем, разумеется). Для этого достаточно дать команду вроде следующей:

$ egrep ‘Часть|Глава|Раздел|Параграф’ filename

Для текста, включающего html- или TeX-разметку, роль рубрик могут выполнять соответствующие ее элементы, например:

$ egrep ‘ <h1>|<h2>|<h3>|<h4>’ filename

Вывод команды grep может быть перенаправлен в файл, а при необходимости и предварительно отсортирован с помощью соответствующих командных конструкций перенаправления и конвейеризации.

Разумеется, тем же способом можно создать общее оглавление для серии фрагментов, записанных в виде самостоятельных файлов — для этого достаточно только перечислить их имена в качестве аргументов команды. Так, например, если есть необходимость составления детальной карты сайта, включающей ссылки на подрубрики внутри отдельных html-документов, следует применить конструкцию типа:

$ egrep ‘<h1>|<h2>|<h3>|<h4>’ path/*.html > sitemap.html

ещё одно замечательное свойство команды grepegrep) — возможность получения шаблона не со стандартного ввода (то есть не путем набора его с клавиатуры), а из файла. Так, если для приведенного выше случая создать простой текстовый файл shablon, содержащий строку

Часть|Глава|Раздел|Параграф

выполнять операцию по сборке оглавления впредь (и в любом тексте, хоть частично совпадающем по структуре с рассмотренным) можно будет выполнять таким образом:

$ egrep -f shablon filename

Опция -f и указывает команде, что список параметров должен извлекаться из файла, указанного в качестве значения опции.

Список опций команды grep не исчерпывается указанными выше. Так, опция -i предписывает игнорировать различие регистров внутри искомого выражения, опция -h — подавляет вывод имен файлов (выводится только содержание найденных строк), тогда как опция -l, напротив, выводит только имена файлов, содержащих найденный шаблон, но не текстовый фрагмент, опция -n выводит номера найденных строк в соответствующих файлах. Весьма важной представляется опция -v, обеспечивающая инверсию поиска: при указании ее выводятся строки, не содержащие шаблона поиска.

Команда grep имеет и аналоги для поиска в сжатых файлах — команду zgrep и семейство команд xzgrep, о которых говорилось в миниочерке про архивацию и компрессию.

Поиск в файлах: утилита search

В дистрибутиве Mint имеется фирменная утилита для поиска текстовых фрагментов в файлах — search/code>. Она входит в состав пакета mintsystem (о котором подробней говорится в очерке об утилите apt) и располагается в каталоге /usr/local/bin/. Формат её вызова таков:

$ search for [искомый фрагмент] in [каталог для поиска]

Например, в форме

$ search for ‘дистрибутив Mint’ in /home/current/alv.me

она отыщет все абзацы с вхождением дистрибутив Mint во всех файлах указанного каталога и выведёт их в таком виде:

/home/current/alv.me/mint/mint17-cin/mint17-02.txt:9:В числе родственников… нет, не примазавшихся, а настоящих, но пошедших другим путём, был и дистрибутив Mint. Сейчас не время обсуждать его взаимоотношения с прародительской Ububtu, но программу установки он унаследовал от неё практически без изменений. По крайней мере, до недавнего времени макроскопических различий в инсталляторах этих систем не наблюдалось.

Команда search не является полной заменой утилит семейства grep, в частности, она не поддерживает регулярные выражения. Но вполне может служить более простой в использовании альтернативой во многих тривиальных случаях, столь частых в практике применителей-текстовиков.

Sed: средство потокового редактирования

Весьма часто при обработке текстов встает такая задача: заменить одно слово (или последовательность слов) на другое сразу во многих файлах. Как она решается «подоконными» средствами? Обычно — открытием всех подлежащих изменению документов в word-процессоре и применением функции поиска/замены последовательно в каждом из них.

Таким же способом можно воспользоваться и в POSIX-мире. Это просто, но уж больно скучно. Тем паче, что здесь есть очень эффективная альтернатива — средства потокового (неинтерактивного ) редактирования, примером которых является sed, с которым мы уже слегка познакомились в очерке о программах в автозапуске.

Потоковое, или неинтерактивное, редактирование не требует загруки документа в память (то есть открытия), как в обычных текстовых редакторах и word-процессорах. Нет, при нем подлежащий изменению файл (или группа файлов) обрабатываются построчно с помощью соответствующих команд, задаваемых как опции единой командной директивы. В наши дни это выглядит анахронизмом, однако в ряде случаев оказывается чрезвычайно эффективным. Каких? — ответ легко дать на нескольких конкретных примерах.

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

$ sudo sed -i ‘s/NoDisplay=true/NoDisplay=false/’ /etc/xdg/autostart/*

Другой случай — во многих десятках, а то и сотнях файлов требуется изменить одну-единственную строку, причём — одинаковым образом (например, заменить копирайт Васи Пупкина на Петю Лавочкина). Неужто для этой цели нужно вызывать мощный текстовый редактор, грузить в него немерянное количество документов, перемещаться тем или иным способом перемещаться к нужному фрагменту, вносить требуемое изменение? Отнюдь, ибо sed поможет и здесь, позволив выполнить изменение любого количества файлов в пакетном режиме.

Во всем блесе sed показывает себя при редактировании очень больших файлов (одно пролистывание которых требует немалого времени). А также — при редактировании сложных символьных последовательностей в нескольких файлах. Однажды, после очередной реконструкции моего сайта, передо мной встала задача тотальной модификации всех внутренних ссылок. Долго я с ужасом размышлял, как буду делать это в текстовом редакторе, и сколько ошибок при этом насажаю. Пока, раскинув мозгами, не нашел, как сделать это с помощью sed — быстро и, главное, безошибочно.

В самом общем виде sed требует двух аргументов — указания встроенной его команды и имени файла, к которому она должны быть применена. Впрочем, в качестве аргумента можно задать только простую команду, мало-мальски сложное действие (а команды поиска/замены принадлежат к числу сложных) необходимо определить через значения опции -e, заключенные в кавычки (одинарные или двойные — по ситуации). Что же касается имен файлов — то их в качестве аргументов можно указать сколько угодно, в том числе и с помощью масок типа *, *.txt и так далее. Правда, sed не обрабатывает содержимое вложенных подкаталогов, но это — дело поправимое (как — скоро увидим). Так что поиск и замена слова или их последовательности выполняются такой конструкцией:

$ sed -e ‘s/Вася Пупкин/Петя Лавочкин/’ *

Здесь s — это команда поиска, Вася Пупкин — искомый текст, а Петя Лавочкин — текст для замены. В приведенной форме команда выполнит поиск и замену только первого вхождения искомого текста. Чтобы заменить текст по всему файлу, после последнего слэша (он обязателен в любом случае, без него sed не распознает конца заменяющего фрагмента) нужно указать флаг g (от global). Важно помнить, что если оставить заменяющее поле пустым, искомый текст будет просто удален.

По умолчанию sed выводит результаты своей работы на стандартный вывод, не внося изменений в файлы аргументы. Так где же здесь редактирование? Оно обеспечивается другой опцией — -i, указание которой внесет изменения непосредственно в обрабатываемый файл. В результате команда для замены, например, всех вхождений html на shtml во всех файлах текущего каталога будет выглядеть так:

$ sed -i -e ‘s/html/shtml’ *

А что делать, если таким же образом нужно обработать файлы во всех вложенных подкаталогах? Придется вспомнить об универсальной команде find, о которой мы не так давно говорили. В форме

$ find . -name * -exec sed -i -e ‘s/html/shtml’ * {} \

она с успехом справится с этой задачей.

Я привел лишь элементарные примеры использования sed. На самом деле возможности его много шире, но их описание далеко выходит за рамки этого краткого введения.

Текстовый редактор nano

Только что я попытался показать мощь неинтерактивного редактирования, доступную благодаря потоковому редактору sed. Однако, как бы силён он не был, иногда при всякого рода конфигурировании возникает необходимость и в настоящем текстовом редакторе, интерактивном. Причём желательно способном работать и в терминальном окне графического сеанса, и в «чёрной» консоли.

Записные линуксоиды обычно в таких случаях советуют начинающим применителям Vim или Emacs, в зависимости от собственной религиозной ориентации. Напрочь забывая о том, что эффективная работа в обоих этих редакторах возможна только при доведённых до автоматизма навыках, и к тому же навыках, постоянно тренируемых — иначе они утрачиваются очень быстро. При необходимости же поправить пару строк в конфиге раз или два в месяц приобретать такие навыки просто не имеет смысла.

А вот редактор Nano вполне может сыграть роль своего рода амортизатора для начинающего применителя. Да, это не Vim, не Emacs, и даже не joe. Но с задачей конфигурирования справляется успешно. А в освоении и`обращении — прост, как грабли. Не случайно во многих дистрибутивах Linux он по умолчанию предлагается в качестве общесистемного. В том числе и в таких юзерофильных, как семейство Ubuntu, представители которого, с одной стороны, имеют штатные, мощные и удобные, инструменты редактирования в своих интегрированных средах, с другой — и Vim’ом эти системы не обделены, да и Emacs им устанавливать не возбраняется. Но даже в этих «борброжелательных» дистрибутивах иногда возникает потребность в простом и лёгком консольном редакторе. А многие ли из начинающих применителей способны сразу же смотреть на Vim и Emacs без содрогания?

Столь длинное вступление направлено к тому, что затратить толику времени на освоение Nano — дело стоящее для многих линуксоидов, в том числе и начинающих применителей Mint. Тем более, что, как уже было сказано, в освоении он прост, а возможностей у него больше, чем может показаться на первый взгляд.

Итак, представляю: редактор Nano, или, точнее, GNU nano. Характеризуется авторами как маленький и дружелюбный. Что в целом соответствует истине. Официальным местопребыванием имеет сайт http://www.nano-editor.org, где его текущая стабильная версия (2.2.6) доступна в виде тарбалла исходников и бинарников в форматах rpm и deb.

Впрочем, применителям Mint заботиться о скачивании бинарников и тем более исходников не придётся: Nano имеется в официальном репозитории этого дистрибутива и, более того, устанавливается по умолчанию с инсталляционного Live-носителя, после чего немедленно готов к работе.

Запускается Nano из командной строки консоли или терминального окна одноименной командой, можно — с указанием имени файла, существующего или нового (в последнем случае, как обычно, файл с таким именем будет создан). Поддерживается несколько опций командной строки, как то: -T #, устанавливающей величину (в символах) табуляции, -i, включающей автоматические отступы, -w, отключающей режим жёсткого переноса строк на границе экрана (что очень важно при редактировании конфигурационных файлов), -$, напротив, включающей режим переноса «мягкого» (так называемый softwrap), при котором визуальный перенос осуществляется без разрыва строки, и так далее. Полный список стартовых опций можно посмотреть посредством

$ man 1 nano

Кроме того, практически все эти опции могут быть прописаны в конфигурационном файле в качестве умолчальных.

Общесистемный конфигурационный файл редактора — /etc/nanorc. Его можно скопировать в свой домашний каталог

$ cp /etc/nanorc ~/.nanorc

После чего редактировать в своё удовольствие. Кроме того, в каталоге /usr/share/nano имеется большое количество примеров конфигов, адаптированных для разных языков программирования и разметки, а также специально для некоторых дистрибутивов (Gentoo, Debian).

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

set softwrap

И, напротив, закрыть комментарием строку

#set nowrap

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

Поиск, кстати, осуществляется комбинацией клавиш Control+w с последующим нажатием на Enter, повторямыми, сколько требуется. А для замены, в том числе глобальной, используется комбинация Control плюс обратный слэш (\) или Meta+R.

После запуска Nano с указанием существующего файла в качестве аргумента (например, его собственного «домашнего» конфига) перед глазами возникает примерно такая картина:


Изображение234

Вверху — титульная строка, в которой выводятся номер версии программы, имя открытого файла и, в правом углу, сообщение о том, что файл был изменен. В нижней части экрана можно видеть зону подсказки — список основных управляющих клавишных последовательностей (образованных сочетанием Control+литера) с пояснениями на языке установленной локали.

Главнейшей из управляющих последовательностей на первых порах знакомства с редактором будет Control+g (литерные клавиши последовательностей к регистру не чувствительны). Она вызывается весьма подробную справку, в том числе и о тех последовательностях, которые не уместились в двух нижних строках рабочей области. Та же самая справка вызывается и клавишей F1 — если она не перехватывается средой, как это имеет место быть в GNOME Terminal’е, который Cinnamon юзает вместо отсутствующего родного.

Вообще поначалу удобно разместить рядом два терминальных окна, и в одном открывать текст для набора или редактирования, а в другом — вызвать справку и постоянно с ней сверяться:


Изображение235

Потому что, повторяю, управляющих последовательностей в Nano довольно много — больше, чем можно запомнить с одного просмотра, и все они полезны в практической работе.

А ещё они бывают двух видов — в сочетании с клавишей Control и с клавишей Meta. Последней на современных клавиатурах не найти — она эмулируется либо нажатием клавиши Alt, либо нажатием и отпусканием клавиши Escape, хотя поледний способ и не всегда срабатывает..

Собственно управляющие последовательности, Control+литера, предназначены в основном для редактирования текста и операций с файлами. Управляющие последовательности частично дублируются функциональными клавишами F1F16. Отсутствующие на клавиатуре функциональные клавиши с F13 по F16 вызываются посредством сочетания Shift+F1F4.

Meta-последовательности (то есть сочетания Meta+литера) теоретически предназначены в основном для временого изменения настроек редактора (тот же результат достигается и опциями командной строки). Однако порою клавиша Meta выступает в роли «усилителя» Control-последовательности.

К слову сказать, в «голой» консоли и Control-, и Meta-последовательности работают при любой раскладке клавиатуры, что латинской, что русской. А вот в терминальных окнах Cinnamon Meta-последовательности при русской раскладке клавиатуры выполнять свои функции отказываются.

Описывать все управляющие и Meta-последовательности не буду — это сделано в той самой экранной подсказке, да в тому же в локализованной системе — на русском языке. Замечу только, что ничего страшного в них нет. Кейбиндинги для навигации по тексту и его редактирования — так называемые Emacs-подобные, примерно такие же, как в шеллах типа Bash или Zsh. И применителю любой из Sh-подобных командных оболочек могут показаться непривычными только те последовательности, которые отражают специфические функции Nano как редактора. Вот эти-то функции рассмотреть стоит.

Как нетрудно догадаться, текстовый редактор может вводить и редактировать тексты, и Nano тут не исключение. Причём он умеет делать это в нескольких документах параллельно — каждый из них открывается в собственном так называемом буфере. Для чего сначала нужно включить мультибуферный режим — делается это meta-последовательностью Meta+F. Затем каждый новый буфер открывается с помощью комбинации Control+R, либо введя имя файла непосредственно в появившейся строке, либо, нажав Control+T, перейти в режим визуального выбора файла:


Изображение236

Число открытых буферов вроде бы ничем не ограничено — разве что объёмом памяти. Переключение между ними — с помощью Meta+> (вперёд) и Meta+< (назад).

Если при задйствовании нескольких буферов отключить мультибуферный режим (это делается повторением комбинации Meta+F), то открытые буфера никуда не деваются, и переключаться между ними можно по прежнему, но вот открыть новый буфер уже не получится до повторного включения мультибуферного режима. А в днобуферном режиме комбинация Control+R после выбора файла вместо открытия втсавит его содержимое в позиции курсора текущего документа.

Между буферами возможен обмен данными. Так, строка, скопированная (посредством Meta+6) или вырезанная (комбинацией Control+K) в одном буфере, может быть вставлена (с помощью Control+U) в другом. Ну и в «родном», разумеется, тоже.

Надо заметить, что в Nano есть и другой способ одновременного редактирования нескольких файлов. Комбинация клавиш Meta+Z приостанавливает работу редактора (точнее, переводит его в фоновый режим), возвращая приглашение командной строки, в которой Nano можно запустить заново. Но это будет уже другой его экземпляр, и обмен между ними через буфер невозможен — это можно сделать только «мышиным» выделением и вставкой кликом средней её кнопкой. Однако в этой временной командной строке можно выполнить какие-либо команды, а результаты через то же «мышиное» выделение поместить в редактируемый документ. Возврат в который из командной строки — по команде fg.

Очень полезная особенность Nano — возможность включения режима мягкого переноса слов (точнее, символов — softwrap), о которой я уже говорил. Здесь же добавлю, что это можно сделать не только через конфиг или опцию запуска Nano, но и прямо в его сеансе — последовательностью Meta+$. Я уделяю этому вопросу столько внимания, потому что такая, казалось бы, мелочь очень важна для сочинителя нарративных текстов — и не только при доводке их в word-процессоре или программе вёрстки, где лишние разрывы строк — вечный повод для головной боли. Не меньше они мешаются при поиске в архивах собственной нетленки по смутно запомнившимся её фрагментам.

Думаю, важность подстветки синтаксиса понимают не только программисты и профессиональные web-разработчики. Ибо мода сочинять конфиги в XML-формате затронула многие рабочие среды. А разобраться в XML-файле без подсветки — проще удавиться. Да и сочинителям нарративных текстов, не брезгующим одновременно их разметкой (в HTML ли, или в TeX) это тоже лишним не покажется. И Nano поддерживает оную с давних пор, а с некоторого времени эта фича включена в нём по умолчанию. Список поддерживаемых языков программирования и разметки, а также дистрибутив-специфичных файлов можно посмотреть так:

$ ls /usr/share/nano

И выглядит он следующим образом:

asm.nanorc      groff.nanorc     nanorc.nanorc  ruby.nanorc

awk.nanorc      html.nanorc      objc.nanorc    sh.nanorc

cmake.nanorc    java.nanorc      ocaml.nanorc   tcl.nanorc

c.nanorc        makefile.nanorc  patch.nanorc   tex.nanorc

css.nanorc      man.nanorc       perl.nanorc    xml.nanorc

debian.nanorc   mgp.nanorc       php.nanorc

fortran.nanorc  mutt.nanorc      pov.nanorc

gentoo.nanorc   nano-menu.xpm    python.nanorc

Правда, возможно, цветовая гамма в них не всем покажется идеальной. Но, как известно, на цвет товарищей нет, и никто не мешает отредактировать её вкусу своих фломастеров.

Далее — проверка орфографии, которая одинаково важна для всех применителей, даже тех, кто, подобно автору этих строк, ею подчас манкирует. Для обеспечения оной в файле ~/nanorc нужно снять комментарий со строки

set speller «aspell -x -c»

После чего по комбинации Control+T (или по клавише F12, если та не задействована для других целей, например, вызова выпадающего терминала) для спеллинга будет вызываться программа aspell — если она, конечно, установлена и снабжена словарем для требующегося языка. В Mint пакет aspell устанавливается по умолчанию, но сопровождается только английским словарём. Так что для обеспечения проверки орфографии в русскоязычных текстах надо установить пакет aspell-ru.

И, наконец, остается только сделать Nano редактором по умолчанию — чтобы использовать его по умолчанию в командах типа sudoedit и visudo (а также везде, где потребуется впредь). Для чего воспользуемся им самим же, открыв в нем конфигурационный файл своей пользовательской командной оболочки. Например, для Bash — так:

$ nano ~/.bashrc

И вписав в него такую вот строку:

export EDITOR=nano

определяющую переменную среды EDITOR. Теперь редактор nano будет вызываться при редактировании системных конфигов, например, командой sudoedit.

Функциональные возможности Nano на фоне Vim или Emacs не производят впечатления исключительно богатых. Однако это — не только минус, но и плюс: ограниченный набор функций легче освоить и особенно — держать в голове при эпизодическом применении. Тем более, что их хватает не только на несложную правку мелких конфигов, но и на сочинение не слишком масштабных нарративных текстов.

Mint и Zsh

В предыдущем очерке работа в 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 с помощью описанного ранее менеджера пакетов. Для чего сначала надо отыскать соответствующий пакет:


Изображение237

После чего поглядеть на его описание и установить:


Изображение238

Однако просто иметь Zsh мало — его надо сделать регистрационной оболочкой (login shell) в своём аккаунте. Как ни странно, в обоих графических модулях Системных настроек Cinnamon такой возможности нет. Однако можно прибегнуть к графической утилите usermode, предварительно установив её через Менеджер приложений и запустив из главного меню, где она скрывается в секции Параметры под именем О себе и после запуска выглядит таким образом:


Изображение239

После установки Zsh её можно будет выбрать из выпадающего списка в поле Оболочка:


Изображение240

Кажется, это единственное, что может сделать полезного данная утилита. Поэтому возникает вопрос — а стоит ли устанавливать её ради разовой операции? Может быть, лучше прибегнуть к самому простому способу смены login shell — прямой команде? Тот этой:

$ chsh -s /bin/zsh

Вопрос, как вы понимаете, риторический…

Каким бы образом ни была назначена Zsh любимой женой пользовательской командной оболочкой, следующая авторизация данного пользователя в «голой» консоли однозначно её запустит. В эмуляторах же терминала, возможно, потребуется внести некоторые изменения в их настройках, например, предписать запуск /bin/zsh явным образом, или отметить опцию запуска оболочки как login shell.

В любом случае первый запуск сеанса пользователя с новой оболочкой предложит такие варианты выбора:

  • q — выход из программы автоконфигурирования без последствий; при следующем входе в оболочку вызов её будет повторён;

  • 0 — выход из автоконфигурирования с созданием пустого конфига ~/.zshrc, предотвращающем в дальнейшем повторения автоконфигурирования;

  • 1 — вызов главного меню;

  • 2 — создание конфига ~/.zshrc по образу и подобию эталонного, /etc/zsh/newuser.zshrc.recommended, который в дальнейшем может редактироваться вручную.


Изображение241

С вариантом q всё ясно, это просто откладывание вопроса на потом, вариант 1, с автоконфигурированием, был некогда описан достаточно подробно, и с тех пор процесс этот ничуть не изменился, вариант же 2 зависит от настроек общего конфига оболочки, принятых майнтайнерами данного дистрибутива. Так что я хотел бы сконцентрировать внимание на «нулевом» варианте. И последовательно рассмотреть все настройки, которые потребуется выполнить применителю для создания комфортной среды CLI. Не абстрактно, разумеется, а применительно к целям и задачам себя, любимого. Так что читатель должен воспринимать всё сказанное в этих очерках далее, не как догму, а как руководство к действиям, то есть экспериментам, и к размышлениям о своих потребностях.

Однако прежде отмечу, что применителю не обязательно сразу определять Zsh как login shell. Он может вызвать её из командной строки Bash:

$ /bin/zsh

Запуск Zsh ознаменуется сменой вида приглашения командной строки с Bash’евской, которая в Mint’е по умолчанию выглядит так:

zshuser@alv-cinn ~ $

на умолчальную Zsh’еву:

alv-cinn%

Вот с настройки вида приглашения командной строки я и начну. Добавив только, что после каждого изменения в конфиге ~/.zshrc для вступления его в силу вовсе не обязательно завершать сеанс и авторизоваться заново — достаточно такой команды:

alv-cinn% source .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, соответственно. Вторичное приглашение у меня имеет вид

PROMPT2=’%i%U> ‘

В результате в нём выводится номер «вторичной» строки в данном сеансе шелла, указывается стрелкой на то, что ввод следует в ней продолжить, а сам ввод даётся подчёркнутым шрифтоначертанием. Вживе это выглядит так:

[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 -p

которая выведет их все (в моей системе — около двух десятков, плюс цветовые вариации) примерно в таком виде:


Изображение242

Среди «невест» можно видеть весьма пёстро наряженных:


Изображение243

Но и одетых весьма скромно также есть:


Изображение244

Выбрав подходящую невесту тему, её можно тут же установить командой

$ prompt имя_темы

при желании — с указанием цветовых параметров, например:

$ prompt fade white grey blue

Что в «живом» терминальном окне (терминал Sakura) будет выглядеть так:


Изображение245

А в выпадающем терминале Guake — несколько иначе:


Изображение246

Кстати, а в «голой» консоли вид этой же темы будет существенно скромнее — разбираться с программами для изготовления скриншотов консоли мне было лень, так что прошу поверить на слово.

Установленная таким образом тема будет функционировать только в данном терминальном окне в течении текущего сеанса. Чтобы увековечить её, необходимо вписать в файл ~/.zshrc такие строки:

autoload -Uz promptinit

promptinit

prompt clint

В примере приведена тема, пожалуй, наиболее информативного приглашения, которое «вживе» вылядит так:


Изображение247

Большое количество тем можно при желании отыскать на сайте Oh My ZSH!, но эти я уже заниматься не стал.

Приёмы навигации

Сознательные граждане, активно применяющие CLI, используют множество команд, как встроенных в их любимый шелл, так и внешних. Но, думаю, что самыми употребимыми в повседневной жизни являются такие:

  • pwd для определения своего текущего положения на файловом древе — да-да, иногда, после многократных переходов между подкаталогами, забываешь, не только кто я, но и где я (уж не в Тимирязском ли?);

  • ls — для просмотра содержимого текущего каталога;

  • cd — для перехода в определённый каталог.

Однако здесь Zsh вносит свои коррективы, здорово облегчающие жизнь его применителя. Только что было показано, как фактическим можно избавиться от команды pwd, выведя путь к текущему каталогу в качестве RPROMPT. Без команды ls, конечно, не обойтись и Zsh. А вот команда cd в Zsh просто… не нужна.

Да, дорогие мои болельщики, в среде Zsh без этой команды не просто можно обойтись, а жить куда комфортней, нежели с ней. Ведь давайте вспомним, что такое переход в каталог имя_рек? Для типа файлов, именуемого каталогом (directory) это то же самое, что исполнение для обычного (ordinary) файла, будь он откомпилированным бинарником или интерпретируемым сценарием.

И потому более чем логично то, что как для запуска скрипта оболочки не требуется никакой внешней команды (хотя и не возбраняется что-нибудь типа . или /bin/sh), так и для перехода в каталог, к которому данный юзер имеет доступ (то есть попадает в число тех, для кого у этого каталога установлен бит исполнения), ему достаточно указать полный путь к нему, без всяких команд. Например, введя к командной строке что-нибудь вроде

$ /usr/share/fonts/truetype/

можно сразу оказаться в каталоге с TTF-шрифтами.

«Бескомандный» переход в каталоги распространяется и на «символические» обозначения последних. Так, команда

$ ~

переместит пользователя в его домашний каталог. Как, кстати, и команда

$ $HOME

Хотя практического смысла последний вариант не имеет. Зато директива

$ ..

волшебным образом ознаменует переход в каталог, родительский относительно текущего.

Правда, всё это происходит не само собой: для практического воплощения этого волшебства в общесистемном конфиге /etc/zsh/zshrc или пользовательском ~/.zshrc должна присутствовать строка

setopt autocd

В пару к ней можно добавить ещё и такую строку:

cdpath=(~/ /home/current/ /home/data/)

где в скобках перечислены каталоги, к подкаталогам которых чаще всего требуется быстрый доступ. И теперь, где бы в пределах файлового древа ни находился пользователь, ввод им директивы

$ Documents

нечувствительно сделает текущим каталогом /home/username/Documents.

То есть опция autocd и массив переменных cdpath отнюдь не исключают, а прекрасно дополняют друг друга.

Автодополнение

Волшебное свойство клавиши Tab, вызывающей автодополнение — одно из первых, с чем знакомится применитель CLI. Хотя при этом часто забывается, что когда-то, в перворождённом шелле Борна, никакого автодополнения не было. Оно появилось в Csh — и сначала только для путей, но не для команд. Тем не менее, ныне представить себе интерактиную работу в командной строке без автодополнения невозможно (да и не нужно).

Однако в Zsh клавиша Tab волшебна дважды: она не только дополняет пути и команды после их частичного ввода, но и способна развернуть аббревиатуры для тех и других. Например, нажатие клавиши табулции после набора последовательности

$ /u/s/f/tr

развернёт её в полный путь к каталогу со шрифтами TrueType

$ /usr/share/fonts/truetype

а после нажатия клавиши Enter сделает этот каталог текущим, как мы только что видели.

Правда, само по себе развёртывание аббревиатур работать не будет — его надо активизировать такими строками в файле ~/.zshrc:

 autoload -Uz compinit

compinit

Можно пойти дальше, и не просто разворачивать безальтернативные аббревиатуры, типа приведённый выше, но и выбирать стрелками, как в меню, подкаталги или файлы среди предлагаемый альтернатив. Например, если набрать ту же самую
последовательность символов:

$ /u/s/f/tr

а затем дважды нажать клавишу табуляции, то она не только развернётся в полный путь

$ /usr/share/fonts/truetype/

но и выведет список подкаталогов указанного каталога:

dejavu/ freefont/ openoffice/ ubuntu-font-family/ droid/ liberation/

ttf-dejavu/ wqy/

И выбор нужного среди них можно выполнять либо стрелками управления курсором, либо обычными кейбиндингами типа Control+f, Control+b и им подобными:


Изображение248

Правда, и такая реакция 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 сделать это очень просто — достаточно дать команду

$ ls path3/**/*.png

где path3, как нетрудно догадаться, «корневой» каталог поиска, *.png — маска искомых файлов, а «двузвёздие» — так сказать, директива рекурсивного поиска.

Правда, вопреки утверждениям некоторых уж очень правоверных Zsh’истов, эта возможность не делает команду find избыточной, ибо, как все знают, она умеет и многое другое. Но зато такая простая директива позволяет не беспокоить Её Величество по пустякам…

А заодно — конструкции вида **/* можно использовать как аргументы команд управления файлами, таких, как cp, mv, rm. В частности, с помощью команды вида

$ rm -f path3/**/*~

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

Разумеется, можно фильтровать базар. Давеча в приступе чёрной меланхолии переслушивал я всё, что сочинил и спел Фред Солянов — увы, большинство моих потенциальных читателей о его существовании не подозревают: в отличе от многих всенародно известных так называемых «бардов», он не был популярен при жизни. А когда его верхние люди позвали — люди нижние про него забыли напрочь. И зря — но это из совсем другой оперы. А в нынешней арии мне было интересно, сколько же Фред сочинил песен за ту четверть чека, что ему отпустила на то судьба. И я дал очень простую команду:

$ ls path3/fred/**/*.mp3 | wc -l

И она мне сказала, что сочинил Фред 168 песен. Откидываем дубликаты, неизбежные в любой коллекции — но здесь их очень мало, на штуки счёт.

Откинем откровенно слабые песенки — ведь даже гений не каждое утро начинает с сочинения чего-то шедеврального. Откинем песенки вторичные — Фред никогда не претендовал на основоположничество, и, в отличе от некоторых более иных авторов, на которых я не хотел бы указывать пальцем, не считал для себя западло называть своего реального учителя в ентом деле, Булат Шавловича…

Для себя откину те песенки, которые лично меня не очень зацепили — их, по сравнению с прочими фильтрами, больше всего, почти полсотни.

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

Ну, дальше на эту тему распространяться не буду, а вернусь к генеральной линии сюжета. А именно — что маски типа **/*можно использовать в аргументах команды grep и для поиска фрагментов текстов. Так, команда

$ grep KDE **/*html

выведет все строки с упоминанием KDE в html-файлах каталога текущего и вложенных. А в форме

$ grep -i kde **/kde*.html

она произведёт аналогичный поиск только в файлах вида kde01.html, kde02.html и так далее. Причём без учёта регистра — но к мадемуазель Zsh, интересы которой я представляю в данный момент, это не имеет никакого отношения.

Перенаправление расширенное и множественное

Что такое перенаправление ввода/вывода — знают все применители CLI. Однако в Zsh возможности его очень широки, почему оно и называется здесь расширенным перенаправлением. Этот механизм позволяет в ряде случаев обходиться без некоторых команд вообще. Например, обычно для просмотра текстового файла применяют или команду cat, или команды-пейджеры типа more, less, most. Выбор между конкатенатором и одним из пейджеров определяется ситуацией, выбор внутри «тройки по борьбе с басмачами файлами» зависит от привычек или предпочтений. Однако Zsh может избавить применителя от мук буриданова осла, подменяя любую из этих команд оператором перенаправления в виде команды

$ < filename

Результатом чего будет постраничный вывод содержимого файла, подобный таковому любого пейджера.

С помощью того же оператора можно просмотреть одновременно содержимое двух файлов — то есть, конечно, не одновременно, а последовательно, но в едином потоке. То есть команда

$ < {zshenv,zshrc}

покажет оба файла как одно целое. Причём в данном случае можно поступить ещё проще, ибо маски имён файлов также не возбраняются:

$ < z*

Кстати, в терминах Zsh развёртывание масок имён файлов называется globbing — с ним мы уже сталкивались в рассказе о рекурсивном поиске.

Число «оперируемых» файлов ничем не ограничено, кроме здравого смысла и целесообразности. Так, есть резон проглядеть таким образом на скорую руку, как будут выглядеть 5-6 заметок по несколько строк каждая, если их объединить в одну статью. Но просматривать с помощью оператора перенаправления книжку, состоящую из пары десятков глав по много страниц каждая, уже явный перебор.

Однако бывают случаи, когда большое число «оперируемых» файлов очень даже уместно. Например, если требуется объединить ряд текстовых фрагментов в единый файл. И тогда, легким движением рук набрав в командной строке конструкцию

$ < chapter[01-10] > mybook

мы на выходе из разрозненных глав получаем готовую книгу.

Таким образом мы перешли уже к множественному перенаправлению. Применение которого просмотром файлов не исчерпывается — их содержимое может быть перенаправлено не только на стандартный вывод, но и на ввод какой-либо команды, подменяя командный конвейер. Например, конструкция вида

$ sort < file_{1,2}

совместно отсортирует строки обоих файлов, file_1 и file_2, точно так же, как это сделал бы конвейер команд

$ cat file_1 file_2 | sort

Кстати, перенаправление вполне может играть с конвейерами в одной команде. Например, конструкция вида

$ time commandname [options] [arguments] > filename | cat

занесёт время выполнения некоей команды в файл с одновременным выводом его на экран, заменяя команду tee. Это особенно полезно при всяких «тестированиях на быстродействие», когда надо и сохранить результат для дальнейшей обработки, и не терпится посмотреть на него сразу.

Множественное перенаправление удобно использовать для суммарного подсчёта числа символов в нескольких файлах таким образом:

$ wc -m <*txt

Что на выводе даст единственное число, например:

5382

Казалось бы, та же команда в «обычной» форме даже короче на один символ:

$ wc -m *txt

Однако вывод её будет развёрнут:

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, — знают все, кто применяет любую командную оболочку: их поддержка существует со времён перворождённого шелла Борна. Это один из простых способов минимизировать ввод командных директив, начиная с простейшего рекурсивного копирования файлов:

alias cp=’cp -R’

И заканчивая бессчётным количеством псевдонимов для команды ls.

Однако в Zsh есть ещё одна фича — глобальные псевдонимы, по сей день не имеющие аналогов, насколько я знаю, во всяких там ваших башах. И даже в почти соплеменных тсишах их нет.

Но начну по порядку. Опять же, кого не раздражала ситуация: в ответ на поиск файла find’ом или поиск фрагмента текста grep’ом выдаётся сто пятьсот экранов сообщений, что доступ к каталогу запрещён?

Разумеется, каждый применитель Bash’а знает, как с этим бороться — достаточно присобачить к конструкции поиска посредством той или другой утилиты маленький аппендикс в виде 2> /dev/null, отправляющий в небытие все сообщения об ошибках.

Сложнее применителям Tcsh — там подавления вывода нежелательных сообщений об ошибках возможно в виде такой конструкции:

% (command > out)>& err

где 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

И больше не заботиться о фильтрации зёрен от плевел.

Глобальные псевдонимы очень полезны в командных конструкциях перенаправления по конвейеру, например, для поэкранного вывода:

$ alias -g L=’|less’

Пример для «пролистывания» вывода команды dmesg:

$ dmesg L

Для фильтрации по вхождению «слова» можно задать такой глобальный псевдоним:

alias -g G=’|grep’

После чего использовать его в конструкциях, подобных такой:

$ dmesg G raid

что выведет нечто вроде

[    1.434246] md: raid0 personality registered for level 0

[    1.434376] md/raid0:md0: md_size is 390742016 sectors.

Мне весьма полезен глобальный псевдоним вида

alias -g W=’|wc -m’

Поскольку часто требуется прибегать к такой конструкции

$ cat filename W

которая в данном случае выведет число символов в текстовом файле — для меня оно важнее числа байт (а при использовании 16-битной кодировки для преимущественно кириллического текста эти значения не совпадают).

К именам глобальных псевдонимов применяются те же требования, что и к именам псевдонимов обычных: они должны быть по возможности короткими, мнемонически прозрачными. И, разумеется, определения всех постоянно используемых глобальных псевдонимов следует занести в свой кондуитик — то есть в ~/.zshrc.

Разумеется, здесь не описаны все возможные случаи употребления глобальных псевдонимов — они лимитируются только потребностями применителя и его фантазией. И, конечно, наказом, который дал атаман Платов небезызвестному Левше:

Не пей мало, не пей много, а пей средственно.

То есть — не придумывайте глобальных псевдонимов больше, чем сможете запомнить.

Псевдонимы-суффиксы

Кроме обычных и глобальных псевдонимов, в Zsh существует ещё одна их разновидность — псевдонимы «суффиксные», более удачного определения на языке родных осин я не придумал, псевдонимы.

Подобно тому, как добаление к команде alias опции -g с помощью магии превращает обычный псевдоним в глобальный, так и опция -s делает обычный псевдоним «суффиксным». То есть привязывает суффикс имени файла (те, кто, подобно автору этих строк, затронуты порчей чёрным DOS’ом, до сих пор часто называют его «расширением») к некоей программе, которая может сотворить над ним нужное действо. Например, если задать псевдоним такого вида

$ alias -s html=links

а затем набрать в CLI такое

$ path3/некто.html

то этот самый некто.html будет открыт в текстовом браузере Links.

Чем, разумеется, возможности «суффиксных» псевдонимов не исчерпываются — как всегда, предел им ставит только фантазия применителя применительно к его задачам. Ограничусь одним примером.

Какой же русский не любит Командера-полуночника? В том числе и потому, что он — один из сыновей прославленного командера Нортона, имя которого, в свою очередь, не более чем alias незабвенного лейтенанта Шмидта (история его чудесного спасения из лап царской охранки и последующей блестящей карьере сначала в ВМС Пендостана, а затем в интернациональном софтверном бузиненсе реконструирована нашими замечательными историками из славного Екатеринбурга). Впрочем, со временем наш русский применитель, не смотря на весь свой патриотизм, начинает понимать, что слепая любовь к MC связывает ему руки в операциях с возлюбленной CLI, и хорошо бы с командиром расстаться, как это делают цивилизованные люди — без скандалов и истерик.

Но тут возникает проблема: MC — один из самых удобных способов просмотра того, из чего состоят файлы пакетов (будь то deb, rpm или что ещё из tar.*z-серии). Так вот, механизм «суффиксных» псевдонимов Zsh предлагает нам адекватную замену: если дать команду, например,

$ alias -s deb=’dpkg -c’

а затем набрать в командной строке такое:

$ 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.

Данный конфиг может быть использован полностью или фрагментарно всеми заин