Differences between revisions 15 and 31 (spanning 16 versions)
Revision 15 as of 2008-07-28 11:35:53
Size: 26351
Comment:
Revision 31 as of 2009-03-22 18:52:24
Size: 29835
Editor: eSyr
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== Основы использования командной строки == == Принципы человеко-машинного взаимодействия в GNU/Linux ==

=== Парадигмы GNU/Linux ===
Line 5: Line 7:
 * во-вторых, может наступить момент, когда придется переходить на другую графическую среду, с другими принципами организации: только самых распространенных сред --- три (KDE, Gnome, XFCE);   * во-вторых, может наступить момент, когда придется переходить на другую графическую среду, с другими принципами организации: только самых распространенных сред --- три (KDE, Gnome, XFCE);
Line 7: Line 9:
## Очевидно, что будучи, операционной системой, GNU/Linux должен отвечать (и отвечает) перечисленным требованиям к операционной системе.
Line 8: Line 11:
Ответим наконец на вопрос: что же такое Линукс? Мы уже знаем, что Линукс это в первую очередь сообщество, а то, что мы видим, --- результат работы сообщества. Но этот ответ неполон. Понятно, что Линукс должен отвечать перечисленным требованиям к ОС, мы же пока видели лишь пользовательские приложения. На самом деле ответ базируется на принципах человеко-машинного взаимодействия. Человек должен не просто управлять компьютером, а обладать инструментом для решения (и изобретения решения) любой задачи. Сформулируем теперь ключевое утверждение: Линукс как ОС (комплекс программных средств, обеспечивающий унификацию, разделение и разграничение ресурсов для пользовательских программ), базируется на трех принципах: Ответим теперь на вопрос: что же такое GNU/Linux (или, неформально, "Линукс")? Мы уже отметили, что это, в первую очередь, свободный программный продукт, разрабатываемый множеством сообществ разработчиков. Однако, это ответ с точки зрения процесса разработки и он неполон.
Ответ на этот вопрос можно получить, рассмотрев базовые принципы человеко-машинного взаимодействия в GNU/Linux. Человек должен не просто управлять компьютером, а обладать инструментом для решения (и изобретения решения) любой задачи. Сформулируем теперь ключевое утверждение: GNU/Linux --- это свободная операционная система, то есть комплекс программных средств, обеспечивающий унификацию, разделение и разграничение ресурсов для пользовательских программ, которая базируется на следующих трех принципах.
Line 10: Line 14:
 1. '''"Все --- файл"'''. Любые системные объекты, использующиеся для управления этой самой системой, приложениями и их взаимодействием --- файлы. "Таинственные" кнопки, рабочие столы --- все взаимозаменяемо. Таким образом, одним из центральных объектов нашего изучения становится файловая система (ФС). Заметим, что этот термин может означать как способ хранения файлов на диске, так и способ представления файлов для пользователя. Речь в данном случае идет, разумеется, о втором из значений. С достаточной степенью точности можно считать, что ФС состоит из выстроенных в древовидную структуру каталогов и файлов. Организация ФС в Линуксе стандартизована и умопостижима --- разобраться, что, где и для чего нужно, обыкновенно не составляет труда.
 2. '''"Все --- текст"'''. Файлы, если они требуют ручной или автоматической модификации, --- текстовые. С точки зрения пользователя, структура ФС (и, в некотором смысле, всей ОС!) представляется в виде дерева файлов, в каждом из которых хранится информация в пригодном для чтения человеком виде. Исключение составляют файлы, не предназначенные для чтения и модификации пользователем: программы в бинарном виде, библиотеки и пр.
 3. Управление системой есть работа со специальным инструментом, манипулирующим текстовыми файлами (строго говоря, файлами и текстом вообще). Сам инструмент также не выходит за рамки парадигмы "файл --- текст": человек и машина обмениваются текстами, в результате чего модифицируются файлы. Следствием данного принципа является то, что основным интерфейсом управления Линуксом (на самом деле, Unix-подобной системой вообще) является '''интерфейс командной строки'''. Понятно, что он очень хорошо подходит для описанной парадигмы: пользователь набирает текстовые команды, компьютер команды интерпретирует, исполняет и в качестве результата выдает обратно текст.
 1. '''"Все --- файл"'''. Для управления операционной системой и GNU/Linux и ее системными сервисами используются файлы. Таким образом, одним из центральных объектов нашего изучения становится файловая система (ФС). Заметим, что этот термин может означать как способ хранения файлов на диске (физическая организация), так и способ представления файлов для пользователя (логическая организация). Речь в данном случае идет, разумеется, о втором из значений. С достаточной степенью точности можно считать, что с точки зрения пользователя файловая система состоит из выстроенных в древовидную структуру каталогов и файлов. Организация файловой системы в GNU/Linux стандартизована и вполне умопостижима --- разобраться, что где лежит и для чего нужно обыкновенно не составляет труда.
 2. '''"Все --- текст"'''. Файлы, требующие ручной или автоматической модификации, --- текстовые. С точки зрения пользователя, структура файловой системы (являющаяся некоторой проекцией всей ОС) представляется в виде дерева файлов, причем в файлах конфигурации информация хранится в пригодном для чтения и изменения человеком текстом виде. Файлы, не предназначенные для непосредственого чтения и модификации пользователем, могут быть бинарными, например к ним относятся программы в бинарном и библиотеки в откомпилированном виде.
 3. Управление системой есть работа со набором специальных инструментов, манипулирующим текстовыми файлами (строго говоря, файлами и текстом вообще). Сам инструмент также не выходит за рамки парадигмы "файл --- текст": человек и машина обмениваются текстами, в результате чего модифицируются файлы. Следствием данного принципа является то, что основным интерфейсом управления GNU/Linux  является '''интерфейс командной строки'''. Понятно, что он очень хорошо подходит для описанной парадигмы: пользователь набирает текстовые команды, компьютер команды интерпретирует, исполняет и в качестве результата выдает обратно текст.
