Различия между версиями 3 и 5 (по 2 версиям)
Версия 3 от 2008-07-22 00:59:45
Размер: 23482
Редактор: ConstantinYershow
Комментарий:
Версия 5 от 2008-07-26 12:26:56
Размер: 23499
Редактор: DmitryChistikov
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 3: Строка 3:
Прилепляться к конкретной графической оболочке не стоит по следующим причинам:
 * вы не поймёте, что такое линукс
 * в какой-то момент вам, возможно, прийдётся перейти на другую графическую оболочку
Излишняя привязка к конкретной графической оболочке --- дело весьма сомнительное:
 * во-первых, графическая оболочка сама по себе не дает понимания, "что такое Линукс";
 * во-вторых, может наступить момент, когда придется переходить на другую графическую оболочку, с другими принципами организации.
Строка 7: Строка 7:
Для начала, надо ответить на вопрос - в таком случае, что же такое линукс? Из вчерашнего разговора мы знаем, что линукс в первую очередь - сообщество, то, что мы видим - результат работы сообщества, причём эти люди частично между собой сговаривались, а частично каждый это делал для себя. Но эт' не ответ на вопрос. Когда лектор говорит о том, что линукс должен отвечать задачам ОС, о чём он говорит, если всё это являестя пользовательскими приложениями? Тут можно потеоретизировать на тему человек-машинного взаимодействия (см. первые лекции последнего семестра). То есть, есть человек, есть компьютер, человек должен управлять компьютером, и наша задача - не просто научить человека управлять компьютером, а дать ему в руки инструмент для изобретения любого решения. Лектор хочет оставить это место бездоказательным и начать сразу с утверждения. Линукс как ОС, как некий комплекс програмных средств, обеспечивающий унификацию, разделение и разграничение ресурсов для пользовательских программ, базируется на трёх принципах: Ответим наконец на вопрос: что же такое Линукс? Мы уже знаем, что Линукс это в первую очередь сообщество, а то, что мы видим, --- результат работы сообщества. Но это не ответ на вопрос. Понятно, что Линукс должен отвечать перечисленным требованиям к ОС, но ведь пока мы видели лишь пользовательские приложения? Ответ базируется на принципах человеко-машинного взаимодействия. Человек должен не просто управлять компьютером, а обладать инструментом для решения (и изобретения решения) любой задачи. Сформулируем теперь ключевое утверждение: Линукс как ОС (комплекс программных средств, обеспечивающий унификацию, разделение и разграничение ресурсов для пользовательских программ), базируется на трех принципах:
Строка 9: Строка 9:
 * Любые системные объекты, которые требуется как-то модифицировать, чтобы управлять системой и приложениями - это файлы. Никаких тинственных кнопок, никаких рабочих столов нет. Оно всё взаимозаменяеме. Что есть - есть файловая сситема, состоящая из каталогов и файлов, и структура файловой системы в линуксе весьма стандартизвана и умопостижима, то есть в ней легко разобраться, что где и для чего нужно. У термина файловая система, замечает лектор, есть два значения: 1) способ хранения файлов на диске и 2) способ представления файлов для пользователя; здесь говорится о втором.
 * Файлы, если они требуют модификации со стороны пользователя или автоматической модификации, должны быть текстовыми, то есть, если превый принцип коротко формулируется как "всё файл", то второй формулируется "всё текст". То есть, с точки зрения пользователя, структура ОС представляется в виде дерева файлов, в каждом из которых хранится какая-то информация, которую можно глазами прочитать. Исключение составляют файлы, которые не предназаначены для чтения и модификации пользователем - программы (те, которые в бинарном виде), библиотеки... Любые другие файлы должны быть по возможности текстовые.
 * Третий принцип состоит в том, каким образом организуется человекомашинное взаимодействие, то есть как человек управляет компьютером если все объекты его управления есть, грубо говоря, текствые файлы, лежащие в каталогах. В этм случае инструмент управления должен работать а) с файлами и б) с текстом, в сумме, с текстовыми файлами. Что это за инструмент? При этом сам инструмент должен быть так организован, чтобы он не выходил из рамок парадигмы файл-текст: челвек и машина должны обмениваться текстами, и в результате этого должны модифицироваться файлы. Неким следствием этого принципа будет то, что основным интерфейсом управления unix-подобной системы в этй парадигме является интерфейс командной строки. В любом случае (то есть, даже если лектор не доказывает его преимущество) очевидно, что он очень подходит для этой парадигмы: вы набираете текстовые команды, компьютер команды интерпретирует (т.е. разбирает этот текст на части, чтобы понять, чего вы ему скомандовали), исполняет и в качестве результата выдаёт обратно текст.
 1. "Все --- файл". Любые системные объекты, использующиеся для управления этой самой системой, приложениями и их взаимодействием --- файлы. "Таинственные" кнопки, рабочие столы --- все взаимозаменяемо. Таким образом, одним из центральных объектов нашего изучения становится файловая система (ФС). Заметим, что у этого термина два основных значения: (1) способ хранения файлов на диске и (2) способ представления файлов для пользователя. Речь в данном случае идет, разумеется, о втором значении. С достаточной степенью точности можно считать, что ФС состоит из выстроенных в древовидную структуру каталогов и файлов. Собственно структура ФС в Линуксе стандартизована и умопостижима --- разобраться, что, где и для чего нужно, обыкновенно не составляет труда.
 2. "Все --- текст". Файлы, если они требуют ручной или автоматической модификации, --- текстовые. С точки зрения пользователя, структура ФС (и, в некотором смысле, всей ОС!) представляется в виде дерева файлов, в каждом из которых хранится информация в пригодном для чтения человеком виде. Исключение составляют файлы, не предназначенные для чтения и модификации пользователем: программы в бинарном виде, библиотеки и пр.
 3. Управление системой есть работа со специальным инструментом, манипулирующим текстовыми файлами (строго говоря, файлами и текстом вообще). Сам инструмент также не выходит за рамки парадигмы "файл --- текст": человек и машина обмениваются текстами, в результате чего модифицируются файлы. Следствием данного принципа является то, что основным интерфейсом управления Линуксом (на самом деле, Unix-подобной системы вообще) является интерфейс командной строки. Понятно, что он очень хорошо подходит для описанной парадигмы: пользователь набирает текстовые команды, компьютер команды интерпретирует, исполняет и в качестве результата выдает обратно текст.
