Text111

строятся как фильтры, т.е. используют и стандартный ввод, и стандартный вывод. К таким командам относятся команды sort, more (общие для всех рассматриваемых ОС) и команда wc из Unix, которая подсчитывает число строк, слов и символов в файле, служащем для ввода информации (в частности, текста, вводимого с клавиатуры).

Практическое значение стандартного ввода-вывода особенно велико в связи с применением так называемых конвейеров в командной строке. Конвейер представляет заданное в команде связывание стандартного вывода одной команды с стандартным вводом другой – следующей в строке – команды. В качестве символа связывания команд в конвейер используется символ | (одинарная вертикальная черта). Конвейер по внешнему виду представляет запись

команда1 | команда2

Здесь стандартный вывод команды команда1 автоматически связывается со стандартным вводом команды команда2. Поэтому данные результата первой команды не появляются на экране, а полностью передаются на вход второй команды, которая и использует их в качестве обрабатываемой ее информации. В одной составной команде может быть построен конвейер не только из двух, но и из любого числа команд, соединенных при записи символом вертикальной черты. Единственное требование при этом заключается в том, что для соединяемых таким путем команд первая из них должна использовать стандартный вывод, а вторая – стандартный ввод.

Практически наиболее часто в конвейерах используется команда more, которая оказывается заключительной в конвейере, поскольку выводит на экран, а не в стандартный вывод. Ее значение в том, что вывод на экран производится порциями по размеру экрана, это позволяет удобно наблюдать результаты объемного вывода на экране, где без ее использования часть выводимых данных исчезает – автоматически выдвигается за верхнюю границу экрана. Даже в операционных системах типа MS эта вспомогательная команда достаточно широко используется при текстовом выводе информации, в частности в составной команде

dir | more

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

В Unix для использования конвейеров существует дополнительная команда tee, которая в качестве единственного аргумента требует указания имени файла и передавая данные со своего стандартного ввода на стандартный вывод одновременно запоминает передаваемые данные в заданном для нее файле. Она как бы кроме простой передачи с входа на выход еще и протоколирует все данные в файле.

При использовании стандартного ввода-вывода иногда возникает проблема запоминания сообщений об ошибках. Для вывода информации об ошибках предназначен стандартный поток ошибок, имеющий константное значение хэндла в Unix и OS/2, равное 2, причем этот вывод об ошибках по умолчанию поступает на экран.

Для переадресации стандартного ввода и стандартного вывода, как уже описывалось в гл. 2, в командной строке используются вспомогательные символы '<' и '>' соответственно. Для переадресации стандартного потока ошибок используется запись вида

команда 2>имя_файла

Предоставляется также возможность направлять данные об ошибках в стандартный поток обычного вывода. Для этого предназначена запись вида

команда 2>&1 Наконец, существует возможность при необходимости перенаправить стан-

дартный вывод в стандартный поток ошибок, что задается записью

команда 1>&2 При использовании переназначений с помощью символов обозначений

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

В частности команда

команда <файл1 >файл2 2>>файл3

указывает – брать исходные данные в файле файл1, помещать данные стандартного вывода в файл файл2 и дописывать в конец файла файл3 сообщения стандартного потока ошибок текущей команды команда.

12.6. Командные файлы и сценарии

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

мандному интерпретатору, принято называть сценариями команд или командными файлами (иногда используется еще термин пакетные файлы).

В операционной системе MS DOS и основанных на ней модификациях Windows 9х такие пакетные файлы должны обязательно иметь расширения .bat, в операционных системах OS/2 и Windows NT командные файлы обязаны иметь расширение .cmd. В этих ОС запуск командных файлов требует просто указания их имени в качестве имени команды. Зато в Unix никаких ограничений на обозначения командных файлов (сценарием команд) не накладывается. Но для их запуска на выполнение возможны целых три пути. Первый из них заключается в запуске командного файла с помощью запускающей команды sh, так что такой запуск имеет вид

sh имя_командного_файла

Близким к нему, но более кратким вариантом является запись вместо команды просто единственного символа точки (так что символ точки используется в Unix в существенно различных применениях: обозначения текущего каталога и имени запускающей команды). Таким образом, предыдущая команда может быть также введена в эквивалентном виде

. имя_командного_файла

Наконец, имеется и возможность для прямого запуска командного файла исключительно по его имени, но перед этих запуском для командного файла должны быть установлены права доступа на выполнение. Практически следует лишь предварительно выполнить команду

