50 основных команд Linux для новичков
Терминал и текстовые команды — главный способ управления операционной системой Linux. Особенно, если речь идет о сервере – на него редко ставят графический интерфейс, и вся работа выполняется исключительно через командную строку. Поэтому любому администратору важно знать хотя бы с десяток ключевых команд для терминала Линукс, нужных для навигации в системе и базового управления файлами. В этом материале мы их как раз разберем.
Базовые команды для работы с терминалом
То, что поможет при работе с консолью в целом.
Команды для управления правами на файлы и директории
Все, что нужно для разрешения проблем, связанных с правами в Linux.
Команды для управления пользователями
Linux — многопользовательская система. Ей одновременно могут управлять несколько людей. Поэтому здесь достаточно сложная система добавления и редактирования учетных записей.
Установка, удаление и обновление пакетов
Для установки программ в Linux используются менеджеры пакетов. Они разнятся от дистрибутива к дистрибутиву, поэтому команды для управления ими тоже отличаются. Рассмотрим наиболее популярные.
Debian/Ubuntu
Red Hat Linux/CentOS
Команды для навигации и базовой работы с файлами
Самый крупный список в статье. Содержит в себе практически все мелкие утилиты и инструменты для взаимодействия с файлами и папками. Причем речь идет не только об их изменении, но и о получении информации о них.
Вот, что написано в тестовом документе
Что в терминал выводит cat
И что выводит grep
Команды для отображения базовой информации и управления системой
Утилиты, делящиеся разного рода справочной информацией с администратором компьютера.
На этом все. Это список команд, которыми я хотел бы поделиться с новичками. Я разобрал основное, что будет важно в самом начале работы. Ну а вы всегда можете воспользоваться документацией, открывающейся через man, и подробнее ознакомиться с любой из команд или утилит.
Основы командного интерфейса
Поскольку не исключена вероятность, что эту книгу будут читать и совсем начинающие применители Linux’а вообще, тех, для кого Mint оказался первым дистрибутивом этой операционной системы, в этом очерке будут даны некоторые общие сведения об интерфейсе командной строки ( CLI — Command Line Interface). Тем более, что это потребуется уже ближайшее время, в очерках, посвящённых управлению пакетами.
Введение в CLI
CLI в большинстве случаев обеспечивается классом программ, именуемых командными интерпретаторами, командными процессорами, командными оболочками или по простому шеллами ( shell ).
Командная строка
Командная строка — визуальное представление среды, в которой задаются основные элементы командного интерфейса: командные директивы с их аргументами и опциями.
Командная директива (или просто команда) — основная единица, посредством которой пользователь взаимодействует с шеллом. Она образуется по определенным правилам, именуемым синтаксисом. Синтаксис командной директивы определяется, в первую очередь, языком, принятым в данной командной оболочке. Кроме того, некоторые команды (не очень многочисленные, но весьма употребимые) имеют собственный, нестандартный синтаксис.
Однако в целом базовые правила построения команд имеют много общего. И именно эти базовые правила станут предметом данного раздела. Синтаксические особенности отдельных нестандартных команд будут оговариваться по ходу изложения.
Итак, командная директива образуется:
Очевидно, что имя команды является обязательным компонентом, тогда как опции и аргументы могут и отсутствовать (или подразумеваться в неявном виде по умолчанию).
В подавляющем большинстве случаев опции (или их последовательности) задаются непосредственно за именем команды, а аргумент (или группа аргументов) команду завершает, хотя это правило имеет некоторые исключения. Вне зависимости от порядка опций и аргументов, принятых для данной команды, интерпретация их осуществляется слева направо.
Команды, опции и аргументы обязательно разделяются между собой пробелами. Кроме того, опции обычно предваряются (без пробела) символом дефиса или двойного дефиса. Впрочем, немногочисленные (но весьма употребимые) команды могут использоваться с опциями без всяких предваряющих символов.
Как уже говорилось, имя команды определяет выполняемые ею функции. Существуют команды, встроенные в оболочку, то есть не имеющие запускающих их исполняемых файлов, и команды внешние. В последнем случае имя команды однозначно указывает на имя исполняемого файла программы, выполняемой при отдаче соответствующей директивы. Часто встроенные и внешние команды одного назначения имеют одинаковые имена. В этом случае обычно предпочтительно использование встроенных команд — впрочем, они и вызываются в первую очередь. Для вызова одноимённой внешней команды её нужно задать с указанием пути. Так, директива
будет задействована внешняя утилита с тем же именем. Кстати, это один из тех случаев, когда второй вариант может иногда оказаться предпочтительней: встроенная и внешняя команды имеют разные форматы вывода, причём в первой он зависит от используемой командной оболочки. И потому она не всегда подходит для прямого сравнения результатов — например, быстродействия в разных системах.
Или, в некоторых случаях, таким:
Для внешних команд любой из этих вариантов даст в выводе путь к исполняемому файлу:
Некоторые команды могут выступать под несколькими именами. Это связано с тем, что исторически в различных Unix-системах команды, исполнявшие одинаковые функции, могли получать разные названия. В каждой конкретной системе обычно используется только одна из таких команд-дублеров. Но при этом имена дублирующих команд также могут присутствовать в системе — для совместимости. Не следует думать, что это две различные программы одного назначения: как правило, такая синонимичность команд реализуется посредством механизма ссылок (links) или псевдонимов (alias), о которых речь пойдёт позднее.
Иногда команда, вызванная через имя своего синонима, может отличаться по своей функциональности от самой же себя, вызванной под родным именем. В этом случае говорят о эмуляции одной команды другой. Типичный пример — командная оболочка /bin/bash в большинстве дистрибутивов Linux имеет своего дублера — /bin/sh ; вызванная таким образом, она воспроизводит базовую функциональность стандарта POSIX-шелла.
Автодополнение
Для правильного применения команд, конечно же, нужно знать их имена и назначение. Однако нас никто не заставляет напрягать пальцы вводом имени команды полностью. Потому что тут на помощь приходит великий метод автодополнения.
Благодаря этому методу для любой команды достаточно ввести первые несколько ее символов — и нажать клавишу табуляции ( Tab ). И, если введённых буковок достаточно для однозначной идентификации, полное имя команды волшебным образом возникнет в строке. Если же наш ввод допускает альтернативы продолжения имени — все они высветятся на экране (сразу или после повторного нажатия на табулятор), и из них можно будет выбрать подходящую.
Большинство употребимых команд POSIX-систем — коротки и мнемонически прозрачны. И может показаться. что не такое уж это облегчение — заменить ввод двух-трех символов нажатием табулятора (а то ещё и неоднократным). Однако, когда речь дойдет до аргументов команд — тут вся мощь автодополнения станет явной.
Ещё один способ облегчения ввода команд — обращение к их истории, о чём разговор будет несколько позже.
Опции
Указания только имени команды достаточно для выполнения некоторых из них. Типичный пример — команда ls (от list), предназначенная для просмотра имен файлов (строго говоря, содержимого каталогов). Данная без аргументов, она выводит список имен файлов, составляющих текущий каталог, представленный в некоторой форме по умолчанию, например, в домашнем каталоге пользователя это будет выглядеть примерно так:
Исполнение же многих других команд невозможно без указания опций и (или) аргументов. Для них в ответ на ввод одного её имени часто следует не сообщение об ошибке (или не только оно), но и краткая справка по использованию команды. Например, в ответ на ввод команды для создания каталогов mkdir (от make directory) последует следующий вывод:
Многие опции имеют две формы — краткую, односимвольную, и полную, или многосимвольную, Некоторые же опции могут быть даны только в многосимвольной форме. Общее правило здесь таково: если одного символа достаточно для однозначного определения опции, могут употребляться обе формы в качестве равноправных. Однако поскольку количество символов латинского алфавита ограниченно (а человеческая фантазия, конструирующая опции — безгранична), при большом количестве опций одной команды некоторые из них приходится делать исключительно многосимвольными.
Опять-таки, из того же примера видно, что опции в односимвольной форме предваряются единичным символом дефиса и могут быть даны единым блоком, без пробелов:
При этом, естественно, опция, требующая указания значений, ставится последней, и ее значение отделяется пробелом. Опции же в многосимвольной форме требуют предварения удвоенным дефисом, обязательно должны разделяться пробелами и значения их, если таковые требуются, присваиваются через символ равенства (по научному он называется ещё оператором присваивания):
Опции команды именуются также флагами (реже ключами) или параметрами. Однозначной трактовки этих терминов нет. Однако обычно под флагами подразумеваются опции, не требующие указания значений. Термин параметр же применяется к опции, такового требующей, и объединяет опцию и ее значение. Правда, мне встречалось определение параметра как совокупности опций и аргументов, но я буду придерживаться приведенных определений.
Пример: опции команды ls
Опции определяют условия выполнения команды. На предыдущей странице был приведён пример команды ls без опций. Однако на самом деле отсутствием опций при ней определяется вид выводимого списка по умолчанию — как многоколочночного списка, состоящего из имен файлов без учета т.н. скрытых файлов (а таковыми являются файлы, имена которых начинаются с символа точки, почему они ещё называются dot-файлами), без каких-либо их атрибутов и без визуального различия файлов различных типов.
Различные же опции команды ls определяют состав и формат выводимого списка файлов. Так, в форме
Я столь подробно остановился на команде ls не только из-за многочисленности ее опций: это — одна из самых употребимых команд для просмотра файловой системы. И, должным образом настроенная (в том числе и с помощью приведенных опций), она дает ничуть не менее информативную и зрительно выразительную картину, чем развитые файловые менеджеры типа Midnight Commander или многочисленные файловых менеджеры графического режима.
Аргументы
Таким образом мы подобрались к понятию аргументов командной директивы. Аргументами определяется, как правило, объект (или объекты) действия команды. В большинстве случаев в качестве аргументов команд выступают имена файлов и (или) пути к ним.
Большинство команд допускает указание не одного, а нескольких (и даже очень многих) аргументов. Так, единой директивой вида
можно скопировать (команда cp — от copy) сколько угодно файлов из текущего каталога в каталог dir (на самом деле на это «сколько угодно» накладываются некоторые теоретические ограничения, определяемые максимально возможной длиной командной строки, но практически предел этот очень далек).
Маленькое отступление. Упоминание команды cp — удобный случай чуть вернуться назад и рассмотреть одну очень важную опцию, почти универсальную для команд POSIX-систем. Для начала попробуем скопировать один каталог в другой:
Как вы думаете, что получится в результате? Правильно, сообщение о невозможности выполнения этой операции — примерно в таком виде:
Вообще рекурсия (то есть определение некоего выражения через самого себя) — очень важное понятие в Unix, пронизывающее происходящие от нее системы насквозь. И послужившие даже базой для своеобразного хакерского юмора. Однако сейчас для нас важно только то, что рекурсия применима практически ко всем файловым операциям, позволяя распространить действие одной командной директивы не только на файлы данного каталога, но и на все вложенные подкаталоги и их содержимое.
Однако вернемся к аргументам. Действие некоторых команд неоднозначно в зависимости от аргументов, к которым она применяется. Например, команда mv служит как для переименования файлов, так и для их перемещёния в другой каталог. Как же она узнает, что ей делать в данном конкретном случае? Да именно по аргументам. Если дать ее в форме
Пути к файлам
Так, если пользователь находится в своем домашнем каталоге (абсолютный путь к нему обычно выглядит как /home/username ), то просмотреть содержимое каталога /usr/bin он может двумя способами — тем, который был дан в предыдущем примере, или вот так:
Пути в аргументах команд могут быть весьма длинными. Например, чтобы просмотреть список шрифтов, применяемых в интерфейсе Cinnamon по умолчанию, нужно дать команду следующего вида:
И читатель вправе спросить — неужели мне все это вводить вручную? Отнюдь — отвечу я ему. Потому что автодополнение, о котором упоминалось по ходу разговора об именах команд, действует также для путей в их аргументах — последовательным нажатием клавиши табуляции все недостающие символы будут добавляться
Кое-что об исключениях
Итак, типичная форма POSIX-команды в обобщенном виде выглядит следующим образом:
Из этого правила выбиваются немногочисленные, но весьма полезные и часто используемые команды. Однако и для таких команд с нестандартным синтаксисом устанавливаются те же компоненты — имя, опции, аргументы, хотя по ряду причин (в том числе исторических) порядок их может меняться.
требует отыскать в домашнем каталоге (
/ ), выступающем в качестве аргумента, файлы, имя которых (первая опция — критерий поиска) соответствует шаблону *.tar (значение первой опции), и выполнить (вторая опция — действия) в их отношении команду tar с собственными опциями, обеспечивающими распаковку архивов (значение второй опции). Интересно, что в этом контексте в качестве значений второй опции команды find выступает не только внешняя команда, но и все относящиеся к ней опции.
В последнем примере имеется несколько символов, смысл которых может показаться непонятным. Надеюсь, он прояснится достаточно скоро — в разговоре о регулярных выражениях.
Псевдонимы
Отнюдь — ответил бы граф, стуча манжетами о подоконник. Потому что этот вопрос задавали себе многие поколения не только пользователей, но и разработчиков. И ответили на него просто — введением понятия псевдонима команды (alias).
Таким образом мы можем наделать себе псевдонимов на все случаи жизни. В разумных пределах, конечно — иначе вместо упрощения жизни мы создадим себе необходимость запоминания множество невнятных сочетаний символов. Однако на наиболее важных (и обычно определяемых) псевдонимах я остановлюсь.
И пользователь может решить, нужно ли ему затирать существующий файл, ответив yes (обычно достаточно y ), или это нежелательно, и должно ответить no (а также просто n — или не отвечать ничего, это равноценно в данном случае отрицательному ответу).
Правда, предварительно нужно убедиться, что в системе нет уже команды с именем, совпадающим с именем псевдонима — иначе эффект может быть весьма неожиданным (впрочем, это относится ко всем псевдонимам, не совпадающим с именами подменяемых команд).
Есть и другой способ обойти опции, установленные для команды-псевдонима: просто отменить псевдоним. Что делается командой обратного значения
То есть дав директиву
мы вернем команде копирования ее первозданный смысл. Ну а узнать, какие псевдонимы у нас определены в данный момент, и каковы их значения, ещё проще: команда
без опций и аргументов выведет полный их список:
Когда я сказан о пользовании псевдонимами ныне, и присно, и вовек, — то был не совсем точен. Ныне, то есть в текущем сеансе пользователя — да, они работают. Однако после рестарта системы (или просто после выхода из данного экземпляра командной оболочки) они исчезнут без следа. Чтобы заданные псевдонимы увековечить, их нужно прописать в конфигурационном файле пользовательского шелла. Но этим мы займемся впоследствии. А пока обратимся к переменным.
Переменные
Переменные играют для аргументов команд примерно такую же роль, что и псевдонимы — для команд. То есть избавляют от необходимости мрачного ввода повторяющихся последовательностей символов. Конечно, это — далеко не единственное (а может быть, и не главное) назначение переменных, однако на данном этапе для нас наиболее существенное.
Что такое переменная? Ответ просто — некоторое имя, которому присвоено некоторое значение. Не очень понятно? — Согласен. Но, возможно, станет яснее в дальнейшем.
Все эти (и ещё некоторые) имена зарезервированы за внутренними, или встроенными, переменными оболочки (некий минимальный их набор имеется в любом шелле). То есть значения их определены раз и навсегда. и пользователем не изменяются. То есть он, конечно, может их изменить, если очень хочет — но ничего доброго, кроме путаницы, из этого не выйдет.
Обратим внимание на то, что в качества аргумента команды выступает не просто имя переменной, а оно же, но предваренное символом доллара. Который в данном случае никакого отношения к приглашению командной строки не имеет, а предписывает команде echo подменить имя переменной ее значением (значениями). В большинстве дистрибутивов Linux случае вывод команды для пользователя будет в обязательном порядке включать такие каталоги:
Обратим вниммание на одно важное обстоятельство: практически во всех дистрибутивах Linux и в более иных ОС в перечне значений переменной PATH отсуствует текущий каталог
и он в своих владениях. Может показаться, что экономия — грошовая (тем паче, что перейти в собственный каталог пользователь может просто командой cd без всяких аргументов), но минуту терпения — и выгоду от использования переменных вы увидите.
Кроме переменных, предопределенных в шелле, пользователю предоставляется почти полная свобода в определении переменных собственных. И вот тут-то и наступает ему обещанное облегчение при наборе аргументов команд.
Предположим, что у нас имеется глубоко вложенный подкаталог с данными, постоянно требующимися в работе. Чисто условно примем, что путь к нему — следующий:
Весьма удручающе для набора, даже если исправно работать табулятором для автодополнения, не так ли? Прекрасно, упрощаем себе жизнь определением переменной:
Дело в шляпе, Теперь, если нам нужно просмотреть состав этого каталога, достаточно будет команды
А вызвать из него любой файл для редактирования можно так:
Подобно псевдонимам, переменные, определенные таким образом (то есть просто в командной строке), имеют силу только в текущем сеансе работы — по выходе из оболочки они утрачиваются. Для того, чтобы они действовали перманентно, переменные должны быть прописаны в конфигурационном файле пользовательского шелла. Однако, в отличие от псевдонимов, и этого оказывается не всегда достаточно. Ибо переменная, определенная посредством
работает не просто только в текущем сеансе — но ещё и только в конкретном экземпляре шелла. Почему и называется переменной оболочки — shell variable. Звучит это. быть может, пока не очень понятно. Однако практически любое действие в шелле — запуск команды или программы, например, — начинается с того, что оболочка, в которой это действие совершается, запускает новый экземпляр самой себя — дочерний шелл, или, как иногда говорят, субшелл.
Так вот, этот самый субшелл не наследует переменные родительской оболочки. И в итоге запущенная из командной строки программа ничего не будет знать, например, о путях к исполняемым файлам. Что автоматически ведет к невозможности запуска из нее команд просто по имени, без указания точного пути.
Чтобы избежать такой неприятной ситуации, было придумано понятие переменных окружения, или переменных среды — environment variable. Это — те переменные, которые наследуются от родительского шелла всеми дочерними программами. И чтобы сделать их таковыми, переменные следует экспортировать. Как? Командой export, которая может быть применена двояким образом. Можно сначала определить переменную:
а затем применить к ней команду export :
А можно сделать это в один прием:
Второй способ применяется, если нужно определить и экспортировать одну переменную. Если же за раз определяется несколько переменных:
то проще прибегнуть к первому способу, так как команда export может иметь сколько угодно аргументов:
Традиционно имена переменных окружения задаются в верхнем регистре, переменных оболочки — в нижнем.
Навигация и редактирование
Имя команды, ее опции и аргументы образуют т.н. командные «слова». В качестве словоразделителей выступают пробелы. Кроме того, как разделители «слов» интерпретируется ряд специальных символов — прямой слэш ( / ) — элемент пути к файлу, обратный слэш ( \ ), служащий для экранирования специальных символов, и операторы командных конструкций, о которых будет сказано ниже.
В некоторых случаях имеет смысл различать «большое слово» и «малое слово». Первые разделяются пробелами, в качестве же вторых интерпретируются символы, лежащие между всеми другими словоразделителями.
Подчеркнем, что командное «слово» прямо не соотносится ни с опциями, ни с аргументами команды. Введение этого понятия призвано просто облегчить навигацию в командной строке и ее редактирование.
Ибо одно из великих достижений командного интерфейса POSIX-систем, заценить которое могут в полной мере только те, кто застал времена «черного DOS’а», — это возможность перемещёния внутри командной строки и внесения необходимых изменений в имя команды, ее опции и аргументы. Делается это различными способами.
Оказывается — есть чего, и самый очевидный способ навигации и редактирования оказывается не самым эффективным. Для начала заметим, что в общем случае привычные клавиши перемещёния курсора и редактирования в POSIX-системах не обязаны работать также, как они делают это в DOS/Windows. Это зависит от многих причин, в том числе и исторических. Ведь POSIX-системы по определению предназначены работать на любых практически машинах (в том числе и на тех, клавиатуры которых клавиш управления курсором просто не имели).
Однако это не главное — в большинстве Linux-дистрибутивов командная оболочка по умолчанию настраивается так, чтобы пользователь при желании мог использовать привычные ему клавиши. Однако тут-то и оказывается, что плюс к этому оболочка предоставляет ему много более эффективную систему навигации по командной строке и ее редактирования. И это — система управляющих последовательностей, так называемых keybindings. То есть сочетания специальных клавиш, именуемых управляющими, с обычными алфавитно-цифровыми.
Управляющие последовательности
Впрочем, к этой теме я ещё вернусь. А пока достаточно нескольких простых рецептов, практически универсальных для любых командных оболочек в терминалах любых типов.
Главное же преимущество клавиатурных последовательностей перед стандартными навигационными клавишами — много более широкая их функциональность. Я не случайно начал этот параграф с упоминания командных «слов» — это, наряду с единичными символами, также навигационные (и, добавлю, редакционные) единицы командной строки. То есть управляющие последовательности позволяют при навигации и редактировании оперировать не только единичными символами, но и целыми словами.
Рассматривать ключевые последовательности подробно здесь я не буду: детали их действия зависят от командной оболочки и ее настроек. Отмечу только два существенных обстоятельства. Первое: keybindings предоставляют пользователю полный комплекс приемов для любых действий в командной строке — вплоть до преобразования регистров уже введенных символов и «слов» (из нижнего в верхний и наоборот), «перетасовки» символов в команде или ее аргументах, и так далее.
И второе — действие ключевых последовательностей, как правило. не зависит не только от типа терминала и физического устройства клавиатуры, но и от ее раскладки — при переключении на кириллицу они будут работать столь же справно, как и в латинице.
История команд
Возможности навигации и редактирования строки особенно ярко проявляются в сочетании с другой замечательной особенностью, предоставляемой командными оболочками — доступом к истории команд. То есть: раз введенная в строке команда не уходит в небытие после исполнения, а помещается в специальный буфер памяти. Который, как и все в Unix’ах, именуется весьма незатейливо — буфер истории команд. Откуда команда (со всеми её опциями и аргументами) может быть извлечена для повторного использования. Или — для редактирования и исполнения в новой реинкарнации.
Буфер истории команд сохраняется в течении всего сеанса работы. Однако в большинстве случаев командные оболочки настраиваются так, что по выходе из сеанса буфер истории сохраняется в специальном файле в домашнем каталоге пользователя, и таким образом его содержимое оказывается доступным при следующем запуске шелла. Имя этого файла может быть различным в разных оболочках, но обычно включает компонент history (в Bash —
/.bash_history ).Так что, можно сказать, что введенным нами командам суждена вечная жизнь.
Конечно, не совсем вечная. И размер буфера истории команд, и количество строк в файле истории — величины конечные. Так что, если установленный предел превышен, то старые команды вытесняются более новыми. Однако и величину буфера, и количество строк в файле истории можно установить любыми. Разумеется, в разумных пределах — не знаю, существует ли принципиальное ограничение на их размер, за исключением объёма памяти и дискового пространства. А если учесть, что и из буфера, и из памяти с помощью соответствующих настроек (со временем я расскажу, каких) можно исключить дубликаты и ещё кое-какой мусор — то мое заявление о вечной жизни команд не выглядит столь уж преувеличенным.
Универсальное средство доступа к буферу истории команд — специальная команда, встроенная во все шеллы, таковой поддерживающие — history (в большинстве дистрибутивов Linux она по умолчанию имеет псевдоним — h ). Данная без опций, эта команда выводит полный список команд в их исторической (издревле к современности) последовательности, или некоторое количество команд, определенных соответствующими настройками (о которых будет говориться позднее).
В качестве опции можно указать желаемое количество одновременно выведенных команд. Например, директива
выведет две последние команды из буфера истории вместе с их номерами:
Поиск в истории
Во всех современных «развитых» шеллах предусмотрены средства поиска команды в буфере истории — простым перебором (обычно Meta+P — назад и Meta+N — вперед).
Впрочем, не смотря на громкое название, обычный поиск ничем практически не отличается от пролистывания исторического списка курсорными стрелками. Что при обширной истории команд может быть весьма утомительным. И потому для ее облегчения предусмотрена такая интересная возможность, как наращиваемый поиск (incremental search) нужной команды в буфере истории по одному (или нескольким) из составляющих ее символов.
Выполняется инкрементный поиск так: после нажатия (при пустой командной строке) клавишной комбинации Control+R появляется предложение ввести алфавитный символ (или — последовательность символов произвольной длины), заведомо входящий в состав требуемой команды:
Ввод такого символа выведет последнюю из команд, его содержащих. При этом введенный символ будет отмечен знаком курсора. Он не обязан входить в имя команды, но может быть составляющим ее опций или аргументов (имени файла или пути к нему, например). Следующее нажатие Control+R зафиксирует курсор на предыдущем символе, в пределах этой же или более ранней по списку команды, и т.д. Однако вместо этого в строке поиска можно вводить дополнительные символы, детализирующие условия поиска команды (или — ее опций и аргументов).
Регулярные выражения
Как известно, все пользователи-POSIX’ивисты должны быть в обязательном порядке привержены одному из семи смертных грехов. И грех этот — леность, можно сказать, показатель профессиональной пригодности линуксоида. В соответствие со своей леностью разработчики POSIX-систем придумывают способы, как бы им минимизировать свои усилия. А применители из лени изощряются в использовании этих приемов на практике. В частности — в том, как свести к минимуму набор в командной строке.
Собственно говоря, этой цели служили почти все приемы, описанные выше. Осталось осветить немногое. А именно — регулярные выражения, реализуемые с помощью т.н. специальных символов (или метасимволов).
то она гарантированно охватит все возможные маски html-документов.
Группировка аргументов может быть сколь угодно глубоко вложенной. Так, команда
Экранирование
Из приведённых примеров можно видеть, что метасимволы, образующие регулярные выражения, интерпретируются командной оболочкой особым образом, не так, как обычные алфавитно-цифровые символы, составляющие, скажем, имена файлов.
В то же время собственно POSIX-системы накладывают на имена файлов очень мало ограничений. И в принципе система не запретит вам создать файл с именем, содержащим метасимволы. Другое дело, что работать с таким образом именованными файлами может быть сложно — командная оболочка будет пытаться интерпретировать их в соответствии с правилами для регулярных выражений.
Конечно, использовать метасимволы в именах файлов весьма не рекомендуется. Однако а) возможны элементарные ошибки при наборе, и б) файлы, полученные при обмене с другими операционными системами (сами знаете. какими), могут иметь довольно непривычный (и, я даже сказал бы, неприличный) вид.
Начнём с первого примера использования экранирования — разрыва длинных строк. Командные директивы, с многочисленными их опциями, особенно в полной форме, и аргументами могут оказаться весьма длинными, не укладывающимися в пределы экранной строки. Правда, обычно командная оболочка по умолчанию настраивается с разрешением так называемого word wrapping’а (то есть переноса «слов» команды без обрыва строки — последнее, как мы помним, достигается нажатием клавиши Enter или комбинации Control+M и приводит к немедленному исполнению введённой команды. Если ввод ее не окончен — последует сообщение об ошибке). Однако перенос «слов» при этом происходит, как бог на душу положит. И в результате командная директива теряет читабельность и становится сложной для понимания.
Возвращаемся к экранированию обратным слэшем. Действие его распространяется только на непосредственно следующий за ним символ. Если символы, могущие быть воспринятые как специальные, идут подряд, каждый из них должен предваряться обратным слэшем.
И вот тут обратный слэш проявляет свое инвертирующее действие: последовательность \033 будет восприниматься уже не как набор символов, а как код символа Escape (обратим внимание, что тут достаточно единичного слэша). Непосредственно в командной строке такой способ инвертированного экранирования, по понятным причинам, обычно не используется, но находит широкое применение в сценариях.
О кавычках
ещё одно широко применяемое использование двойных кавычек — экранирование пробелов, предотвращающих разбиение аргументов команды на отдельные «слова». Правда, в случае с командой echo это, как правило, не требуется (хотя настоятельно рекомендуется экранировать ее аргумент таким образом). Однако представьте, что в качестве аргумента команды копирования и перемещёния выступает файл, переписанный с Windows-машины. Ведь там пробелы в именах — вещь обычная. Тут-то экранирование двойными кавычками и придется к месту.
Из сказанного понятно, почему двойные кавычки именуются ещё неполными, или не строгими — они все же допускают внутри себя использование символов со специальными значениями. В противоположность им, кавычки одинарные носят имя строгих, или полных. Потому что между ними утрачивают специальное значение все метасимволы, кроме их самих — в том числе и символ единичного экранирования. В итоге они используются там, где гарантированно требуется отсутствие специальных символов. Если вы помните, мы применили строгие кавычки при установке псевдонимов. Они же часто оказываются обязательными при определении переменных.
Завершая тему экранирования, осталось сказать только об обратных кавычках. Их функция очень узка: они служат для экранирования команд. То есть, скажем, команда
в полном соответствие со своим именем, просто выведет нам собственный аргумент:
Однако если аргумент команды закрыть обратными кавычками, то date будет воспринято как имя команды, подлежащей исполнению. И результат этого исполнения (то есть текущая дата и время — а именно для их получения и предназначена команда date) будет замещать имя команды в выводе echo:
Если вспомнить, что обратные кавычки сохраняют свое специальное значение внутри кавычек двойных, становится ясной польза от их применения: они незаменимы в тех случаях, когда требуется вывод результатов работы одной команды внутри другой. К как в нашем примере с выводом даты, если его (вывод) следует включить в некое выдаваемое командой echo сообщение.
Конечно, в описанном случае добиться той же цели можно было бы гораздо легче — просто командой date. Однако представьте, что у нас возникло желание одновременно и получить сведения о количестве пользователей в системе (для чего предназначена команда who). Тут-то и выясняется. что проще всего это сделать командой типа следующей:
Ответом на что будет сообщение, подобное тому, что часто можно наблюдать на главной странице многих сайтов:
А теперь последнее, чем и закроем тему регулярных выражений вообще. В этом разделе рассматривалось использование метасимволов в командной оболочке (конкретно, в данном случае. в Dash, Bash и Zsh). В других оболочках применение метасимволов и условия их экранирования могут несколько отличаться. И к тому же многие запускаемые из строки шелла команды могут иметь свои правила построения регулярных выражений. Так что в итоге их форма определяется сочетанием особенностей конкретной оболочки и команды, из неё запущенной. Все это при необходимости будет оговариваться в дальнейшем.
А пока переходим к рассмотрению командных конструкций — одной из тех особенностей CLI, которая определяет мощь и универсальность этого интерфейса.
Вводные слова о командных конструкциях
Надеюсь, из того, что было рассказано на предшествующих страницах, посвящённых CLI, читателю стало ясно, что подавляющее большинство команд в POSIX-системах очень просты по сути и предназначены для выполнения какого-либо одного элементарного действия.
То есть команда cp умеет только копировать файлы, команда rm — только удалять их, но зато делают они это хорошо. Подчас — через чур хорошо, что мог ощутить на себе каждый, кому «посчастливилось» по ошибке выдать директиву вроде
Для тех, кто не испытал этого волнительного ощущения, поясню: результатом будет полное и безвозвратное уничтожение всех файлов от текущего каталога вниз (включая подкаталоги любой степени вложенности).
А если задать ту же команду от лица администратора, то, в зависимости от текущего положения на файловом древе, можно нечувствительно удалить что угодно, вплоть до системы целиком: одна из причине, почему повседневные действия не следует выполнять под root’ом.
Собственно, разделение любой задачи на серию элементарных операций — это и есть основной принцип работы в POSIX-системах, тот самый пресловутый Unix-way, о котором столько говорят его приверженцы.
Однако вслед за этапом решительного размежевания (эх, неистребимы в памяти нашего поколения слова товарища Ленина) должен наступить этап объединения, как за анализом явления следует синтез эмпирических данных о нём. И целям такого объединения служат командные конструкции.
Командные конструкции — очень важный компонент интерфейса командной строки. Они позволяют объединять несколько команд воедино и выполнять различные команды последовательно или параллельно. Для этого служат специальные символы — операторы: фонового режима, объединения, перенаправления и конвейеризации.
Совместное выполнение команд
Простейшая командная конструкция — это выполнение команды в фоновом режиме, что вызывается вводом символа амперсанда после списка опций и (или аргументов):
В Bash и Zsh пробел перед символом амперсанда не обязателен, но в некоторых шеллах он требуется, и потому лучше возвести его ввод (как и во всех аналогичных случаях) в ранг привычки. После этого возвращается приглашение командной строки и возможен ввод любых других команд (в том числе и фоновых). Команды для параллельного исполнения можно задать и в той же строке:
В результате все команды, перечисленные в строке, кроме той, что указана последней, будут выполняться в фоновом режиме.
Существуют и конструкции для последовательного выполнения команд. Так, если ряд команд разделен в строке символом точки с запятой ( ; )
и так далее. При этом первая команда может, например, копировать файлы, вторая — осуществлять поиск, третья — выполнять сортировку, или другие действия. Очевидно, что в общем случае выполнение последующей команды не зависит от результатов работы предшествующей.
Однако возможна ситуация, когда результаты предыдущей команды из такой конструкции используются в команде последующей. В этом случае ошибка исполнения любой составляющей команды, кроме последней, делает невозможным продолжение работы всей конструкции. Что само по себе было бы ещё полбеды — однако в некоторых ситуациях исполнение последующей команды возможно только при условии успешного завершения предыдущей.
Характерный пример — сборка программы из ее исходных текстов, включающая три стадии — конфигурирование, собственно компиляцию и установку собранных компонентов. Что обычно выполняется последовательностью из трёх команд:
Ясно, что если конфигурирование завершилось ошибкой, то компиляция начаться не сможет и, соответственно, потом нечего будет устанавливать. И потому объединение их в последовательную конструкцию вида
может оказаться нецелесообразным.
Однако для предотвращения таких ситуаций в конструкции из взаимосвязанных команд существует другой оператор, обозначаемый удвоенным символом амперсанда — &&. Он указывает, что последующая команда конструкции должна исполняться только в том случае, если предыдущая завершилась успешно:
На практике обе приведённые в качестве примера конструкции дадут один и тот же результат — разумеется, если все составляющие их команды будут выполнены без ошибок. Однако в ряде иных случаев различие между этими конструкциями может быть существенным.
Впрочем, предусмотрена и командная конструкция, в которой последующей команде предписано исполняться в том и только в том случае, если предыдущая команда завершилась неудачно. Она имеет вид
и может служить, в частности, для вывода сообщений об ошибках.
Перенаправление
Следующая командная конструкция — это так называемое перенаправление ввода/вывода. Чтобы понять,что это такое, нужно помнить две вещи:
любая команда получает данные для своей работы (например, список опций и аргументов) со стандартного устройства ввода (которым в первом приближении будем считать клавиатуру), а результаты своей работы представляет на стандартном устройстве вывода (коим договоримся считать экран монитора);
POSIX-системах любое устройство — не более чем имя специального файла, именуемого файлом устройства.
Таким образом, ничто не запрещает нам подменить специальный файл устройства ввода или устройства вывода любым иным файлом (например, обычным текстовым). Откуда и будут в этом случае браться входные данные или куда будет записываться вывод команды.
Перенаправление вывода команды обозначается следующим образом:
Во втором же случае (двойной символ >> ) происходит добавление вывода команды command в конец существующего файла filename (при отсутствии же его в большинстве случаев просто образуется новый файл). И потому это называется присоединяющим перенаправлением, или перенаправлением в режиме присоединения.
Перенаправление ввода выглядит так:
Простейший случай перенаправления вывода — сохранение результата исполнения команды в обычном текстовом файле. Например, конструкция
При перенаправлении ввода команда получает данные для своей работы из входящего в командную конструкцию файла. Например, конструкция
осуществит сортировку строк того же файла в порядке, обратном алфавитному (вернее, обратном порядку кодов символов, но это нас в данном случае не волнует).
В одной конструкции могут сочетаться перенаправления ввода и вывода, как в режиме замещёния, так и в режиме присоединения. Так, конструкция
Конвейеры
Возможности построения командных конструкций не ограничиваются перенаправлением ввода/вывода: результаты работы одной команды могут быть переданы для обработки другой команде. Это достигается благодаря механизму программных каналов (pipe) или конвейеров — последний термин лучше отражает существо дела.
При конвейеризации команд стандартный вывод первой команды передается не в файл, а на стандартный ввод следующей команды. Простой пример такой операции — просмотр списка файлов:
Конвейеризация команд может быть сколь угодно длинной. Возможно также объединение конвейеризации команд и перенаправления в одной конструкции. Кроме того, команды в конструкции могут быть сгруппированы с тем, чтобы они выполнялись как единое целое. Для этого группа команд разделяется символами ; и пробелами, как при последовательном выполнении команд, и заключается в фигурные скобки. Так, если нам требуется перенаправить вывод нескольких команд в один и тот же файл, вместо неуклюжей последовательности типа
можно прибегнут к более изящной конструкции:
И в результате получить файл такого (условно) содержания, которое мы для разнообразия просмотрим с помощью только что упомянутой команды cat (благо и для просмотра содержимого файлов она также пригодна):
Понятие о фильтрах
С понятием командных конструкций тесно связано понятие программ-фильтров. Это — команды, способные принимать на свой ввод данные с вывода других команд, производить над ними некоторые действия и перенаправлять свой вывод (то есть результат модификации полученных данных) в файлы или далее по конвейеру — другой команде.
Программы-фильтры — очень эффективное средство обработки текстов, и в своё время мы к ним вернемся для подробного изучения. Пока же важно отметить, что в качестве фильтров могут работать не все команды. Например, команды find или grep фильтруют имена файлов или фрагменты их содержимого, а команда ls фильтром не является.
Сценарии оболочки
Наш затянувшийся разговор о командах и командном интерфейсе подходит к концу. И в заключение этого раздела — ещё немного терпения. Потому что было бы несправедливо не уделить чуть-чуть места тому, что придает командному интерфейсу POSIX-систем его несравненную гибкость и универсальность. Заодно способствуя закоснению пользователя в смертном грехе лености. Итак — слово о сценариях оболочки.
В самом начале я обмолвился, что шелл — это не просто среда для ввода единичных команд и командных конструкций, но и ещё интерпретатор собственного языка программирования. Так вот, сценарии оболочки, именуемые также скриптами, — это и есть программы, написанные на этом языке.
Только не заподозрите меня в гнусном намерении учить вас программерству. Господь борони, и в мыслях не держал (тем паче, что и сам-то этим ремеслом не владею в должной для обучения других степени). Нет, просто на последующих страницах нам то и дело придётся рассматривать кое-какие примеры готовых сценариев, а подчас и пытаться создавать их собственноручно. Ибо занятие это в элементарном исполнении навыков программирования не требует вообще.
В самом простом случае сценарий — это просто одна или несколько команд или (и) командных конструкций с необходимыми опциями и аргументами, сохраненные в виде обычного именованного текстового файла. И предназначены они в первую очередь для автоматизации часто исполняемых рутинных операций, в частности, ввода длинных последовательностей в командной строке.
Создание пользовательского сценария — просто, как правда. Для этого всего и нужно:
С принципами создания команд и командных конструкций мы в первом приближении разобрались раньше. А вот способов помещёния их в файл существует множество. Можно просто ввести (или вызвать из буфера истории) нужную команду и оформить ее как аргумент команды echo, вывод которой перенаправить в файл:
Таким образом мы получили простейший скрипт для копирования файлов из рабочего каталога в каталог для резервного хранения данных, что впредь и будем проделывать регулярно (не так ли?).
Аналогичную процедуру можно выполнить с помощью команды cat — она, оказывается, способна не только к объединению файлов и выводу их содержимого, но и к вводу в файл каких-либо данных. Делается это так. Вызываем cat с перенаправлением ее вывода в файл:
В результате получаем сценарий для архивирования в специально предназначенном для этого каталоге archivedir наших рабочих данных (командой tar), а заодно и их компрессии (командой gzip ) — в Unix, в отличие от DOS/Windows, архивирование и компрессия обычно рассматриваются как разные процедуры.
Наконец, сценарий можно создать в любом текстовом редакторе. но это не так интересно — по крайней мере, пока. Да и стоит ли вызывать редактор ради двух-трёх строк?
Комментариями в шелл-сценариях считаются любые строки, начинающиеся с символа решетки ( # ) — они не учитываются интерпретатором и не принимаются к исполнению. Хотя комментарий может быть начат и внутри строки — важно только, что между символом # и концом её больше ничего не было бы. Ясно, что комментарии — элемент для скрипта не обязательный, но очень желательный. Хотя бы для того, чтобы не забыть, ради чего этот сценарий создавался.
Но одна строка, начинающаяся символом решётки, в сценарии практически обязательна. И должна она быть первой и выглядеть следующим образом:
В данном случае восклицательный знак подчеркивает, что предваряющий его символ решетки ( # ) — не комментарий, а указание (т.н. sha-bang) на точный абсолютный путь к исполняемому файлу оболочки, для которой наш сценарий предназначен, например,
для POSIX-шелла, или
для оболочки Bash. Здесь следует подчеркнуть, что шелл, для которого предназначается сценарий, отнюдь не обязан совпадать с командной оболочкой пользователя. И полноты картины для замечу, что указание точного имени интерпретатора требуется не только для шелл-скриптов, но и для программ на любых языках сценариев (типа Perl или Python).
Теперь остается только выполнить наш сценарий. Сделать это можно разными способами. Самый напрашивающийся — непосредственно вызвать требуемый шелл как обычную команду, снабдив его аргументом — именем сценария (предположим, что он находится в текущем каталоге):
Далее, для вызова скриптов существует специальная встроенная команда оболочки, обозначаемая символом точки. Используется она аналогично:
Однако наиболее употребимый способ запуска сценариев — это присвоение его файлу так называемого атрибута исполнения. Эта процедура волшебным образом превращает невзрачный текстовый файлишко во всамделишную (хотя и очень простую) программу.
Так вот, после присвоения нашему сценарию бита исполнения запустить его можно точно также, как любую другую команду — просто из командной строки:
Понятие о функциях
И уж совсем в заключение этого раздела осталось сказать пару слов о функциях командной оболочки. Это — такая же последовательность команд (или даже просто одиночная команда), как и сценарий, но — не вынесенная в отдельный исполняемый файл, а помещённая в тело другого скрипта. В коем она опознаётся по имени, и может быть выполнена неоднократно в ходе работы этого скрипта.
Главное отличие функции от сценария — в том, что она выполняется в том же процессе (и, соответственно, экземпляре шелла), что и заключающий её сценарий. Тогда как для каждого скрипта, вызываемого из другого сценария, создаётся отдельный процесс, порождающий собственный экземпляр шелла. Это может быть важным, если в сценарии определяются некоторые переменные, которые имеют силу только в нём самом.
Функции не обязательно помещаются внутрь сценария — их можно собрать в некоторые отдельные файлы, которые именуются библиотеками функций и могут быть использованы по мере надобности.
Настройка шелла
Во всех дистрибутивах Linux в качестве пользовательской командной оболочки по умолчанию выступает Bash, и Mint здесь не исключение. Так что, хотя автор этих строк не является ни её любителем, ни, тем более, знатоком, совсем обойти её вниманиемне мог. Так что ниже даётся мини-очерк настройки этого шелла.
Оболочка Bash поддерживает все интерактивные возможности, столь важные для пользователя, как то: автодополнение для команд и путей к файлам, историю оных (включая средства инкрементного поиска), мощные возможности навигации и редактирования командной строки.
Важно, что существует дополнительный пакет bash-completion: установка его обогащает базовую оболочку множеством опциональных средств настройки автодополнения (в том числе и для командных аргументов). Правда, чтобы эта дополненная оболочка была по настоящему удобной и функциональной, нужно приложить некоторые усилия по её настройке, чем мы сейчас и займёмся.
Схема настройки bash предусматривает наличие пары файлов /etc/profile и /etc/bashrc (для логин-шелла и просто интерактивного его экземпляра), а также соответствующих им пользовательских конфигов —
/.bashrc. Файл /etc/profile может занимать особое положение — в него часто помещают переменные окружения (например, локально-зависимые), которые должны быть общими для всех пользователей данной системы. Пользовательские же настройки определяются в файлах
/.bash_profile определяются переменные окружения, которые должны действовать для всех дочерних процессов, а в
/.bashrc — параметры, всегда требуемые в интерактивном режиме (например, псевдонимы).
Впрочем, в большинстве современных дистрибутивов Linux, ориентированных на графический режим и, следовательно, использование эмулятора терминала с интерактивным шеллом, не являющимся, тем не менее, шеллом пользовательским (login shell),
/.bash_profile играет сугубо служебную роль, и содержимое его сводится к отработке файла
/.bashrc и выполняются при этом все пользовательские настройки.
Большинство настроек Bash по умолчанию разумны, и потому наличные в данном дистрибутиве файлы вполне могут быть взяты за основу. Однако путём некоторых несложных действий их можно дополнить, увеличив удобство интерактивного использования командной оболочки.
Решается эта задача очень просто: достаточно файл
/.bashrc внести следующие строки:
Если в файл /etc/inpurc (или в
/inpurc) добавить такие строки: