Differences between revisions 1 and 2
Revision 1 as of 2008-07-17 17:15:30
Size: 10513
Editor: eSyr
Comment:
Revision 2 as of 2008-07-21 21:57:31
Size: 23486
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Ппытка прилепиться к конкр. граф болочке приводит к тому, что a) вы не понимаете, чт такое линукс, б) ... Прилепляться к конкретной графической оболочке не стоит по следующим причинам:
 * вы не понимаете, что такое линукс
 * в какой-то момент вам, возможно, прийдётся перейти на другую графическую оболочку
Line 5: Line 7:
Для начала, надо ответить на вопрос --- хорошо, в течение часа расск. не про линукс. А что же такое линукс? Из вчерашнего разг. значем, чт линукс в первую очередь сбщество, то, что мы видим --- результат работы сообщества. Но эт не ответ на вопрос. Кгда линукс должен отв. задачам ОС, то чем явл. ..., что явл польз. приложениями? Тут можн потеоретиз. на тему чел-маш взаимодействия (см. первые лекции посл. семестра). ... Линукс как некаяОС, кк некий комплекс средств, бесп. униф, разд. и разгр. ресурсов, базируется на двух принципах:
 * Любые сист. бъекты, которые требуется как-то идентиф, для упр. системой --- файлы. Речь чём --- никаких тинственных кнопк, никаких рабочих столов нет. Оно всё взаимозаменяеме. Чт есть --- есть ФС, сст. из каталгов и фалов, и структура ФС в линуксе весьма стандартизвана.
Для начала, надо ответить на вопрос - в таком случае, что же такое линукс? Из вчерашнего разговора мы знаем, что линукс в первую очередь - сообщество, то, что мы видим - результат работы сообщества, причём эти люди частично между собой сговаривались, а частично каждый это делал для себя. Но эт' не ответ на вопрос. Когда лектор говорит о том, что линукс должен отвечать задачам ОС, о чём он говорит, если всё это являестя пользовательскими приложениями? Тут можно потеоретизировать на тему человек-машинного взаимодействия (см. первые лекции последнего семестра). То есть, есть человек, есть компьютер, человек должен управлять компьютером, и наша задача - не просто научить человека управлять компьютером, а дать ему в руки инструмент для изобретения любого решения. Лектор хочет оставить это место бездоказательным и начать сразу с утверждения. Линукс как ОС, как некий комплекс програмных средств, обеспечивающий унификацию, разделение и разграничение ресурсов для пользовательских программ, базируется на трёх принципах:
Line 8: Line 9:
Файлы эти, если они треб. модиф. со стороны польз или автомат. модиф, должны быть текстовыми, и это второй принцип. Т есть, с чтки зрения польз, структура ОС предст. в виде дерева файлов, в каждом из которых хранится какая-то информация, которые можно глазами прочитать. Искл. составляют файлы, которые не предназаначены для чтения пользователей --- прграммы, библиотеки... Любые другие файлы длжны быть п возм. текстовые.  * Любые системные объекты, которые требуется как-то модифицировать, чтобы управлять системой и приложениями - это файлы. Никаких тинственных кнопок, никаких рабочих столов нет. Оно всё взаимозаменяеме. Что есть - есть файловая сситема, состоящая из каталогов и файлов, и структура файловой системы в линуксе весьма стандартизвана и умопостижима, то есть в ней легко разобраться, что где и для чего нужно. У термина файловая система, замечает лектор, есть два значения: 1) способ хранения файлов на диске и 2) способ представления файлов для пользователя; здесь говорится о втором.
 * Файлы, если они требуют модификации со стороны пользователя или автоматической модификации, должны быть текстовыми, то есть, если превый принцип коротко формулируется как "всё файл", то второй формулируется "всё текст". То есть, с точки зрения пользователя, структура ОС представляется в виде дерева файлов, в каждом из которых хранится какая-то информация, которую можно глазами прочитать. Исключение составляют файлы, которые не предназаначены для чтения и модификации пользователем - программы (те, которые в бинарном виде), библиотеки... Любые другие файлы должны быть по возможности текстовые.
 * Третий принцип состоит в том, каким образом организуется человекомашинное взаимодействие, то есть как человек управляет компьютером если все объекты его управления есть, грубо говоря, текствые файлы, лежащие в каталогах. В этм случае инструмент управления должен работать а) с файлами и б) с текстом, в сумме, с текстовыми файлами. Что это за инструмент? При этом сам инструмент должен быть так организован, чтобы он не выходил из рамок парадигмы файл-текст: челвек и машина должны обмениваться текстами, и в результате этого должны модифицироваться файлы. Неким следствием этого принципа будет то, что основным интерфейсом управления unix-подобной системы в этй парадигме является интерфейс командной строки. В любом случае (то есть, даже если лектор не доказывает его преимущество) очевидно, что он очень подходит для этой парадигмы: вы набираете текстовые команды, компьютер команды интерпретирует (т.е. разбирает этот текст на части, чтобы понять, чего вы ему скомандовали), исполняет и в качестве результата выдаёт обратно текст.