Строка 13: Строка 13:
Понятно, что задачи могут выходить за рамки этого, но сейчас мы говорим не о пользовательских задачах, а об управлении системой как таковой. Лектор сразу говорит, что подробнее об этом можно прочитать в книжке МК, она почти полностью этому посвящена, там тоже есть далеко не всё, тема обширная и её необязательно всю охватывать разумом, если вы хотите познакомиться с линуксом. Её необязательно всю охватывать разумомесли вы не собираетесь пользоваться машиной больше чем точкой для интернет-браузера, точкой для прослушивания музыки и почтовым клиентом - все пункты есть в меню. А вот если вы пытаетесь линукс изучать, вам опять-таки не следует пытаться охватывать всё это разом, а пользоваться таким алгоитмом: если вы хотите решить задачу, для которой у вас недостаточно инструментов (например, у вас есть микроскоп и надо забить девятнадцать гвоздей), не пытайтесь решить задачу имеющимися инструментами (не пытайтесь все девятнадцать гвоздей забить микроскопом, ну один гвоздь разрешается забить микроскопом - чтобы убедиться, что так делать не надо), а изучите, какой интструментарий предоставляет линукс под это дело, выберите подходящий молоток и дальше получайте своё удовольтвие с молотком. Если убрать все иносказания: если вы чувствуете, что решение задаи неэффективно, это значит,что вы просто не знаете нужного инструмента. Ищите инструмент. У линукса очень богатый инструментарий, и, скорее всего, инструмент для решения вашей задачи тоже есть, только вы его ещё не освоили. В результате окажется, что, честно читая документацию в подобных случаях вы накопили багаж знаний, достаточный для решения всех своих, в том числе довольно изощрённых задач, и вам уже прямая дорога в гуру. Нетрудно понять, что существуют выходящие за рамки описанной парадигмы пользовательские задачи. Заметим, однако, что речь в данном случае идет об управлении системой как таковой. Чтобы пользоваться компьютером как точкой запуска Интернет-браузера, аудиоплеера и почтового клиента, не обязательно разбираться во всех тонкостях: все нужные приложения легко найти в меню. Если же мы захотим изучать Линукс как операционную систему, то разумно пользоваться следующей схемой. Допустим, мы хотим решить задачу, а инструментов перед собой видим недостаточно: у нас есть микроскоп, а нам нужно забить девятнадцать гвоздей. Не следует пытаться решить задачу имеющимися инструментами (как максимум --- один гвоздь забить микроскопом, чтобы убедиться в нецелесообразности такого подхода). Вместо этого имеет смысл пошарить в ящике с инструментами, выбрать подходящий (молоток) и в дальнейшем пользоваться (именно для забивания гвоздей!) именно им. Иными словами, если решение задачи представляется малоэффективным, то это значит, что используется плохо подходящий инструмент. ОС Линукс предоставляет очень богатый инструментарий, так что скорее всего, нужный инструмент попросту не найден или недостаточно освоен. Чтение в случае необходимости пользовательской документации позволяет накопить багаж знаний, достаточных для решения всех своих, в том числе довольно изощренных, задач.
Строка 15: Строка 15:
Чуть более формально о том, что такое интерфейс командной строки. Мы все знаем, что есть программа, шелл, интерпретатор командной строки. То есть не просто линукс с вами разговаривает, а при логине запускается много процессов, один из них - специальная прграмма, в задачи которй входит реализация интерфейса командной строки по управлению линуксом. Именно эта программа читает то, что вы вводите с клавиатуры, анализирует, выполняет соответствующие задачи, выводит результаты (свои или других программ) в виде текста. Существует несколько программ, реализующих эту парадигму, не только шелл, но и, например, клиент mysql, python. То есть, идея, что человек сидит за клавиатурой, даёт текстовую команду, эта команда исполняется, результат выводится на экран, она эксплуатировалась много раз с тех пор, как изобрели шелл. Расскажем теперь об интерфейсе командной строки чуть более формально. Этот интерфейс на самом деле предоставляется специальной программой --- Shell'ом, или интерпретатором командной строки. Другими словами, это не Линукс с нами "разговаривает", а специальный процесс --- один из запускаемых при логине (входе в систему). Чем занимается эта программа? Она читает то, что мы вводим с клавиатуры, анализирует, выполняет соответствующие задачи и выводит результаты --- как свои, так и других программ --- в виде текста. Отметим, что данная парадигма реализуется не только Shell'ом: подобный интерфейс имеют, скажем, интерпретатор языка программирования python, клиент базы данных mysql.
Строка 17: Строка 17:
Как выглядит команда, которую вы даёте шеллу: команды вводятся построчно, строка разбивается на слова по принципу: последовательности любых симвлов, подряд идущие и не являющиеся разделителями - это слово, а последовательности разделителей - это не слово, а промежуток между словами. Разделители - это пробел, символ табуляции и символ перевода строки (хотя заставить шелл воспринимать последний как разделитель довольно тяжело: перевод строки - управляющая клавиша, и, нажимая её, шеллу передаётся вся строчка целиком). Итак, строка, которую вы вводите, разбирается на слова, первое слово - команда, остальные слова - параметры этой команды. Надо понять, откуда это взникло. Можно было конечно придумать на каждый случай жизни специадльную команду (нарисовать розовую мышку - одна кманда, нарисовать голубую мышку - другая команда, и так далее). Но понятно, что слова быстро кончатся и команды станут выглядеть совсем ужасно, кроме того, запоминать это будет невозможно. Поэтму при работе с командной строкой осуществляется следующий принцип - команда, которая, по сути говоря, утилита, решает некоторую пользовательскую подзадачу, и все параметры (файлы, нюансы работы) передются в виде следующих слов. Пример - то, что мы видим на экране - это команда script с двумя параметрами. Последнее слово по причине того, что шелл его обработал, не является параметром команды script. Наличие символа > - это перенаправление вывода, это значит, что к тому моменту, когда команда запустится, этой группы символов уже не будет. Как же выглядит подаваемая Shell'у команда? Обыкновенно команды вводятся построчно, каждая строка разбивается на слова в соответствии со следующим простым правилом: последовательность любых символов, идущих подряд и не являющихся разделителями --- это слово, а последовательность разделителей --- это не слово, а промежуток между словами. Разделители --- это пробел, символ табуляции и символ перевода строки. (Заметим, что заставить Shell воспринимать символ перевода строки как разделитель довольно непросто: перевод строки --- это управляющая клавиша, поэтому при ее нажатии Shell'у передается вся набранная строка, которую он воспринимает как законченную команду.)

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