Line 14: Line 18:
Нетрудно понять, что существуют выходящие за рамки описанной парадигмы пользовательские задачи. Заметим, однако, что речь в данном случае идет об управлении системой как таковой. Чтобы пользоваться компьютером как точкой запуска Интернет-браузера, аудиоплеера и почтового клиента, не обязательно разбираться во всех тонкостях: все нужные приложения легко найти в меню. Если же мы захотим изучать Линукс как операционную систему, то разумно пользоваться следующей схемой. Допустим, мы хотим решить задачу, а инструментов перед собой видим недостаточно: у нас есть микроскоп, а нам нужно забить девятнадцать гвоздей. Не следует пытаться решить задачу имеющимися инструментами (как максимум --- один гвоздь забить микроскопом, чтобы убедиться в нецелесообразности такого подхода). Вместо этого имеет смысл пошарить в ящике с инструментами, выбрать из этих инструментов подходящий (молоток) и в дальнейшем пользоваться (для забивания гвоздей!) именно им. Иными словами, если решение задачи представляется малоэффективным, то это значит, что используется плохо подходящий инструмент. ОС Линукс предоставляет очень богатый инструментарий, так что, скорее всего, нужный инструмент попросту не найден или же недостаточно освоен. Чтение в таких ситуациях пользовательской документации позволяет накопить багаж знаний, достаточных для решения всех своих, в том числе довольно изощренных, задач. Следует отметить, что все сказанное выше относится к любой Unix-подобной операционной системе вообще, поскольку известная расшифровка аббревиатуры GNU как ''GNU is Not Unix'' касалась только несвободной природы UNIX в 80-ые годы, но не ее принципов как операционной системы.
Line 16: Line 20:
Расскажем теперь об интерфейсе командной строки чуть более формально. Этот интерфейс на самом деле предоставляется специальной программой --- Shell'ом, или интерпретатором командной строки. Другими словами, это не Линукс с нами "разговаривает", а специальный процесс --- один из запускаемых при логине (входе в систему). Чем занимается эта программа? Она читает то, что мы вводим с клавиатуры, анализирует, выполняет соответствующие задачи и выводит результаты --- как свои, так и других программ --- в виде текста. Отметим, что данная парадигма реализуется не только Shell'ом: подобный интерфейс имеют, скажем, интерпретатор языка программирования python, клиент базы данных mysql и другие программы. Безусловно, существуют выходящие за рамки описанной парадигмы пользовательские задачи. Заметим, однако, что речь в данном случае идет об управлении операционной системой как таковой. Чтобы пользоваться компьютером как точкой запуска интернет-браузера, аудиоплеера и почтового клиента, не обязательно разбираться во всех тонкостях: все нужные приложения легко найти в меню графической среды пользователя. Если же мы захотим изучать GNU/Linux как операционную систему, то разумно пользоваться следующей схемой. Допустим, мы хотим решить какую-то задачу управления системой, а инструментов перед собой видим недостаточно: у нас есть микроскоп, а нам нужно забить девятнадцать гвоздей. Не следует пытаться решить задачу имеющимися инструментами: как максимум, можно один гвоздь забить микроскопом, чтобы убедиться в нецелесообразности такого подхода. Вместо этого имеет смысл изучить содержимое ящика с инструментами, выбрать из этих инструментов подходящий (молоток) и в дальнейшем пользоваться для забивания гвоздей именно им.
Line 18: Line 22:
Подаваемые Shell'у команды обыкновенно вводятся построчно. Каждая строка разбивается на слова в соответствии с простым правилом: последовательность любых символов, идущих подряд и не являющихся разделителями --- это слово, а последовательность разделителей --- промежуток между словами. Разделителями являются пробел, символ табуляции и символ перевода строки. Заметим, что заставить Shell воспринимать символ перевода строки как разделитель довольно непросто: перевод строки --- это управляющая клавиша, поэтому при ее нажатии Shell'у передается вся набранная строка, которую он воспринимает как законченную команду. Иными словами, если решение задачи представляется малоэффективным, то это вероятно значит, что используется плохо подходящий инструмент: нужный инструмент попросту не найден или же недостаточно освоен. GNU/Linux предоставляет очень богатый инструментарий, позволяющий пользователю при необходимости объединять имеющиеся инструменты в более сложные. Чтение в таких ситуациях документации позволяет накопить багаж знаний, достаточных для решения всех своих, в том числе довольно изощренных, задач.
Line 20: Line 24:
Итак, введенная строка разбита на слова. Первое из этих слов считается командой, а все остальные --- параметрами этой команды. Откуда взялось такое соглашение? Конечно, можно было на каждый случай жизни придумать специальную команду: нарисовать розовую мышку --- одна команда, нарисовать голубую мышку --- другая. Понятно, однако, что слова при таком подходе быстро закончились бы и команды в конце концов стали бы выглядеть довольно странно. Запомнить такой букет было бы, ясное дело, совершенно невозможно. Поэтому при работе с командной строкой применяется следующий принцип: команда (на самом деле --- скорее утилита, но об этом далее) решает ту или иную пользовательскую подзадачу, а все параметры этой подзадачи (имена файлов, нюансы работы) передаются при вводе команды в виде слов (второго и последующих). == Основы использования командной строки ==