Line 10: Line 13:
Третий принцип сост. в том, каким обр. орг. человекомаш. взаимодействие, если всё есть текствые файлы. В этм случае инстр. упр. должен рабтать с текст. файлами. Что это за инструмент? При этом сам инстр не должен выходить из этй парадигмы: челвек и машина бм. текстом, и в результате этого должны мдиф. файлы. Неким следствием этг принципа будет то, что основным инт. упр. unix-подобной системы в этй парадигме явл. инт. командной строки. В любм случае очевидно, что он очень подходит для этой прадигмы: вы набираете текстовые команды, компбьютер команды интерпретирует, исполняет и в кчестве результата выдаёт обратно текст. Понятно, что задачи могут выходить за рамки этго, но ... . Лектор сразу говорит, чт подробнее можно прчитть в книжке МК, на почти полн. этму посвязена, там далеко не вся, тема большая обширная и её необязх. всю охватывать рахзумм, если тема большая. Основной совет --- если не знаете инстр. для задачи, то поищите его, н наверняка есть. В результате окажется, что вы накопили багаж знаний, дост. для решения всех своих задач. Понятно, что задачи могут выходить за рамки этого, но сейчас мы говорим не о пользовательских задачах, а об управлении системой как таковой. Лектор сразу говорит, что подробнее об этом можно прочитать в книжке МК, она почти полностью этому посвящена, там тоже есть далеко не всё, тема обширная и её необязательно всю охватывать разумом, если вы хотите познакомиться с линуксом. Её необязательно всю охватывать разумомесли вы не собираетесь пользоваться машиной больше чем точкой для интернет-браузера, точкой для прослушивания музыки и почтовым клиентом - все пункты есть в меню. А вот если вы пытаетесь линукс изучать, вам опять-таки не следует пытаться охватывать всё это разом, а пользоваться таким алгоитмом: если вы хотите решить задачу, для которой у вас недостаточно инструментов (например, у вас есть микроскоп и надо забить девятнадцать гвоздей), не пытайтесь решить задачу имеющимися инструментами (не пытайтесь все девятнадцать гвоздей забить микроскопом, ну один гвоздь разрешается забить микроскопом - чтобы убедиться, что так делать не надо), а изучите, какой интструментарий предоставляет линукс под это дело, выберите подходящий молоток и дальше получайте своё удовольтвие с молотком. Если убрать все иносказания: если вы чувствуете, что решение задаи неэффективно, это значит,что вы просто не знаете нужного инструмента. Ищите инструмент. У линукса очень богатый инструментарий, и, скорее всего, инструмент для решения вашей задачи тоже есть, только вы его ещё не освоили. В результате окажется, что, честно читая документацию в подобных случаях вы накопили багаж знаний, достаточный для решения всех своих, в том числе довольно изощрённых задач, и вам уже прямая дорога в гуру.
Line 12: Line 15:
Чуть более формальн, что такое ИКС. Мы все знаем, что есть прграмма, шелл, интерпретатор командной строки. Т есть не линукс разговаривает, а при логине запускается мнго прграмм, одна из них --- спеец. прграмма, в задачи которй входит орг. ИКС. Именно эта программа яитает воод с ком. стрки, интерп., выводит результаты (свои или других программы). Существует неск. прграмм, реализ эту праадигму, не только шеллв, н и, например, клиент mysql, python... Чуть более формально о том, что такое интерфейс командной строки. Мы все знаем, что есть программа, шелл, интерпретатор командной строки. То есть не просто линукс с вами разговаривает, а при логине запускается много процессов, один из них - специальная прграмма, в задачи которй входит реализация интерфейса командной строки по управлению линуксом. Именно эта программа читает то, что вы вводите с клавиатуры, анализирует, выполняет соответствующие задачи, выводит результаты (свои или других программ) в виде текста. Существует несколько программ, реализующих эту парадигму, не только шелл, но и, например, клиент mysql, python. То есть, идея, что человек сидит за клавиатурой, даёт текстовую команду, эта команда исполняется, результат выводится на экран, она эксплуатировалась много раз с тех пор, как изобрели шелл.
Line 14: Line 17:
Как выглядит команда, которую вы даёте шеллу: команды вводятся построчно, строка разбивается на слова по принц. любых симвлов, подряд идущих, не явл. разделителем, и разделители. Первое слво --- кманда, стальные слва --- параметры команды. Надо понять, ткуда это взникла. Можно было конечно придумать на каждый случай жизни специадльную команду ()нарисовать розовую мышку --- одна кманда, нарисовать голубого слова --- другая команда, и так далее. Но понятно, что склова быстр кончатся и станет грустно, кроме того, запоминать эт невозможно. Поэтму ис.п лсде. принцип --- программа решает нек. задачу, и все ньюнсы пведения (файлы, параметры) передются в виде неск. слова. Пример --- кманда скрипт с двумя параметрами. Т, чт дальше обрабатывается шеллом и команде это не передаётся. Как выглядит команда, которую вы даёте шеллу: команды вводятся построчно, строка разбивается на слова по принципу: последовательности любых симвлов, подряд идущие и не являющиеся разделителями - это слово, а последовательности разделителей - это не слово, а промежуток между словами. Разделители - это пробел, символ табуляции и символ перевода строки (хотя заставить шелл воспринимать последний как разделитель довольно тяжело: перевод строки - управляющая клавиша, и, нажимая её, шеллу передаётся вся строчка целиком). Итак, строка, которую вы вводите, разбирается на слова, первое слово - команда, остальные слова - параметры этой команды. Надо понять, откуда это взникло. Можно было конечно придумать на каждый случай жизни специадльную команду (нарисовать розовую мышку - одна кманда, нарисовать голубую мышку - другая команда, и так далее). Но понятно, что слова быстро кончатся и команды станут выглядеть совсем ужасно, кроме того, запоминать это будет невозможно. Поэтму при работе с командной строкой осуществляется следующий принцип - команда, которая, по сути говоря, утилита, решает некоторую пользовательскую подзадачу, и все параметры (файлы, нюансы работы) передются в виде следующих слов. Пример - то, что мы видим на экране - это команда script с двумя параметрами. Последнее слово по причине того, что шелл его обработал, не является параметром команды script. Наличие символа > - это перенаправление вывода, это значит, что к тому моменту, когда команда запустится, этой группы символов уже не будет.
Line 16: Line 19:
Как это происходит --- пользователь набирает строку, шелл её обрабатывает строку, есть два варианта --- команда встренная или внешняя (ищется по спец. алгоритму). Ещё до этого шелл обрабатывает строку на нличие спецсимволов (на самм деле, там есть третий тип --- упр. символы). После того, как н их находит, он их обр., в данном случае, stderr будет перенапр. не на экран, а в файл. Более того, script этго даже не заметит, если не присматриваться. После тго, как будет перенапр. вывод, этт кусок строки удалится, и script будет запущен с двумя параметрами. {{{
#script -t 1.script 2>1.script.time
}}}
Line 18: Line 23:
По этому примеру видно ещё одно: ключи и содерж. параметры. Содерж. параметры --- имена объектов, строки, какая-о инф, которая исп. в прграмме. Ключи --- спец. параметры, которые изм. пведение программы. Нпример, -t заставляет вывдить время на stderr, а 1.script --- чодерж. параметр --- имя файла, в ктором сохр. Здесь - пример того, как люди используют историю как записную книжку. Решётка вначале означает комментарий. Эта команда не выполнилась. Но она сохранилась в истории.
Line 20: Line 25:
Кманда ls показывает списк файлв в тек. каталоге. В частности, если звёзы сложились удачно (при наличии алиаса и сотв. терминала), то они будут раскрашены. Если вызвать /bin/ls, то раскраски не будет. Если сказать -F, то увидим в конце директорий "/" (и изменили поведение программы). Если указать -s, то можн увидеть ещё и размер. При этом собл. принцип аббревиативности, по возм. --- вместо полных назхваний ключей (--size) исп. сокращения (-s). Кроме того, однобукв. ключи могут прилипать друг к другу: ls -Fs. Достинсмтво однобукв. ключей --- их быстр набирать, недостаток --- их надо помнить. И когда ключей много или ни исп. редко, то исп. плнословная нотация, когда ключи нач. с двухз минусов и тогда идёт полное название параметра. Надо учитиывать, чт это соглашения, и они могут не выполняться (dd, ps, tar) Фактически, диалог пользователя и системы при помощи командной строки происходит следующим образом. Пользователь набирает команду в командной строке, шелл обрабатывает строку, в данном случае он смотрит в два места:
 * Он определяет, что это за команда такая script. Есть небольшой набор встроенных в шелл команд (например cd - встроенная команда, потому что нельзя поменять текущий каталог в другой программе). Если команда встроенная, всё хорошо, если нет, шелл ищет по специальному алгоритму, нет ли где утилиты с таким названием.
 * Ещё до этого шелл обрабатывает строку на наличие спецсимволов (когда лектор говорил, что есть два вида символов, он немножко покривил душой: на самом деле, там есть третий тип - управляющие символы). В данном случае, шелл нашёл управляющий символ >, который означает перенаправление вывода. То есть, весь текст, который должен был выходить на стандартный вывод ошибок, был перенаправлен шеллом в файл 1.script.time. После того, как он находит управляющие символы, он их обрабатывает, в данном случае, при запуске команды script вывод ошибок будет перенаправлен не на терминал, а в файл. Более того, script этго даже не заметит, если специально не будет к этому присматриваться. После того, как будет перенаправлен вывод, этот кусок строки удалится из командной строки, и script будет запущен с двумя параметрами.

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

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