Рассмотрим следующую команду:
Строка 23: Строка 27:
Здесь - пример того, как люди используют историю как записную книжку. Решётка вначале означает комментарий. Эта команда не выполнилась. Но она сохранилась в истории. Это пример того, как люди используют список введенных ими команд ("историю") в качестве записной книжки. Дело в том, что введенная в начале строки решетка является специальным символом, обозначающим комментарий. Эта команда была лишь введена, но не выполнена, однако при этом она попала в историю введенных команд (ее, разумеется, можно просматривать).
Строка 25: Строка 29:
Фактически, диалог пользователя и системы при помощи командной строки происходит следующим образом. Пользователь набирает команду в командной строке, шелл обрабатывает строку, в данном случае он смотрит в два места:
 * Он определяет, что это за команда такая script. Есть небольшой набор встроенных в шелл команд (например cd - встроенная команда, потому что нельзя поменять текущий каталог в другой программе). Если команда встроенная, всё хорошо, если нет, шелл ищет по специальному алгоритму, нет ли где утилиты с таким названием.
 * Ещё до этого шелл обрабатывает строку на наличие спецсимволов (когда лектор говорил, что есть два вида символов, он немножко покривил душой: на самом деле, там есть третий тип - управляющие символы). В данном случае, шелл нашёл управляющий символ >, который означает перенаправление вывода. То есть, весь текст, который должен был выходить на стандартный вывод ошибок, был перенаправлен шеллом в файл 1.script.time. После того, как он находит управляющие символы, он их обрабатывает, в данном случае, при запуске команды script вывод ошибок будет перенаправлен не на терминал, а в файл. Более того, script этго даже не заметит, если специально не будет к этому присматриваться. После того, как будет перенаправлен вывод, этот кусок строки удалится из командной строки, и script будет запущен с двумя параметрами.