Расскажем теперь об интерфейсе командной строки чуть более формально. Этот интерфейс на самом деле предоставляется специальной программой --- интерпретатором командной строки, называемого также командной оболочкой или "шеллом" (англ. ''unix shell''). Другими словами, это не само ядро Linux с нами "разговаривает", а специальный пользовательский процесс --- один из запускаемых при входе пользователя в систему. По умолчанию это запущенный файл {{{/bin/bash}}}. Чем занимается эта программа? Она читает то, что мы вводим с клавиатуры, анализирует, выполняет соответствующие задачи и выводит результаты --- как свои, так и других программ --- в виде текста. При использовании графической среды для запуска командного интерпретатора следует выбрать пункт ''Терминал'' из меню. При использовании среды KDE (Юниор, Мастер) это выглядит так:

{{attachment:../ui_cli_konsole1.png}}

Команды для выполнения командной оболочкой могут как вводится с клавиатуры, так и браться из файла, называемого командным сценарием или "скриптом" (англ. ''shell script''). Команды не обязательно исполняются последовательно --- на самом деле командная оболочка является интерпретатором специализированного языка программирования! Отметим, что данная парадигма реализуется не только командной оболочкой: подобный интерфейс имеют, скажем, интерпретатор языка программирования Python, клиент базы данных MySQL и другие программы.

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

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

Вначале введем некоторые общепринятые соглашения. Команда следует после символа "$", который пользователь в видит в конце приглашения к вводу при использовании командного интерпретатора. Например, запись
{{{
$ ls
}}}
означает, что следует ввести {{{ls}}} и нажать Enter. Если же для выполнения команды должно происходить от лица суперпользователя (root), то перед командной будет выводится символ "#", которым заканчивается приглашение к вводу для пользователя root. Таким образом, команды
{{{
$ su -
# service network restart
}}}
означают выполнение команды переключения пользователей {{{su}}} с параметром "-" (система запросит пароль суперпользователя) и выполнение команды {{{service}}} с параметрами {{{network}}} и {{{restart}}} с праваими суперпользователя.
Line 23: Line 48:
{{{
$ #script -t my_script 2> my_script.time
}}}