chmod +x имя_командного_файла

икомандный файл можно будет запускать непосредственно по имени.

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

Для краткости параллельно будем рассматривать возможности трех типов командных файлов: для интерпретаторов типа MS (для MS DOS/Windows 9x, OS/2 и Windows NT), для командного интерпретатора Unix, называемого bash (в модификации, применяемой в Linux), и для командного интерпретатора tcsh из Linux.

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

ность заключается в задании служебного символа @ перед первым символом команды ECHO, так что последняя приобретает вид @ECHO.

Запрет на отображения текста других команд задается более глобально. Именно для установки режима отмены отображения команд предназначена команда ECHO OFF, которая действует до выполнения команды ECHO ON, после которой дальнейшие команды будут отображаться (до новой команды ECHO OFF, если она появится). Причем сама команда ECHO OFF еще отобразится на экране, если ее не задать в форме @ECHO OFF.

Вкомандной оболочке bash в Unix команды, выполняемые из сценария команд, не отображают свой текст на экране в ходе такого выполнения. Текст команд отображается только, когда команды по одиночке (или в составе пакета, задаваемого разделителями ; && ||) задаются на выполнение в обычном режиме командной строки. Практически это снимает проблемы "отображать или не отображать". В командном интерпретаторе tcsh возможности управления отображением команд аналогичны интерпретаторам типа MS (точнее вторые используют более раннее техническое решение, появившееся в свое время именно в интерпретаторах типа tcsh). Эти возможности задаются в tcsh парой команд set echo и unset echo, причем первая из них устанавливает режим отображения текста каждой из следующих команд, а вторая отменяет режим такого отображения.

Команда echo в Unix имеет одну полезную опцию, задаваемую как -n. При наличии этой опции не происходит перехода на следующую строку вывода по завершению вывода текущей командой. Это дает возможность формировать единственную строку вывода, используя несколько операторов. (В отдаленных аналогиях эта возможность аналогично использованию оператора WRITE в Паскале вместо WRITELN или использованию оператора вывода printf, аргумент формата которого не содержит управляющего символа '\n'.)

Для вспомогательных целей программирования предназначены комментарии

вкомандных файлах. Командные интерпретаторы типа MS рассматривают как комментарии строки, начинающиеся со служебного слова REM, а в Unix интерпретаторах для задания комментариев предназначен служебный символ #.

ВUnix имеется возможность с помощью команды chsh изменить командный обработчик по умолчанию или вызывать командный файл, указывая явно командный интерпретатор в виде

bash имя_командного_файла tcsh имя_командного_файла

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

#!имя_ программы_нужного_интерпретатора

Так, задание вызова интерпретатора bash должно иметь в первой строке текст #!/bin/sh

а для вызова интерпретатора tcsh текст #!/bin/tcsh

(использовано стандартное размещение упомянутых программ интерпретаторов в файловой системе Linux).

Более-менее сложное программирование немыслимо без использования переменных. Поэтому все рассматриваемые оболочки содержат средства задания переменных. В оболочках типа MS переменные задаются с помощью вспомогательного служебного слова SET. Практически это слово открывает оператор командной строки, задающий значение переменной (это очень похоже на язык Basic, где для таких целей используется служебное слово LET). Оператор определения переменной имеет здесь вид

set имя_переменной=значение

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

Воболочке tcsh для Unix определение переменной строкового типа также задается с помощью служебного слова set. Причем в этом интерпретаторе символ присваивания (символ =) либо совсем не выделяется пробелами (ни справа, ни слева), либо выделяется пробелами с обеих сторон.

Воболочке bash для Unix определение переменной строкового типа задается более простой конструкцией вида

имя_переменной=значение

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

задаваться в кавычках.