Каким образом эта команда была разобрана? Если бы символа комментария в начале строки не стояло, интерпретатор выделил бы имя команды ("script") и два параметра ("-t" и "1.script"). В данном случае последнее введенное слово параметром команды не является: оно содержит символ "больше" (">") и является указанием Shell'у выполнять перенаправление вывода. К моменту запуска команды это слово было бы уже обработано интерпретатором (для простоты можно считать, что эта группа символов просто исчезнет).
Строка 29: Строка 31:
По этому примеру видно ещё одно: среди параметров есть параметры двух видов: ключи и содержательные параметры. Содержательные параметры - имена объектов, строки, какая-то информация, которая может быть разной. Ключи - специального вида параметры, они обычно начинаются на -, наличие которых в командной строке означает, что команда будет выполняться примерно также, но с некоторыми нюансами. Например, -t заставляет команду script выводить время, а 1.script - содержательный параметр - имя файла, с которым команда будет работать. Фактически, диалог пользователя и системы при помощи командной строки происходит следующим образом. Пользователь набирает команду в командной строке, Shell эту строку обрабатывает. Обратим внимание на два этапа обработки:
Строка 31: Строка 33:
Во всей этой замечательной нашей речи мы опустили одно: что же делает команда script. Она протоколирует все действия, то есть откладывает в файл и команды, которые мы выводим, и результат, который мы получаем. Нужна для того, чтобы писать примеры.  * Shell определяет, что за команда была введена (в данном случае --- script). Есть небольшой набор встроенных в Shell команд (к примеру, cd, изменяющая текущий каталог). Если команда является встроенной, то с ней все ясно, в противном же случае Shell по специальному алгоритму ищет утилиту (программу) с таким названием (именем).
Строка 33: Строка 35:
Давайте вместо команды script будем использовать команду ls, которая показывает список файлов в текущем каталоге. В частности, если звёзды сложились удачно (при наличии алиаса и сответствующего терминала), то она будет все объекты цветом выделять. Но это необязательно. Если вызвать /bin/ls, то раскраски не будет.  * Shell обрабатывает строку на наличие специальных управляющих символов. Когда ранее шла речь об обыкновенных символах и разделителях, была допущена некоторая неточность: есть и третий тип символов --- управляющие. После того, как Shell находит управляющие символы, он их обрабатывает в соответствии с их значением. В данном случае стандартный вывод (поток) ошибок утилиты script перенаправляется не на терминал, а в файл. Сама утилита script этого даже не заметит, если не будет специально "присматриваться". После того, как вывод будет перенаправлен, этот фрагмент строки будет считаться обработанным ("удалится"), а утилита script будет запущена с двумя параметрами.

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

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