где "$", как уже было сказано, не часть команды, а приглашение ввода. Это пример того, как люди используют список введенных ими команд ("историю") в качестве записной книжки. Дело в том, что введенная в начале строки решетка является специальным символом, обозначающим комментарий. Таким образом, команда была лишь введена, но не выполнена, однако при этом она попала в историю введенных команд (эту историю, разумеется, можно просматривать, например клавишами "вверх" и "вниз"). Представим теперь, что символа комментария в начале строки не стоит:
Line 25: Line 55:
#script -t 1.script 2>1.script.time $ script -t my_script 2> my_script.time
Line 28: Line 58:
Это пример того, как люди используют список введенных ими команд ("историю") в качестве записной книжки. Дело в том, что введенная в начале строки решетка является специальным символом, обозначающим комментарий. Эта команда была лишь введена, но не выполнена, однако при этом она попала в историю введенных команд (эту историю, разумеется, можно просматривать). Представим теперь, что символа комментария в начале строки не стоит: Каким образом будет разобрана такая команда? Интерпретатор выделит имя команды ("script") и два параметра ("-t" и "my_script"). Cлово "2>" в данном случае параметром команды не является: оно содержит символ "больше" (">") и является указанием интерпретатору выполнять перенаправление вывода сообщений об ошибках в файл {{{my_script.time}}}. К моменту запуска команды это слово будет уже обработано интерпретатором (можно считать, что с точки зрения команды script соответствующая группа символов просто исчезнет).
Line 30: Line 60:
{{{
script -t 1.script 2>1.script.time
}}}
Фактически, диалог пользователя и системы при помощи командной строки происходит следующим образом. Пользователь набирает команду в командной строке, а интерпетатор эту строку обрабатывает. Обратим внимание на три этапа обработки:
Line 34: Line 62:
Каким образом будет разобрана такая команда? Интерпретатор выделит имя команды ("script") и два параметра ("-t" и "1.script"). Последнее из введенных слов в данном случае параметром команды не является: оно содержит символ "больше" (">") и является указанием Shell'у выполнять перенаправление вывода. К моменту запуска команды это слово будет уже обработано интерпретатором (можно считать, что соответствующая группа символов просто исчезнет).  * Командный интерпретатор определяет, что за команда была введена (в данном случае это {{{script}}}). В командном интерпретаторе есть небольшой набор встроенных (''built-in'') команд --- чтобы их выполнить, не нужно запускать отдельных программ (хорошим примером является команда {{{cd}}}, изменяющая текущий каталог). Если команда является встроенной, то она будет выполнена самим интерпретатором, в противном же случае он по специальному алгоритму будет вначале искать в файловой системе программу с таким именем.
Line 36: Line 64:
Фактически, диалог пользователя и системы при помощи командной строки происходит следующим образом. Пользователь набирает команду в командной строке, а Shell эту строку обрабатывает. Обратим внимание на два этапа обработки:  * Командный интерпретатор просматривает строку и ищет в ней специальные управляющие символы. Ранее, когда шла речь об обыкновенных символах и разделителях, мы намеренно допустили некоторую неточность. На самом деле есть и третий тип символов --- управляющие. После того, как интерпретатор находит управляющие символы, он их обрабатывает в соответствии с их значением. В данном случае стандартный вывод (поток) ошибок утилиты {{{script}}} перенаправляется не на терминал, а в файл (сама утилита script этого даже не заметит, если не будет специально "присматриваться").
Line 38: Line 66:
 * Shell определяет, что за команда была введена (в данном случае --- script). В Shell есть небольшой набор встроенных (built-in) команд --- чтобы их выполнить, не нужно запускать отдельных программ (хорошим примером является команда cd, изменяющая текущий каталог). Если команда является встроенной, то она будет выполнена самим интерпретатором, в противном же случае он по специальному алгоритму будет вначале искать утилиту (программу) с таким названием (именем).

 * Shell просматривает строку и ищет в ней специальные управляющие символы. Ранее, когда шла речь об обыкновенных символах и разделителях, мы намеренно допустили некоторую неточность. На самом деле есть и третий тип символов --- управляющие. После того, как Shell находит управляющие символы, он их обрабатывает в соответствии с их значением. В данном случае стандартный вывод (поток) ошибок утилиты script перенаправляется не на терминал, а в файл (сама утилита script этого даже не заметит, если не будет специально "присматриваться"). После того, как вывод будет перенаправлен, этот фрагмент строки будет считаться обработанным ("удалится"), а утилита script будет запущена с двумя параметрами.

 ''В этом абзаце используется слово '''терминал''' без всяких пояснений. На мой взгляд, необходимо (а) прокомментировать это место и (б) показать, '''где''' пользователь может увидеть собственно командную строку ('''эмуляторы терминала''' в меню, "виртуальные терминалы" на Alt+F?).'' -- DmitryChistikov <<DateTime(2008-07-27T12:55:52+0400)>>
  ''Дополнение: (в) дать ссылку вперед на пятую часть той же лекции.'' -- DmitryChistikov <<DateTime(2008-07-27T13:29:07+0400)>>
 * После того, как вывод будет перенаправлен, этот фрагмент строки будет считаться обработанным ("удалится"), а утилита {{{script}}} будет запущена с двумя параметрами.
Line 47: Line 70:
Заметим теперь, что передаваемые команде параметры обыкновенно разбиваются на две группы --- ключи и содержательные параметры. Содержательные параметры --- это имена объектов, строки, специальная информация. Ключи же --- это особого вида параметры, начинающиеся обычно с минуса ("-"). Наличие в командной строке ключей означает, что команда должна выполняться приблизительно так же, но с некоторыми нюансами (изменениями). Ключ -t в нашем случае заставляет утилиту script дополнительно выводить время (time), содержательный же параметр 1.script называет по имени файл, с которым, согласно нашей команде, утилита должна работать. Заметим теперь, что передаваемые команде параметры обычно логически разбиваются на две группы --- ключи и содержательные параметры. Содержательные параметры --- это имена объектов, строки, специальная информация. Ключи же --- это особого вида параметры, начинающиеся обычно с дефиса ("-"). В силу этого в unix-подобных системах не принято начинать названия файлов с дефиса.
Line 49: Line 72:
 ''Кстати говоря, здесь неплохо бы сказать пару слов о приглашении (о том, которое PS1), чтобы начинающиеся с символа '''$''' (а в других текстах, возможно, и с '''#''') тайпскрипты не вызывали недоумения.'' -- DmitryChistikov <<DateTime(2008-07-27T13:13:14+0400)>>
  ''Дополнение: еще раз дать ссылку вперед на пятую часть той же лекции.'' -- DmitryChistikov <<DateTime(2008-07-27T13:29:07+0400)>>