Давайте вместо команды script будем использовать команду ls, которая показывает список файлов в текущем каталоге. В частности, если звёзды сложились удачно (при наличии алиаса и сответствующего терминала), то она будет все объекты цветом выделять. Но это необязательно. Если вызвать /bin/ls, то раскраски не будет.
{{{
$ /bin/ls
DirDir File
}}}
Обратите внимание, что если просто выводить названия файлов и каталогов на экран, непонятно, кто из них каталог, а кто файл. Есть ключ -F, который после каталога рисует "/", чтобы мы видели, что это каталог. Вот типичный пример работы ключа, который модифицирует работу программы. Тот параметр, который вы передаёте, никакому объекту не соответствует: это не файл, ни имя; лектор даже затрудняется сказать, что означает буква 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), они были написаны давно, когда этого соглашения не было.
Line 28: Line 74:
|| 0 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || || 20 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || ||

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

Прилепляться к конкретной графической оболочке не стоит по следующим причинам:

  • вы не понимаете, что такое линукс
  • в какой-то момент вам, возможно, прийдётся перейти на другую графическую оболочку

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

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

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

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

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

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

Здесь - пример того, как люди используют историю как записную книжку. Решётка вначале означает комментарий. Эта команда не выполнилась. Но она сохранилась в истории.

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

  • Он определяет, что это за команда такая script. Есть небольшой набор встроенных в шелл команд (например cd - встроенная команда, потому что нельзя поменять текущий каталог в другой программе). Если команда встроенная, всё хорошо, если нет, шелл ищет по специальному алгоритму, нет ли где утилиты с таким названием.
  • Ещё до этого шелл обрабатывает строку на наличие спецсимволов (когда лектор говорил, что есть два вида символов, он немножко покривил душой: на самом деле, там есть третий тип - управляющие символы). В данном случае, шелл нашёл управляющий символ >, который означает перенаправление вывода. То есть, весь текст, который должен был выходить на стандартный вывод ошибок, был перенаправлен шеллом в файл 1.script.time. После того, как он находит управляющие символы, он их обрабатывает, в данном случае, при запуске команды script вывод ошибок будет перенаправлен не на терминал, а в файл. Более того, script этго даже не заметит, если специально не будет к этому присматриваться. После того, как будет перенаправлен вывод, этот кусок строки удалится из командной строки, и script будет запущен с двумя параметрами.

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

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

Давайте вместо команды script будем использовать команду ls, которая показывает список файлов в текущем каталоге. В частности, если звёзды сложились удачно (при наличии алиаса и сответствующего терминала), то она будет все объекты цветом выделять. Но это необязательно. Если вызвать /bin/ls, то раскраски не будет.

$ /bin/ls
DirDir  File

Обратите внимание, что если просто выводить названия файлов и каталогов на экран, непонятно, кто из них каталог, а кто файл. Есть ключ -F, который после каталога рисует "/", чтобы мы видели, что это каталог. Вот типичный пример работы ключа, который модифицирует работу программы. Тот параметр, который вы передаёте, никакому объекту не соответствует: это не файл, ни имя; лектор даже затрудняется сказать, что означает буква 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

20

1

1

1

1

ConstantinYershow, DmitryChistikov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

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