Для более тонких случаев в качестве символов, окаймляющих значение для переменной, используются символы прямых или обратных апострофов (символы ' и `). Предварительно заметим, что при использовании кавычек содержимое, заданное параметром значение, используется в применении переменной без всяких из-

менений и подстановок. Определение переменной с помощью апострофов приводит к подстановке в тексте значений переменных.

После определения значения переменной указанными выше способами эта переменная может быть использована в дальнейших командах. Такое использование требует не просто задания имени переменной, но ее имени с уточняющими символами. В интерпретаторах типа MS такое применение имени переменной требует записи вида

%имя_переменной%

а в интерпретаторах Unix в простейших случаях используется единственный служебный символ $ перед именем переменной. В более сложных случаях, требующих синтаксического выделения имени переменной из последующего текста, используется форма

${имя_переменной} Заметим, что никакие дополнительные пробелы в этих формах не допустимы

(пробелы являются синтаксически важными символами разделения элементов конструкций в командных файлах).

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

Данное изложение знакомит только с простейшими средствами командных интерпретаторов операционных систем. Не рассмотренными остались многие другие, в том числе и достаточно используемые и полезные средства. Среди них – приемы использования переменных в командных интерпретаторах, ввод данных в сценариях команд, арифметические операторы, управляющие структуры в MS, управляющие структуры разветвления в Unix сценариях, управляющие структуры циклов в Unix сценариях. Их изучение рекомендуется продолжить по списку рекомендуемой литературы [1,7,11,24].

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1.Банахан М., Раттер Э. Введение в операционную систему UNIX. - М:. Радио и связь, 1986. - 344 с.

2.Бек Л. Введение в системное программирование. - М: Мир,1988. - 448 с.

3.Гордеев А.В., Молчанов А.Ю. Системное программное обеспечение. -СПб.: Питер, 2001. - 736 с.

4.Дейтел Г. Введение в операционные системы. - М:. Мир, 1987. Т.1. -357 с., Т.2. - 398 с.

5.Кастер Х. Основы Windows NT и NTFS. - М:. Издательский отдел "Русская редакция ТОО Channel Trading Ltd", 1996. - 440 с.

6.Кейлингерт П. Элементы операционных систем. - М:. Мир, 1985. - 295 с.

7.Керниган Б.В., Пайк Р. UNIX – универсальная среда программирования. - М.: Финансы и статистика, 1992. - 304 с.

8.Краковяк С. Основы организации и функционирования ОС ЭВМ. - М.: Мир, 1988. - 480 с.

9.Крэнц Дж. и др. Операционная система OS/2. - М:. Мир, 1991. - 351 с.

10.Митчел М., Оулдем Дж., Самьюэл А. Программирование для Linux. Профессиональный подход. - М.: Изд. дом "Вильямс", 2002. - 288 с.

11.Петерсен Р. LINUX: Руководство по операционной системе. - К.: Изд. гр. BHV, 1997. - 688 с.

12.Рихтер Дж. Windows для профессионалов. - М:. Издательский отдел "Русская редакция ТОО Channel Trading Ltd", 1995. - 720 с.

13.Рихтер Дж. Windows для профессионалов: создание эффективных Win32приложений с учетом специфики 64-разрядной версии Windows. - СПб:. Питер; М.: Изд.-торг. дом "Русская редакция", 2001. - 752 с.

14.Робачевский А. Операционная система UNIX. - СПб.: BHV - Санкт-Петер- бург, 1997. - 528 с.

15.Теренс Ч. Системное программирование на C++ для Unix. - К.: Издательская группа BHV, 1997. - 592 с.

16.Стивенс У. UNIX: взаимодействие процессов. - СПб.: Питер, 2002. - 576 с.

17.Столлингс В. Операционные системы. - М.: Изд. дом "Вильямс", 2002. - 848 с.

18.Флоренсов А.Н. Системное программирование в многозадачных ОС. Семантический подход: Учеб. пособие - Омск: Изд-во ОмГТУ, 2000. - 102 с.

19.Флоренсов А.Н. Введение в системное программирование для 32-разрядных компьютеров: Учеб. пособие. - Омск, Изд-во ОмГТУ, 1998. - 144 с.

20.Флоренсов А.Н. Программирование для графического интерфейса. Семантический подход: Учеб. пособие. - Омск, Изд-во ОмГТУ, 2003. - 128 с.

21.Фролов А.В., Фролов Г.В. Программирование для Windows NT. - М.: ДИА- ЛОГ-МИФИ, 1996, - 272 с. (Библиотека системного программиста; Т.26)

22.Фролов А.В., Фролов Г.В. Программирование для Windows NT: Ч. 2. - М.: ДИАЛОГ-МИФИ, 1997, - 271 с. -(Библиотека системного программиста; Т.27)

23.Хэвиленд К., Дайна Г., Салама Б. Системное программирование в Unix. Руководство программиста по разработке ПО. - М.: ДМК Пресс, 2000. - 368 с.

24. Попов А. Командные файлы и сценарии Windows Script Host. - СПб.: BHVПетербург, 2002. - 320 с.