Наличие в командной строке ключей означает, что команда должна выполняться с некоторыми нюансами и изменениями. Ключ {{{-t}}} в нашем случае заставляет утилиту {{{script}}} дополнительно выводить время ({{{-t}}} --- time), содержательный же параметр {{{my_script}}} --- это имя файла, с которым, согласно нашей команде, утилита должна работать. Следует отметить, что командный интерпретатор в данном случае ничего не знает о смысле этих ключей, для него это просто две строки.
Line 52: Line 74:
Будем теперь рассматривать вместо команды script команду ls, показывающую список файлов в текущем (если не указано иного) каталоге. При выполнении некоторых специальных условий (к примеру, при наличии алиаса и соответствующего терминала --- но на этом мы останавливаться не будем) она выделяет объекты различных типов различными цветами. Это, однако, выполняется не всегда. Если вызвать команду ls не просто как "ls", а как "/bin/ls" (это полный путь к соответствующему файлу в дереве каталогов), то выделения цветом не произойдет:
Будем теперь рассматривать вместо команды {{{script}}} команду {{{ls}}} (от англ. ''list''), показывающую список файлов в текущем, если не указано иного, каталоге. При выполнении некоторых специальных условий она так же выделяет объекты различных типов различными цветами, но не всегда. Например, если вызвать команду {{{ls}}} не просто как {{{ls}}}, а как {{{/bin/ls}}} то выделения цветом не произойдет:
Line 56: Line 77:
DirDir  File Dir1 file1
Line 59: Line 80:
Обратим внимание, что отличить имя файла от имени каталога в выводе ls без раскраски невозможно. Можно, однако, указать ключ -F, который заставит ls после имен каталогов выводить символ "/". Это типичный пример использования ключа, который модифицирует работу программы. Передаваемый параметр не соответствует никакому объекту: это не файл и не имя. С этим ключом, однако, поведение программы несколько изменяется: Здесь {{{/bin/ls}}} --- это полный путь к соответствующему файлу в дереве каталогов файловой системы, а строка "Dir1 file1" --- это вывод команды {{{/bin/ls}}}, который видит пользователь.

Обратим внимание, что отличить имя файла от имени каталога в выводе ls без раскраски невозможно. Можно, однако, указать ключ {{{-F}}}, который заставит ls после имен каталогов выводить символ "/". Это типичный пример использования ключа, который модифицирует работу программы. Передаваемый параметр не соответствует никакому объекту: это не файл и не имя. С этим ключом, однако, поведение программы несколько изменяется:
Line 63: Line 86:
DirDir/ File Dir1/ file1
Line 66: Line 89:
Если указать ключ -s, то мы увидим и размер объектов. Каталог в данном случае имеет размер 4 блока, а файл --- 0 (он пуст). Если указать ключ {{{-s}}}, то мы увидим и размер объектов с точки зрения физической организации файлвовой системы. Каталог в данном случае имеет размер 4 блока, а файл --- 0 блоков (он пуст).
Line 71: Line 94:
4 DirDir/ 0 File 4 Dir1/ 0 file1
Line 74: Line 97:
Для ключей по возможности соблюдается принцип аббревиативности: вместо полных названий используется одна буква, с названием как-либо связанная. Для ключа -F эта связь неочевидна (от слова classiFy), а вот -s означает size (размер). Принцип аббревиативности нужен вот зачем: когда используется сразу несколько ключей, появляется возможность уменьшить количество набираемых символов. Например, команда "ls -F -s" и так не слишком длинная, однако ее можно еще сократить, поскольку однобуквенные ключи могут прилипать друг к другу: "ls -Fs". Мы ставим один общий минус, а дальше перечисляем все однобуквенные ключи. Достоинство однобуквенных ключей --- их быстро набирать. Недостатков у них два. Во-первых, не всегда легко запомнить значения всех ключей (смысл сокращений). Отметим, что используются в ключах как маленькие, так и большие буквы. Так, ls с ключом -a (all) показывает все объекты в текущем каталоге: Для ключей по возможности соблюдается принцип аббревиативности: вместо полных названий используется одна буква, с названием как-либо связанная. Для ключа -F эта связь неочевидна (от слова ''classiFy''), а вот -s означает size (размер). Принцип аббревиативности нужен вот зачем: когда используется сразу несколько ключей, появляется возможность уменьшить количество набираемых символов. Например, команда {{{ls -F -s}}} и так не слишком длинная, однако ее можно еще сократить, поскольку однобуквенные ключи могут прилипать друг к другу:
{{{
$
ls -Fs
ито
го 4
4 Dir1/ 0 fi
le1
}}}
Line 76: Line 104:
Мы ставим один общий дефис, а дальше перечисляем все однобуквенные ключи. Достоинство однобуквенных ключей --- их быстро набирать. Недостатков у них два. Во-первых, не всегда легко запомнить значения всех ключей (смысл сокращений). Отметим, что используются в ключах как маленькие, так и большие буквы. Так, ls с ключом {{{-a}}} (англ. ''all'') показывает все объекты в текущем каталоге:
Line 78: Line 107:
. .. DirDir File .FileFile . .. Dir1 file1 .file1
Line 81: Line 110:
Ключ же -A (almost all) заставит ls вывести "почти все" объекты: будут пропущены . и .. (они есть в любом каталоге, и информация о них нужна не всегда): Как видно, по-умолчанию утилита {{{ls}}} не показывает объекты с именами, начинающимися с точки. Здесь "." и ".." --- ссылки на каталог верхнего уровня и на текущий каталог. Ключ же -A (''almost all'') заставит вывести "почти все" объекты: будут пропущены "." и ".." (они есть в любом каталоге, и информация о них обычно не нужна):
Line 85: Line 114:
DirDir File .FileFile Dir1 file1 .file1
Line 88: Line 117:
Второй недостаток однобуквенных ключей состоит в том, что алфавит рано или поздно заканчивается и букв начинает не хватать. Когда ключей много или используются некоторые из них редко, то применяют полнословную нотацию. Ключи в этом случае начинаются с двух минусов, после которых идет полное название параметра (при этом мы не отступаем от правила, предписывающего ключам начинаться с минуса). Чаще всего однобуквенные ключи имеют полнословные эквиваленты: Второй недостаток однобуквенных ключей состоит в том, что алфавит рано или поздно заканчивается и букв начинает не хватать. Когда ключей много или используются некоторые из них редко, то применяют полнословную нотацию. Ключи в этом случае начинаются с двух дефисов, после которых идет полное название параметра (при этом мы не отступаем от правила, предписывающего ключам начинаться с дефиса). Чаще всего однобуквенные ключи имеют полнословные эквиваленты:
Line 92: Line 121:
. .. DirDir File .FileFile . .. Dir1 file1 .file1
Line 94: Line 123:
DirDir File .FileFile Dir1 file1 .file1
Line 97: Line 126:
Важно понимать, что описанные принципы работы с ключами --- это всего лишь соглашения, которые, увы, соблюдаются не всеми. Никто не мешает создать программу, с ключами не работающую вовсе или использующую другие принципы их написания. Несколько таких программ --- dd, ps, tar --- были созданы давно, когда этого соглашения не было, а потому передаваемые им параметры выглядят несколько иначе.

 ''Мне почему-то (see Wikipedia) кажется более правильным использовать термин '''дефис''' (hyphen) вместо '''минус''' в данном контексте. Возможно, следует подправить этот и некоторые другие модули.'' -- DmitryChistikov <<DateTime(2008-07-27T13:13:14+0400)>>