Будем теперь рассматривать вместо команды script команду ls, показывающую список файлов в текущем (если не указано иного) каталоге. При выполнении некоторых специальных условий (к примеру, при наличии алиаса и соответствующего терминала --- но на этом мы останавливаться не будем) она выделяет объекты различными цветами. Это, однако выполняется не всегда. Если вызвать команду ls не просто как "ls", а как "/bin/ls" (это полный путь к соответствующему файлу в дереве каталогов), то выделения цветом не произойдет:
Строка 36: Строка 45:
DirDir File DirDir  File
Строка 38: Строка 47:
Обратите внимание, что если просто выводить названия файлов и каталогов на экран, непонятно, кто из них каталог, а кто файл. Есть ключ -F, который после каталога рисует "/", чтобы мы видели, что это каталог. Вот типичный пример работы ключа, который модифицирует работу программы. Тот параметр, который вы передаёте, никакому объекту не соответствует: это не файл, ни имя; лектор даже затрудняется сказать, что означает буква F. Зато с этим ключом несколько изеняется поведение программы.
Обратим внимание, что отличить имя файла от имени каталога в выводе ls без раскраски невозможно. Можно, однако, указать "ключ" -F, который после имен каталогов будет рисовать символ "/". Это типичный пример использования ключа, который модифицирует работу программы. Передаваемый параметр не соответствует никакому объекту: это не файл и не имя. С этим ключом, однако, поведение программы несколько изменяется:
Строка 43: Строка 54:
Если указать -s, то можно увидеть ещё и размер объектов. Каталог здесь имеет размер 4 блока, а файл 0, потому что он пустой.
Если указать ключ -s, то мы увидим и размер объектов. Каталог в данном случае имеет размер 4 блока, а файл --- 0 (он пуст).
Строка 49: Строка 62:
Для ключей соблюдается(по возможности) принцип аббревиативности - вместо полных назхваний ключей используется одна буква, с ним как-то связанная. С ключом -F эта связь неочевидна (от слова classiFy),  а вот -s означает size. Принцип аббревиативности нужен вот зачем: когда вы используете много разных ключей, вам нужно меньше нажимать на клавиатуру. Например, команда ls -F -s и так небольшая, но её можно ещё сократить, поскольку однобуквенные ключи могут прилипать друг к другу: ls -Fs. Мы ставим один общий минус, а дальше перечисляем все однобуквенные ключи. Достинсмтво однобуквенных ключей - их быстро набирать. Недостатков два: во-первых, их надо помнить. Это при том, что заняты и большие, и маленькие буквы. Например, ключ -a (all) показывает все объекты в директории.
Для ключей по возможности соблюдается принцип аббревиативности: вместо полных названий ключей используется одна буква, с ним как-то связанная. Для ключа -F эта связь неочевидна (от слова classiFy), а вот -s означает size (размер). Принцип аббревиативности нужен вот зачем: когда используется сразу несколько ключей, появляется возможность уменьшить количество набираемых символов. Например, команда "ls -F -s" и так не слишком длинная, однако ее можно еще сократить, поскольку однобуквенные ключи могут прилипать друг к другу: "ls -Fs". Мы ставим один общий минус, а дальше перечисляем все однобуквенные ключи. Достоинство однобуквенных ключей --- их быстро набирать. Недостатков у них два. Во-первых, их надо помнить. Заняты при этом как маленькие, так и большие буквы. Ключ -a (all) показывает все объекты в текущем каталоге:
Строка 54: Строка 69:
Ключ -A (almost all) выводит почти все объекты, за исключением . и .. которые есть в любом каталоге, и смотреть на них совершенно необязательно.
Ключ -A (almost all) выводит все объекты, за исключением . и .. (они есть в любом каталоге, и смотреть на них, возможно, нам неинтересно):
Строка 59: Строка 76:
Во-вторых, через некоторое время алфавит заканчивается. Когда ключей много или кни используются редко, то используется полнословная нотация, когда ключи начинаются с двух минусов (тем самым мы не отступаем от правила, что ключи начинаются на минус), и тогда идёт полное название параметра.
Второй недостаток однобуквенных ключей состоит в том, что алфавит рано или поздно заканчивается и букв начинает не хватать. Когда ключей много или используются некоторые из них редко, то применяют полнословную нотацию. Ключи в этом случае начинаются с двух минусов (тем самым мы не отступаем от правила, что ключи начинаются на минус), после которых идет полное название параметра. Чаще всего однобуквенные ключи имеют полнословные эквиваленты:
Строка 66: Строка 85:
Надо учитиывать, что это соглашения, и они могут не выполняться, то есть никто вам не мешает написать программу, которая не будет работать с ключами. Есть несколько таких программ (dd, ps, tar), они были написаны давно, когда этого соглашения не было.
Важно понимать, что описанные принципы работы с ключами --- это всего лишь соглашения, которые, увы, соблюдаются не всеми. Никто не мешает написать программу, с ключами не работающую вовсе или использующую другие принципы их написания. Несколько таких программ --- dd, ps, tar --- были написаны давно, когда этого соглашения не было, и потому этим правилам (частично или полностью) не подчинаются.
Строка 74: Строка 94:
|| 20 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || || 40 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || ||

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

