Командная строка
Прежде чем мы начнем смотреть в экранчик, давайте вспомним главный пафос нашей прошлой встречи. Я показал некоторое количество разных дистрибутивов, в основном это были дистрибутивы из нашей инструментальной линейки. Эти дистрибутивы оформлены как Live CD, их можно скачивать и запускать. И мы посмотрели на разное количество всяких разных организаций рабочего стола и убедились в том, что все линуксы разные и изучать их имеет смысл, только если вы собираетесь работать с каким-то из них длительное время. Соответственно, возник вопрос: что именно нужно рассматривать в качестве инвариантов - вещей, которые стоит изучать не на скорую руку, а вообще - то, в чем собираешься разбираться.
Мы таких инвариантов нашли несколько:
- Вопрос выбора интерфейса. Графический интерфейс непостоянен, и, более того, раз он непостоянен, то из этого следует, что какой-то заведомо гарантированный диалог между пользователем и системой лежит не в этой области и было сказано, что эта область - интерфейс командной строки.
- Объекты операционной системы: это не было сказано напрямую, вернее, не было показано, что объектами ос являются файловая система и файлы. Собственно говоря, в каком-то смысле других объектов нет, особенно, если учесть, что у нас есть еще и субъекты ос.
- Субъекты ОС. Этими субъектами являются процессы.
Эти три вещи, совершенно очевидно, не изменятся в ближайшем будущем, а если и изменятся, то это будет уже другая ос. А сама ос организована как некая надстройка относительно вот этого вот. Да, еще нужно вспомнить про программное обеспечение:
- Программное обеспечение - оно включает в себя понятие пакет. Из понятия пакет вытекает понятие репозиторий, так как программное обеспечение хранится именно там, но об этом мы еще поговорим.
- Инвариантом являются информационные и технические ресурсы сообщества. Почему это входит в понятие ос? Почему инвариант? Потому то если вы не будете взаимодействовать с компьютером как пользователь с информационными ресурсами, то у вас получится плохо. Например, ситуация, когда вас посадили перед компьютером, выключили интернет и сказали «крокодил, играй» — вот это очень плохая ситуация для Windows.
Это отличие современного линукса от линукса 20 или 30-летней давности. Предполагалось, что операционная система должна содержать в себе всю информацию, чтобы можно было пользоваться ею до конца. Соответственно, на сегодняшний день это довольно бессмысленная штука. Довольно бессмысленно создавать статический, огромный корпус текстов, описывающий ос. Потому что пока вы его будете создавать - она уже будет меняться. Примерно это мы и будем рассматривать в текущем курсе, потому что нам нужно вести знакомство с этим вашим линуксом.
Это касаемо инвариантов, которые стоит рассматривать в дальнейшем. теперь перейдем к чему-то из этого списка инвариантов.
Здесь где-то есть небольшое следствие: было бы неплохо поизучать, как ничего из этого не является ос: ядро лишь ядро, сценарий лишь сценарий - все это лишь конструктор для сборки операционной системы. Мы не сможем в этом семестре окончательно разобрать оборудование, так как нам сначала нужно разобраться с -этим-, но было бы неплохо достичь первоначального понимания, что все это и есть ОС и ничего кроме. А все что кроме - то лишь удобные костыли, с помощью которых все работает еще лучше.
Давайте мы тогда не сходя с места обратимся к пункту 1, а именно - к интерфейсу командной строки, так как мы только что убедились в том, что интерфейс графический нам не очень помогает, а единственное, в чем он на помогает - разобраться в многообразии установленных пользовательских приложений, не более.
Ну, окей. Наверное, давайте мы прямо посмотрим примеры такого интерфейса.
Вот, значит, интерфейс командной строки, который нас будет некоторое время преследовать, а если вы решите заняться линуксом всерьез, то он будет преследовать вас всегда. Но прежде, чем показать этот, я буду показывать вам другой, чтобы показать, что свет клином на шелле не сошелся.
Кто ходит на лекции по питону, вспомнит, что питон - тоже интерпретатор командной строки и обладает всеми свойствами командной строки. Сам диалог между пользователем и программой устроен так, что вы выдаете пачку команд, команды интерпретируются и выдают вам ответ. Это язык программирования, его основная цель. - программирование, объекты его - традиционные объекты типа чисел, строк, списков и вот этого всего. Соответственно, когда вы работаете с этим языком программирования, у вас есть какая-то история, где можно что-то поискать, какие-то удобства по работе с командной строкой, ну, короче говоря, помимо того, что это язык программирования, это еще и интерпретатор команд. Как это устроено: мы набираем команду, она разбирается на лексемы, лексемы подвергаются синтаксическому анализу, если верно - команда выполняется. Даже принцип совмещения потоков данных и потоков управления в нем отлично совмещается. Например, если мы вводим команду, которая не нравится питону, он сразу на экран выводит ошибку. Если мы вводим помощь, на тот же экран выведется помощь.
Это для тех, кто знаком с питоном, чтобы было понятно. Есть еще куча других интерпретаторов, например, MySQL. Собственно, редактор командной строки, называемый шеллом (оболочкой) работает совершенно так же, он работает по принципу диалога между пользователем и системой. То есть, вы вводите команду, она обрабатывается, появляется диагностика, на основании диагностики…. . Понятное дело что запуск какой-то программы - это тоже в каком-то роде интерпретация, но тут идея именно в диалоге.
Вот пример команды и ее выполнения: (date - команда для вывода текущей даты) вы ввели команду, произошла ее интерпретация, результат выполнения вылез на экран. В интерпретаторе командной строки шелл реализовано удобство работы с командами: стрелочка вверх показывает историю. Как видите, недавно я читал лекцию по питону. Может быть, мы чуть позже к этому вернемся. Тот язык команд, который вы даете шеллу, является языком программирования, причем довольно высокого уровня: можно писать свои программы на шелле - сценарии или шелл-скрипты. Так вот: язык программирования формализованный шелл тоже существует, его можно и нужно использовать, все аналогично. Где же разница? Почему на свете не существует одного универсального интерпретатора командной строки? Разница в задаче, которую вы преследуете. Цель питона - написание программ, шелла - взаимодействия с системой. Поэтому ваш интерпретатор командной строки должен уметь хорошо работать с системными объектами и вступать во взаимоотношения с системными субъектами.
Так, смотрите, что тут написано: «кошка о точка пы». Давайте выполним эту команду. Ага, судя по всему, команда cat не имеет отношения к кошкам, а, видимо, она происходит от слова catenation, что как бы намекает нам на то, что можно склеить несколько файлов в один стандартный вывод. Вон у нас сколько файлов.
Есть еще программа tac, как вы думаете, что она делает? Она выводит файл задом наперёд. Не знаю, зачем это надо, но бывает нужно. Мы про это тоже поговорим.
Это я к чему. Это я к тому, что, на самом деле, все, что вы делаете в командной строке, за исключением основным категорий типа циклов, функций, переменных - все, что вы делаете в командной строке - вывод команд, и подавляющее их большинство - вообще не какие-то конструкции языка программирования шелл, а просто программы, которые мы запускаем по имени. Вот очень важный момент, чем язык программирования шелл отличается от других языков программирования.
Запуск процесса в шелле - всего лишь указание имени файла, который лежит где-то там. Есть специальное место, где указано, где лежит ваш файл. И вспоминая прошлую лекцию (кол-во программ зависит от кол-ва установленных пакетов) становится понятно, почему вопрос «приведите мне список команд линукса» является бессмысленным.
Можно говорить, что есть такие команды, существующие еще со времен ранних юниксов, без которых обойтись нельзя. Ими мы и будем заниматься, но еще раз повторяю - их довольно мало. Например, утилита ls - входит в базовый набор, правда, современный ls умеет раскрашивать вывод. Ну, вы же понимаете, что не может быть ни синеньких файлов, ни зелененьких файлов. На самом деле, современный ls еще вот это делает: если файл написать с пробелом - он пишет апострофы с двух сторон, хотя их там нету.
Я не зря на этом так залип, потому что мы приближаемся к пониманию того как сборно разбираются команды на части. В этих примерах вы хорошо видели, что первое слово той строки, которую мы вводим - команда, а дальше идут какие-то ее параметры например вот такие:
У нас первое слово нашей строки обычно (но не всегда) - команда, все остальные слова - параметры. Причем, что такое слово? Слово - последовательность неразделителей. Можем добавить разделители и все равно будет нормально работать. Команда echo - принимает 2 параметра, в зависимости от кучи пробелов ничего не меняется — все как раньше.
Поскольку мы договорились, что взаимодействие с элементами командной строки происходит внутри шелл-оболочки, логично ожидать, что среди этих программ много для работы с файлами и текстами. Это актуально, если среди нашего диалога не было ничего, не равного тексту.
Существует довольно большой класс программ, которые предназначены для решения задач — работы с файлами и текстом. Такие программы называются утилитами. Точного разделения между программами, которые называются утилитами, и программами, называются приложениями, вообще говоря, нет. Принято их разделять. Если программа запускается из командной строки и используется для управления системой - она называется утилита. Чем утилита больше - тем меньше ее смысла удалять из системы. Мы не можем выучить все утилиты из этой вашей юникс системы, нам нужно научиться искать то, что нам нужно для всего этого многообразия.
Видимо, пора раскрыть еще несколько тайн. Договоренность о том, что является параметром команды. Параметры бывают двух типов:
- Cодержательные - отсылающие своему объекту
- параметры «ключи» - options. Ключи изменяют логику работы самих материалов.
Команда ls -N --color=none 0.txt - 2 параметра в качестве содержателя. При этом, модификаторы выполнения - ключи, которые говорят, что утилита будет работать немножко не так. Иначе у нас не хватило бы всех буквосочетаний, если бы все утилиты совмещались. Поэтому утилита решает класс подзадач, модификатор ее выполнения.
Ключи, как мы только что видели, бывают двух видов: однобуквенные и полнословные. У подавляющего большинства утилит есть один и тот же ключ в длинной форме и в короткой. Как утилиты достаются:
- Присобачить к ней короткий ключ и получить краткую помощь
- Вызвать утитилу man, которая расскажет вам все в структурированном виде.
Как видите, утилита man бывает на русском языке. Скорее всего, документация, переведенная на русский, будет устаревшей — и поэтому некорректной. Просмотр манпейджей выполняется из специальной программы которая сейчас называется less, раньше называлась more Давайте вызовем утилиту less. Вот вам еще один параметр программы ls: ключ -s - выводит размер в кб.
Что умеет программа просмотра (т.н. пейджер) less?
- искать регулярные выражения
- открывать редактор
- переходить по файлам
- расставлять метки
- переходить по меткам…
и всем этим можно пользоваться.
Команда less предназначена для интеллектуального просмотра файлов, существует по всем утилитам. Страницы man есть по всем программам, установленным в вашей системе, если у вас стоит `Debian`.
Какие еще есть секции в документации?
- имя
- синопсис
иногда выделяется раздел options, отдельный раздел examples и раздел see also.
Важный пункт: когда вы рассматриваете ман — внизу есть список дополнительной документации, которую, как создатели утилиты решили, вам будет интересно посмотреть.
В каком-то идеале, к которому стремились UNIX-системы 20-летней давности - все эти документации должны были иметь всякие связки, если вы хотели бы пойти в соседний кластер, например сменить ваш поиск от утилит, которые преобразуют текст задом наперед к, например, сортировке. К сожалению, эта цель идеальная так и не была достигнута, поэтому я подозреваю что ее никто в виду не имеет.
Вторая причина в том, что текстовая документация существует не только в формате мануал пейдж, который очень жесткий, как видите, достаточно хорошо стандартизирован. Если вы хотите написать документацию в более свободном стиле, то, может быть, вам будет тесно в рамках манпейдж, тем более манпейдж - такой текстовый формат: тут только текст, жирный символ и подчеркивание. Раньше я приводил в примере, откуда там зеленые и синенькие буквы: синенький это, кажется, жирные символы, а зелененький - подчеркнутые. И стандартный формат состоит в том, что 2 раза написать символ - воспринимается как жирный символ. Вопрос сейчас в другом. Вам может быть тесно в рамках манпейджа и вас могут послать в текстовую документацию другого формата которая называется info.
Info необязательно может существовать к вашей программе, зато оно довольно развесистое - фактически оформляется как книжка. Вот, например, просмотр документаций к утилите, которая называется coreutils и тут видите прямо книжка: звездочкой отмечено меню , вы можете унтером туда попасть и читать. Если заглянуть в инфо - главное научиться в инфо навигировать. Его интерфейс воспроизводит редактор Emacs. Если вы нажмете вопросительный знак - он расскажет, как им пользоваться. По-моему, есть еще pinfo.
В некоторых системах, например, в аде есть смотрелка для info (и для манов) в броузере. Поскольку мы говорим о командной строке …. о, есть pinfo, да. Там с навигацией проще. там стрелочки, унтер, как у людей, а не как у этих в емаксе. Ну, автор забросил pinfo где-то году в 2006 и с тех пор что-то изменилось. Тогда пользуемся инфо. И тут куча всякого. Например, одна из любимых моих утилит wc - кол-во слов, строк и букв в выдаче выдает.
Подсистема помощи.
Итак, есть --help, man, info - и то и другое работает в терминале, не обязательно оттуда выходить. В любой системе есть эмулятор терминала и это именно то, с чем мы с вами работаем.
Есть еще так называемая консоль линуксовая: всегда можно нажать ctrl+alt+f-чего-нибудь и перейти в текстовую консоль - я это показывал на прошлой лекции, когда запускал rescue disk, который состоял только из консоли.
Еще один способ модифицировать выполнение программы - задать т.н. переменную окружения. В шелле, как и в других языках программирования, есть переменные как в некотором количестве интерпретируемых языков. Переменные все там текстовые, но поскольку наш шелл предназначен для управления системой, было бы интересно отметить переменные и управление: мы задаем некую переменную окружения и запускаемая нами утилита эту переменную окружения принимает к сведению. Выглядит это так: man date
- получаем ман дейт на руском языке. Перегрузи нам локаль и сделай ее базовой без пересчитывания в какой-то язык! LC-ALL=C man date
и получаем ее на оригинальном языке. А если мы скажем TERM=jfskldjfsdjf - мы перегрузили TERM и он не знает в какие цвета раскрашивать.
Никакого секрета в раскрашивании букв нету: наша утилита (ls, less, текстовый редактор) не знает, как переключать наш терминал, который в переменной TERM знает, как переключать данные в разные цвета, и поэтому раскрашивает. Кстати сказать, для удобства синтаксического разбора обращение к содержимому переменной выглядит как $имя_переменной
Поскольку у нас такое вступление в командную строку, какие еще утилиты бывают посмотрим в след раз, сейчас еще несколько важных вещей которые, очень хотелось бы показать, чтобы узнать, насколько шелл хорош именно в качестве языка программирования для взаимодействия с системой.
Я уже показывал операцию перенаправления вывода. Как она в действительности работает? Чтобы это понять, нужно понять, как работает запуск команды по имени. Это не такая простая вещь - пойдите напишите это на си! Итак, сначала это нужно найти где она лежит. Есть переменная PATH, где лежат все каталоги. Я подозреваю, что этот date в /bin - да, в /bin. Так вот, сначала нужно найти эту команду date. Потом нужно запустить процесс новый, передав ему все окружение - слава богу, в линуксе все это делается очень просто. В прошлом семестре мы даже обсуждали, как это на си делается. Кстати, как закончить все это безобразие? Нужно каким-то образом рассказать терминалу, что файл, который вы вводите, закончился. Это не так очевидно, как кажется: нет никакого символа конца файла. Тем не менее, ctrl-d - и он заканчивается. В чем дело: дело в том, что терминал - это не просто устройство для передачи данных туда и обратно. Когда терминал принимает данные с клавиатуры, он некоторые из них преобразует сам на пути к ядру. Взаимодействие с терминалом происходит в обработанном режиме и за это отвечает команда stty. Команда stty sane - восстанавливает параметры терминальной линии до здорового состояния.
Перенаправление вывода в файл file: > file, перенаправление ввода: < file
И, вообще говоря, команда, как вообще всякая программа, например, на си, получает на вход 3 файла: стандартный ввод, стандартный вывод и стандартный вывод ошибок. Когда шелл открывает wc - он принимает 3 файла. Большинство утилит в линуксе работают именно так: читаем со стандартного ввода, пишем на стандартный вывод. Дальше:
Можно указать, что будет концом файла (ввод) - here documents Например:
cat <<@@@@
Перенаправление: ls -l a. О! — ошибка! — у нас нет файла а.
Обратная картина ls -l a o >2 oe - диагностика в файле ое. Перенаправление одного потока в другой, но идея в том, что один поток в файл, а потом второй - туда же, куда и первый. ls -l a o >o 2>&1
Самые главные и простые перенаправления в шелле:
1: конвейер, которым я пользовался, не объясняя что это такое cal | wc — запустить программу календарь и стандартный вывод прислать на команду wc.
2: постановка результатов работы программу в строку, которую можно присвоить переменной. Например:
AAA=‘ls’ echo $AAA
Если вы хотите, чтобы echo вывело то, что вы хотите:
echo fsdf sf df - плохо echo "fsdf sf df" - хорошо - вы передадите ей один параметр.
Пафос состоит в том, что любой текстовый вывод можно положить в текстовую переменную и работать с ней в переменной. Двойные кавычки - подстановка выполняется в переменную, одинарные - нет.
Вот такой вот наскоком разговор о работе с шеллом. В следующий раз мы будем говорить с вами о файлах и файловой системе.