Важно понимать, что описанные принципы работы с ключами --- это всего лишь соглашения, которые, увы, соблюдаются не всеми и не всегда. Никто не мешает создать программу, с ключами не работающую вовсе или использующую другие принципы их написания. Несколько таких программ ({{{dd}}}, {{{ps}}}, {{{tar}}}) были созданы давно, когда этого соглашения не было, а потому передаваемые им параметры выглядят несколько иначе.
Line 107: Line 134:
|| 55 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || || 90 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || ||

Принципы человеко-машинного взаимодействия в GNU/Linux

Парадигмы GNU/Linux

С точки зрения изучения системы GNU/Linux, излишняя привязка к конкретной графической среде весьма сомнительна по следующим причинам:

  • во-первых, графическая оболочка сама по себе не дает понимания, "что такое Линукс" как операционная система;
  • во-вторых, может наступить момент, когда придется переходить на другую графическую среду, с другими принципами организации: только самых распространенных сред --- три (KDE, Gnome, XFCE);
  • в-третьих, существует целый класс задач системного администрирования, решаемых с интенсивным использованием командной строки.

Ответим теперь на вопрос: что же такое GNU/Linux (или, неформально, "Линукс")? Мы уже отметили, что это, в первую очередь, свободный программный продукт, разрабатываемый множеством сообществ разработчиков. Однако, это ответ с точки зрения процесса разработки и он неполон. Ответ на этот вопрос можно получить, рассмотрев базовые принципы человеко-машинного взаимодействия в GNU/Linux. Человек должен не просто управлять компьютером, а обладать инструментом для решения (и изобретения решения) любой задачи. Сформулируем теперь ключевое утверждение: GNU/Linux --- это свободная операционная система, то есть комплекс программных средств, обеспечивающий унификацию, разделение и разграничение ресурсов для пользовательских программ, которая базируется на следующих трех принципах.

  1. "Все --- файл". Для управления операционной системой и GNU/Linux и ее системными сервисами используются файлы. Таким образом, одним из центральных объектов нашего изучения становится файловая система (ФС). Заметим, что этот термин может означать как способ хранения файлов на диске (физическая организация), так и способ представления файлов для пользователя (логическая организация). Речь в данном случае идет, разумеется, о втором из значений. С достаточной степенью точности можно считать, что с точки зрения пользователя файловая система состоит из выстроенных в древовидную структуру каталогов и файлов. Организация файловой системы в GNU/Linux стандартизована и вполне умопостижима --- разобраться, что где лежит и для чего нужно обыкновенно не составляет труда.

  2. "Все --- текст". Файлы, требующие ручной или автоматической модификации, --- текстовые. С точки зрения пользователя, структура файловой системы (являющаяся некоторой проекцией всей ОС) представляется в виде дерева файлов, причем в файлах конфигурации информация хранится в пригодном для чтения и изменения человеком текстом виде. Файлы, не предназначенные для непосредственого чтения и модификации пользователем, могут быть бинарными, например к ним относятся программы в бинарном и библиотеки в откомпилированном виде.

  3. Управление системой есть работа со набором специальных инструментов, манипулирующим текстовыми файлами (строго говоря, файлами и текстом вообще). Сам инструмент также не выходит за рамки парадигмы "файл --- текст": человек и машина обмениваются текстами, в результате чего модифицируются файлы. Следствием данного принципа является то, что основным интерфейсом управления GNU/Linux является интерфейс командной строки. Понятно, что он очень хорошо подходит для описанной парадигмы: пользователь набирает текстовые команды, компьютер команды интерпретирует, исполняет и в качестве результата выдает обратно текст.