Излишняя привязка к конкретной графической оболочке --- дело весьма сомнительное:

  • во-первых, графическая оболочка сама по себе не дает понимания, "что такое Линукс";
  • во-вторых, может наступить момент, когда придется переходить на другую графическую оболочку, с другими принципами организации.

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

  1. "Все --- файл". Любые системные объекты, использующиеся для управления этой самой системой, приложениями и их взаимодействием --- файлы. "Таинственные" кнопки, рабочие столы --- все взаимозаменяемо. Таким образом, одним из центральных объектов нашего изучения становится файловая система (ФС). Заметим, что у этого термина два основных значения: (1) способ хранения файлов на диске и (2) способ представления файлов для пользователя. Речь в данном случае идет, разумеется, о втором значении. С достаточной степенью точности можно считать, что ФС состоит из выстроенных в древовидную структуру каталогов и файлов. Собственно структура ФС в Линуксе стандартизована и умопостижима --- разобраться, что, где и для чего нужно, обыкновенно не составляет труда.
  2. "Все --- текст". Файлы, если они требуют ручной или автоматической модификации, --- текстовые. С точки зрения пользователя, структура ФС (и, в некотором смысле, всей ОС!) представляется в виде дерева файлов, в каждом из которых хранится информация в пригодном для чтения человеком виде. Исключение составляют файлы, не предназначенные для чтения и модификации пользователем: программы в бинарном виде, библиотеки и пр.
  3. Управление системой есть работа со специальным инструментом, манипулирующим текстовыми файлами (строго говоря, файлами и текстом вообще). Сам инструмент также не выходит за рамки парадигмы "файл --- текст": человек и машина обмениваются текстами, в результате чего модифицируются файлы. Следствием данного принципа является то, что основным интерфейсом управления Линуксом (на самом деле, Unix-подобной системы вообще) является интерфейс командной строки. Понятно, что он очень хорошо подходит для описанной парадигмы: пользователь набирает текстовые команды, компьютер команды интерпретирует, исполняет и в качестве результата выдает обратно текст.

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

Расскажем теперь об интерфейсе командной строки чуть более формально. Этот интерфейс на самом деле предоставляется специальной программой --- Shell'ом, или интерпретатором командной строки. Другими словами, это не Линукс с нами "разговаривает", а специальный процесс --- один из запускаемых при логине (входе в систему). Чем занимается эта программа? Она читает то, что мы вводим с клавиатуры, анализирует, выполняет соответствующие задачи и выводит результаты --- как свои, так и других программ --- в виде текста. Отметим, что данная парадигма реализуется не только Shell'ом: подобный интерфейс имеют, скажем, интерпретатор языка программирования python, клиент базы данных mysql.

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

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

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

#script -t 1.script 2>1.script.time

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

Каким образом эта команда была разобрана? Если бы символа комментария в начале строки не стояло, интерпретатор выделил бы имя команды ("script") и два параметра ("-t" и "1.script"). В данном случае последнее введенное слово параметром команды не является: оно содержит символ "больше" (">") и является указанием Shell'у выполнять перенаправление вывода. К моменту запуска команды это слово было бы уже обработано интерпретатором (для простоты можно считать, что эта группа символов просто исчезнет).

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

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

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

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

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

$ /bin/ls
DirDir  File

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

$ ls -F
DirDir/  File

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

$ ls -F -s
итого 4
4 DirDir/  0 File

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

$ ls -a
.  ..  DirDir  File  .FileFile

Ключ -A (almost all) выводит все объекты, за исключением . и .. (они есть в любом каталоге, и смотреть на них, возможно, нам неинтересно):

$ ls -A
DirDir  File  .FileFile

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

$ ls --all
.  ..  DirDir  File  .FileFile
$ ls --almostr-all
DirDir  File  .FileFile

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

40

1

1

1

1

ConstantinYershow, DmitryChistikov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080717/03ConsoleBasics (последним исправлял пользователь eSyr 2009-03-22 21:52:24)