Следует отметить, что все сказанное выше относится к любой Unix-подобной операционной системе вообще, поскольку известная расшифровка аббревиатуры GNU как GNU is Not Unix касалась только несвободной природы UNIX в 80-ые годы, но не ее принципов как операционной системы.

Безусловно, существуют выходящие за рамки описанной парадигмы пользовательские задачи. Заметим, однако, что речь в данном случае идет об управлении операционной системой как таковой. Чтобы пользоваться компьютером как точкой запуска интернет-браузера, аудиоплеера и почтового клиента, не обязательно разбираться во всех тонкостях: все нужные приложения легко найти в меню графической среды пользователя. Если же мы захотим изучать GNU/Linux как операционную систему, то разумно пользоваться следующей схемой. Допустим, мы хотим решить какую-то задачу управления системой, а инструментов перед собой видим недостаточно: у нас есть микроскоп, а нам нужно забить девятнадцать гвоздей. Не следует пытаться решить задачу имеющимися инструментами: как максимум, можно один гвоздь забить микроскопом, чтобы убедиться в нецелесообразности такого подхода. Вместо этого имеет смысл изучить содержимое ящика с инструментами, выбрать из этих инструментов подходящий (молоток) и в дальнейшем пользоваться для забивания гвоздей именно им.

Иными словами, если решение задачи представляется малоэффективным, то это вероятно значит, что используется плохо подходящий инструмент: нужный инструмент попросту не найден или же недостаточно освоен. GNU/Linux предоставляет очень богатый инструментарий, позволяющий пользователю при необходимости объединять имеющиеся инструменты в более сложные. Чтение в таких ситуациях документации позволяет накопить багаж знаний, достаточных для решения всех своих, в том числе довольно изощренных, задач.

Основы использования командной строки

Расскажем теперь об интерфейсе командной строки чуть более формально. Этот интерфейс на самом деле предоставляется специальной программой --- интерпретатором командной строки, называемого также командной оболочкой или "шеллом" (англ. unix shell). Другими словами, это не само ядро Linux с нами "разговаривает", а специальный пользовательский процесс --- один из запускаемых при входе пользователя в систему. По умолчанию это запущенный файл /bin/bash. Чем занимается эта программа? Она читает то, что мы вводим с клавиатуры, анализирует, выполняет соответствующие задачи и выводит результаты --- как свои, так и других программ --- в виде текста. При использовании графической среды для запуска командного интерпретатора следует выбрать пункт Терминал из меню. При использовании среды KDE (Юниор, Мастер) это выглядит так:

../ui_cli_konsole1.png

Команды для выполнения командной оболочкой могут как вводится с клавиатуры, так и браться из файла, называемого командным сценарием или "скриптом" (англ. shell script). Команды не обязательно исполняются последовательно --- на самом деле командная оболочка является интерпретатором специализированного языка программирования! Отметим, что данная парадигма реализуется не только командной оболочкой: подобный интерфейс имеют, скажем, интерпретатор языка программирования Python, клиент базы данных MySQL и другие программы.

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

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

Вначале введем некоторые общепринятые соглашения. Команда следует после символа "$", который пользователь в видит в конце приглашения к вводу при использовании командного интерпретатора. Например, запись

$ ls

означает, что следует ввести ls и нажать Enter. Если же для выполнения команды должно происходить от лица суперпользователя (root), то перед командной будет выводится символ "#", которым заканчивается приглашение к вводу для пользователя root. Таким образом, команды

$ su -
# service network restart

означают выполнение команды переключения пользователей su с параметром "-" (система запросит пароль суперпользователя) и выполнение команды service с параметрами network и restart с праваими суперпользователя.

Рассмотрим следующую команду:

$ #script -t my_script 2> my_script.time

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

$ script -t my_script 2> my_script.time

Каким образом будет разобрана такая команда? Интерпретатор выделит имя команды ("script") и два параметра ("-t" и "my_script"). Cлово "2>" в данном случае параметром команды не является: оно содержит символ "больше" (">") и является указанием интерпретатору выполнять перенаправление вывода сообщений об ошибках в файл my_script.time. К моменту запуска команды это слово будет уже обработано интерпретатором (можно считать, что с точки зрения команды script соответствующая группа символов просто исчезнет).

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

  • Командный интерпретатор определяет, что за команда была введена (в данном случае это script). В командном интерпретаторе есть небольшой набор встроенных (built-in) команд --- чтобы их выполнить, не нужно запускать отдельных программ (хорошим примером является команда cd, изменяющая текущий каталог). Если команда является встроенной, то она будет выполнена самим интерпретатором, в противном же случае он по специальному алгоритму будет вначале искать в файловой системе программу с таким именем.

  • Командный интерпретатор просматривает строку и ищет в ней специальные управляющие символы. Ранее, когда шла речь об обыкновенных символах и разделителях, мы намеренно допустили некоторую неточность. На самом деле есть и третий тип символов --- управляющие. После того, как интерпретатор находит управляющие символы, он их обрабатывает в соответствии с их значением. В данном случае стандартный вывод (поток) ошибок утилиты script перенаправляется не на терминал, а в файл (сама утилита script этого даже не заметит, если не будет специально "присматриваться").

  • После того, как вывод будет перенаправлен, этот фрагмент строки будет считаться обработанным ("удалится"), а утилита script будет запущена с двумя параметрами.

Чем же занимается утилита script? Оказывается, она протоколирует все действия, производимые пользователем: записывает в специальный файл вводимые команды и получаемые результаты. Именно эта утилита и использовалась для написания наших примеров.

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

Наличие в командной строке ключей означает, что команда должна выполняться с некоторыми нюансами и изменениями. Ключ -t в нашем случае заставляет утилиту script дополнительно выводить время (-t --- time), содержательный же параметр my_script --- это имя файла, с которым, согласно нашей команде, утилита должна работать. Следует отметить, что командный интерпретатор в данном случае ничего не знает о смысле этих ключей, для него это просто две строки.

Будем теперь рассматривать вместо команды script команду ls (от англ. list), показывающую список файлов в текущем, если не указано иного, каталоге. При выполнении некоторых специальных условий она так же выделяет объекты различных типов различными цветами, но не всегда. Например, если вызвать команду ls не просто как ls, а как /bin/ls то выделения цветом не произойдет:

$ /bin/ls
Dir1 file1

Здесь /bin/ls --- это полный путь к соответствующему файлу в дереве каталогов файловой системы, а строка "Dir1 file1" --- это вывод команды /bin/ls, который видит пользователь.

Обратим внимание, что отличить имя файла от имени каталога в выводе ls без раскраски невозможно. Можно, однако, указать ключ -F, который заставит ls после имен каталогов выводить символ "/". Это типичный пример использования ключа, который модифицирует работу программы. Передаваемый параметр не соответствует никакому объекту: это не файл и не имя. С этим ключом, однако, поведение программы несколько изменяется:

$ ls -F
Dir1/  file1

Если указать ключ -s, то мы увидим и размер объектов с точки зрения физической организации файлвовой системы. Каталог в данном случае имеет размер 4 блока, а файл --- 0 блоков (он пуст).

$ ls -F -s
итого 4
4 Dir1/  0 file1

Для ключей по возможности соблюдается принцип аббревиативности: вместо полных названий используется одна буква, с названием как-либо связанная. Для ключа -F эта связь неочевидна (от слова classiFy), а вот -s означает size (размер). Принцип аббревиативности нужен вот зачем: когда используется сразу несколько ключей, появляется возможность уменьшить количество набираемых символов. Например, команда ls -F -s и так не слишком длинная, однако ее можно еще сократить, поскольку однобуквенные ключи могут прилипать друг к другу:

$ ls -Fs
итого 4
4 Dir1/  0 file1

Мы ставим один общий дефис, а дальше перечисляем все однобуквенные ключи. Достоинство однобуквенных ключей --- их быстро набирать. Недостатков у них два. Во-первых, не всегда легко запомнить значения всех ключей (смысл сокращений). Отметим, что используются в ключах как маленькие, так и большие буквы. Так, ls с ключом -a (англ. all) показывает все объекты в текущем каталоге:

$ ls -a
.  ..  Dir1  file1  .file1

Как видно, по-умолчанию утилита ls не показывает объекты с именами, начинающимися с точки. Здесь "." и ".." --- ссылки на каталог верхнего уровня и на текущий каталог. Ключ же -A (almost all) заставит вывести "почти все" объекты: будут пропущены "." и ".." (они есть в любом каталоге, и информация о них обычно не нужна):

$ ls -A
Dir1  file1  .file1

Второй недостаток однобуквенных ключей состоит в том, что алфавит рано или поздно заканчивается и букв начинает не хватать. Когда ключей много или используются некоторые из них редко, то применяют полнословную нотацию. Ключи в этом случае начинаются с двух дефисов, после которых идет полное название параметра (при этом мы не отступаем от правила, предписывающего ключам начинаться с дефиса). Чаще всего однобуквенные ключи имеют полнословные эквиваленты:

$ ls --all
.  ..  Dir1  file1  .file1
$ ls --almost-all
Dir1  file1  .file1

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


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

90

1

1

1

1

ConstantinYershow, DmitryChistikov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080717/03ConsoleBasics (last edited 2009-03-22 18:52:24 by eSyr)