Интерпретатор shell — это наиболее важная программа для пользователей UNIX, быть может, за исключением вашего любимого текстового редактора. Она исполняет ваши запросы на запуск программ и занимает гораздо больше вашего времени, чем любая другая программа системы. Значительная часть настоящей главы и гл. 5 будут посвящены описанию возможностей интерпретатора. Основная мысль, к которой мы хотим подвести вас, состоит в том, что если вы научитесь работать с интерпретатором, то сможете достичь многого и без особого труда, не прибегая к традиционным языкам программирования типа Си.

Как уже отмечалось, описание интерпретатора разделено на две части. В этой главе от простейших возможностей, показанных в гл. 1, мы перейдем к рассмотрению некоторых необычных, но широко используемых конструкций, таких, как метасимволы, кавычки, новые команды с переданными им аргументами, переменные shell и отдельные структуры управления. Все это понадобится вам для эффективной работы с интерпретатором. Материал гл. 5 более сложный. Изучив его, вы сможете писать настоящие программы на языке shell и даже предоставлять их другим пользователям. Такое деление темы, конечно, во многом произвольно, поэтому мы рекомендуем вам прочитать обе главы.

 

3.1 Структура командной строки

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

Самая простая команда состоит из одного слова, обычно имени файла, предназначенного для выполнения (позднее вы познакомитесь с другими типами команд):

$ who Выполняем файл /bin/who

you tty2 Sep 28 07:51

jpl tty4 Sep 28 08:32

$

Команда, как правило, завершается символом перевода строки, но может завершаться и точкой с запятой:

$ date;

Wed Sep 28 09:07:15 EDT 1983

$ date; who

Wed Sep 28 09:07:23 EDT 1983

you tty2 Sep 28 07:51

jpl tty4 Sep 28 08:32

$

Однако выполнение команды не начнется, пока вы не нажмете клавишу RETURN. Обратите внимание на то, что интерпретатор выдает только одно приглашение после нескольких команд, но если не учитывать этого, то ввод

$ date; who

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

$ date; who | wc

Wed Sep 28 09: 08:48 EDT 1983

2 10 60

$

Возможно, вы получите не то, что ожидали, поскольку только результат команды who передается команде wc. При связывании who и wc через программный канал образуется единая команда, называемая конвейером, которая выполняется после date. В процессе разбора командной строки shell считает приоритет операции '|' выше, чем операции ';'. Для группирования команд следует использовать скобки:

$ (date; who)

Wed Sep 28 09:11:09 EDT 1983

you tty2 Sep 28 07:51

jpl tty4 Sep 28 08:32

$ (date; who) | wc

3 16 89

$

Результат выполнения команд date и who конкатенируется в один поток, который можно передать по программному каналу.

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

$ (date; who) | tee save | wc

3 16 89 Результат команды wc

$ cat save

Wed Sep 28 09:13:22 EDT 1983

you tty2 Sep 28 07:51

jpl tty4 Sep 28 08:32

$ wc

3 16 48

$

Команда tee переписывает свой входной поток в поименованный файл (или файлы), а из него — точно так же без изменений в выходной поток, поэтому wc получает те же самые данные, как если бы команда tee не присутствовала в конвейере.

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

$ long-running-command &

5273 Номер процесса длительной команды

$    Приглашение появляется сразу

Имея возможность группировать команды, получаем некоторые интересные способы применения фоновых процессов. Команда sleep ожидает указанное число секунд, прежде чем закончить свое выполнение:

$ sleep 5

$ Проходит 5 секунд до появления приглашения

$ (sleep 5; date) & date

5278

Wed Sep 28 09:18:20 EDT 1983   Результат второй команды date

$ Wed Sep 28 09:18:25 EDT 1983 Появляется приглашение, затем

через 5 секунд дата

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

$ (sleep 300; echo Чай готов) & Чай будет готов через 5 минут

5291

$

(Если в строке, следующей за командой echo, есть символ ctl-g, то при появлении ее на экране зазвонит звонок.) В этих примерах нужны скобки, так как приоритет '&' выше, чем у ';'.

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

$ pr файл | lpr &

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

$ (pr файл | lpr ) & To же, что и в предыдущем примере

Большинство команд допускает наличие аргументов в командной строке, таких, как файл в предыдущем примере (аргумент команды pr). Аргументами служат слова, разделенные пробелами и символами табуляции, которые обычно именуют файлы, предназначенные для обработки командой. Однако они рассматриваются просто как строки, и программа может интерпретировать их любым подходящим для нее способом. Например, команда pr допускает имена файлов, которые нужно напечатать, команда echo посылает эхо своих аргументов без всякой интерпретации, а первый аргумент команды grep специфицирует строку-шаблон для поиска. И конечно, многие команды имеют необязательные параметры (флаги), задаваемые аргументами, начинающимися со знака “-”.

Различные специальные символы, интерпретируемые shell, такие, как <, >, |, ; и &, не являются аргументами команд, запускаемых интерпретатором. Они управляют самим процессом запуска. Например,

$ echo Hello > junk

требует, чтобы интерпретатор запустил команду echo с одним аргументом Hello и поместил выходной поток в файл junk. Строка > junk не является аргументом команды echo; она интерпретируется shell, и echo никогда ее "не увидит". На самом деле, данная строка может и не быть последней в командной строке:

$ > junk echo Hello

Это идентичный запуск, хотя и менее очевидный.

Упражнение 3.1

В чем состоит различие между следующими командами?

$ cat file | pr

$ pr <file

$ pr file

(С течением времени операция переключения < потеряла свою связь с программными каналами; " cat file | " считается более естественным, чем " < file ".)

 

3.2 Метасимволы

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

$ echo *

есть не что иное, как некое подобие команды ls. В гл. 1 мы не отметили, что во избежание проблем с именами '.' и '..', которые присутствуют в любом каталоге, символы подстановки в именах файлов нельзя применять к именам файлов, начинающимся с точки. Правило таково: символы подстановки в именах файлов действуют на имена файлов, начинающихся с точки, только в том случае, если точка явно задана в шаблоне. Как обычно, "рассудительная" команда echo прояснит ситуацию:

$ ls

.profile

junk

temp

$ echo *

junk temp

$ echo .*

. .. .profile

$

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

Таблица 3.1: Метасимволы shell

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

$ echo '* * *'

* * *

$

Можно также использовать кавычки "...", но интерпретатор на самом деле "заглядывает" внутрь этих кавычек в поиске метасимволов $, '...' и \, так что не применяйте "...", если только вам не требуется определенным образом обработать строку в кавычках.

Еще одну возможность дает ввод обратной дробной черты перед каждым символом, который вы хотите закрыть от интерпретатора, например:

$ echo \*\*\*

Хотя строка \*\*\* не похожа на английское слово, в терминологии языка shell это слово, ибо им является любая последовательность символов, воспринимаемая интерпретатором как целое, включая даже пробелы, если они взяты в кавычки.

Кавычки одного вида могут экранировать кавычки другого вида:

$ echo "Don't do that!"

Don't do that!

$

и могут не заключать в себе весь аргумент:

$ echo x'*'y

x*y

$ echo '*'A'?'

*А?

$

В последнем примере команда echo получает один аргумент, не содержащий апострофов, так как, сделав свое дело, апострофы исчезают. Строки в кавычках могут содержать символы строк:

$ echo 'hello

> world'

hello

world

$

Символ > является вторичным приглашением интерпретатора, которое выдается, если ожидается продолжение ввода для завершения команды. В этом примере апостроф в первой строке должен быть уравновешен другим апострофом. Вторичное приглашение интерпретатора хранится в переменной PS2; его можно изменить по своему вкусу.

Во всех приведенных выше примерах экранирование специальных символов предохраняет их от интерпретации. Команда

$ echo x*y

выдает все имена файлов, начинающиеся с x и кончающиеся y. Как обычно, команда echo ничего "не знает" ни о файлах, ни о метасимволах; интерпретация *, если она требуется, осуществляется shell.

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

$ ls x*y

x*y not found Сообщение ls: таких файлов нет

$ >xyzzy      Создать файл xyzzy

$ ls x*y

xyzzy         Файл xyzzy соответствует x*y

$ ls 'х*y'

x*y not found ls не интерпретирует *

$

Появление обратной дробной черты в конце строки требует продолжения строки, что является способом задать интерпретатору очень длинную строку:

$ echo abc\

> def\

> ghi

abcdefghi

$

Обратите внимание на то, что символ перевода строки отбрасывается, если перед ним стоит обратная дробная черта, но он остается, если взят в кавычки. Метасимвол # в программе на языке shell практически всюду используется в качестве комментария; если слово начинается с #, остаток строки игнорируется:

$ echo hello#there

hello

$ echo hello # there

hello # there

$

Символ # не присутствует в оригинальной седьмой версии, но имеет очень широкое распространение, и в дальнейшем мы будем им пользоваться.

Упражнение 3.2

Объясните результат выполнения команды

$ ls .

Некоторые дополнительные сведения о команде echo

Команда echo выдает заключительный символ перевода строки, даже если на это нет явного запроса. Разумной и, возможно, более корректной была бы такая реализация команды echo, при которой вывод соответствовал бы только запросу. Добиться этого легко, если потребовать от интерпретатора выдачи приглашения:

$ правильное эхо введенная команда:

Введенная команда: $ Нет завершающего перевода строки

Однако при таком решении в самой распространенной ситуации, когда перевод строки нужен, он не подразумевается по умолчанию и требует дополнительного ввода:

$ правильное эхо 'Привет!

>'

Привет!

$

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

Но как быть, если это нежелательно? В седьмой версии системы команда echo имеет единственный флаг -n, который подавляет последний символ перевода строки:

$ echo -n Enter a command:

Enter a command: $ Приглашение на той же строке

$ echo -

-                  Только - является специальным случаем

$

Существует одна маленькая хитрость в случае получения эха от -n, за которым должен следовать символ перевода строки:

$ echo -n '-n

>'

-n

$

Такое решение некрасиво, но эффективно, к тому же это довольно редкий случай.

Другой подход принят в System V, где команда echo интерпретирует последовательность символов с обратной дробной чертой аналогично тому, как это делается в языке Си, а именно: \b обозначает "шаг назад", \c подавляет перевод строки (правда, здесь не очень точно воспроизведена конструкция Си):

$ echo 'Введенная команда: \с' Версия System V

Введенная команда: $

Хотя при подобном решении не возникает коллизий при получении эха от знака "-", у него есть свои недостатки. Команда echo часто используется в качестве диагностического средства, а символ обратной дробной черты интерпретируется таким множеством программ, что участие в этом команды echo только вносит дополнительную путаницу.

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

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

UNIX и Эхо

Жила-была в стране Нью-Джерси UNIX, прекрасная девушка, к которой приезжали издалека, чтобы полюбоваться ею. Ослепленные чистотой UNIX, все искали ее руки и сердца: одни — за изящество, другие — за изысканную вежливость, третьи — за проворность при выполнении самых изнурительных заданий. Была она от рождения столь великодушна и услужлива, что все женихи остались довольны ею, а ее многочисленное потомство распространилось во все концы земли.

Сама природа покровительствовала UNIX и вторила ей более охотно, чем кому-либо из смертных. Простые люди поражались ее эхом, таким оно было точным и кристально чистым. Они не могли поверить, что ей отвечают те же леса и скалы, которые так искажают их собственные голоса. Когда один нетерпеливый пастушок попросил UNIX: "Пусть эхо ответит ничего", и она послушно открыла рот, эхо промолчало. "Зачем ты открываешь рот?" — спросил пастушок. — "Отныне никогда не открывай его, если эхо должно ответить ничего!" — и UNIX подчинилась.

"Но я хочу совершенного исполнения, даже если эхо отвечает ничего," — потребовал другой, обидчивый, юноша, — "а никакого совершенного эха не получится при закрытом рте". Не желая обидеть никого из них, UNIX согласилась говорить разные "ничего" для нетерпеливого и обидчивого юношей. Она называла "ничего" для обидчивого как ' \n' . Однако теперь, когда она говорила ' \n' , на самом деле она не произносила ничего, поэтому ей приходилось открывать рот дважды: один раз, чтобы сказать '\n' , и второй раз, чтобы не сказать ничего. Это не понравилось обидчивому юноше, который тотчас сказал: "Для меня '\n' звучит, как настоящее "ничего", но когда ты открываешь рот второй раз, то все портишь. Возьми второе "ничего" назад". Услужливая UNIX согласилась отказаться от некоторых эхо и обозначила это как '\c' . С тех пор обидчивый юноша мог услышать совершенное эхо "ничего", если он задавал '\n' и '\c' вместе, но говорят, что он так и не услышал его, поскольку умер от излишеств в обозначениях.

Упражнение 3.3

Предскажите, что сделает команда grep в каждом случае, а затем проверьте себя;

grep \$     grep \\

grep \\$    grep \\\\

grep \\\\$  grep "\$"

grep '\$'   grep '"$'

grep '\'$   grep "$"

Файл, состоящий из таких команд, послужит хорошим материалом для теста, если вы хотите поэкспериментировать.

Упражнение 3.4

Как указать grep , что нужно найти шаблон, начинающийся с '-' ? Почему взятие аргумента в кавычки не помогает? Подсказка: исследуйте флаг -е .

Упражнение 3.5

Рассмотрите команду

$ echo */*

Может ли она вывести все имена всех каталогов? В каком порядке появятся эти имена?

Упражнение 3.6

( Хитрый вопрос .) Как ввести / в локальное имя файла (т.е. символ / , который не является разделителем компонентов в абсолютном имени)?

Упражнение 3.7

Что произойдет в случае ввода команд $ cat x y >y и $ cat x >>x

Подумайте, прежде чем броситься их выполнять.

Упражнение 3.8

Если вы введете

$ rm *

почему команда rm не сможет предупредить вас, что вы собираетесь удалить все ваши файлы?

 

3.3 Создание новых команд

Теперь, как мы обещали вам в гл. 1, рассмотрим создание новых команд из старых. Имея последовательность команд, которую придется многократно повторять, преобразуем ее для удобства в "новую" команду со своим именем и будем использовать ее как обычную команду. Чтобы быть точными, предположим, что нам предстоит часто подсчитывать число пользователей с помощью конвейера

$ who | wc -l

(см. гл. 1), и для этой цели нужна новая программа nu.

Первым шагом должно быть создание обычного файла, содержащего 'who | wc -l'. Можно воспользоваться вашим любимым редактором или проявить изобретательность:

$ echo 'who | wc -l' >nu

(Что появится в файле nu, если не употреблять кавычки?)

Как отмечалось в гл. 1, интерпретатор является точно такой же программой, как редактор, who или wc; он называется sh. А коль скоро это программа, ее можно вызвать и переключить ее входной поток. Так что запускаем интерпретатор с входным потоком, поступающим из файла nu, а не с терминала:

$ who

you tty2 Sep 28 07:51 rhh tty4 Sep 28 10:02

moh tty5 Sep 28 09:38 ava tty6 Sep 28 10:17

$ cat nu who | wc -l

$ sh < nu

4

$

Результат получился таким же, каким бы он был при задании команды who | wc -l с терминала. Опять-таки, как и большинство программ, интерпретатор берет входной поток из файла, если он указан в качестве аргумента; вы с тем же успехом могли задать:

$ sh nu

Однако досадно вводить "sh" каждый раз; во всяком случае эта запись длиннее и создает различия между программами, написанными, например, на Си, и программами, написанными с помощью shell. Поэтому если файл предназначен для выполнения и если он содержит текст, то интерпретатор считает, что он состоит из команд. Такие файлы называются командными. Все, что вам нужно сделать, это объявить файл nu выполняемым, задав

$ chmod + x nu

а затем вы можете вызывать его посредством

$ nu

С этого момента те, кто используют файл nu, не смогут определить способ его создания.

Способ, с помощью которого интерпретатор на самом деле выполняет nu, сводится к созданию нового процесса интерпретатора, как если бы вы задали

$ sh nu

Этот процесс-потомок называется порожденным интерпретатором, т.е. процессом интерпретатора, возбужденным вашим текущим интерпретатором. Но команда sh nu — это не то же самое, что sh < nu, поскольку в первом случае стандартный входной поток все еще связан с терминалом. Пока команда nu выполняется только в том случае, если она находится в вашем текущем каталоге (при условии, конечно, что текущий каталог включен в PATH, а именно это мы и предполагаем с настоящего момента). Чтобы сделать команду nu частью вашего репертуара независимо от того каталога, с которым вы работаете, занесите ее в свой собственный каталог bin и добавьте /usr/you/bin к списку каталогов поиска:

$ pwd /usr/you

$ mkdir bin                 Создать bin, если его еще не было

$ echo $PATH                Проверить Path, чтобы убедиться

:/usr/you/bin:/bin:/usr/bin Должно быть нечто похожее

$ mv nu bin                 Установить команду nu в bin

$ ls nu

nu not found                Она действительно исчезла

из текущего каталога

$ nu

4                           Но интерпретатор ее находит

$

Конечно, ваша переменная PATH должна быть правильно определена в файле .profile, чтобы вам не приходилось переопределять ее при каждом входе в систему.

Существуют и другие простые команды, которые вы можете адаптировать к среде по своему вкусу и создавать таким же способом. Нам показалось удобным иметь следующие команды:

• cs для посылки подходящей последовательности специфических символов с целью очистки экрана вашего терминала (24 символа перевода строки — практически универсальное решение);

• what для запуска who и ps -а, чтобы сообщить, кто работает в системе и что он делает;

• where для вывода идентифицированного названия используемой системы UNIX. Это удобно, если вы постоянно работаете с несколькими версиями. (Установка PS1 служит для подобной цели.)

Упражнение 3.9

Просмотрите каталоги /bin и /usr/bin , чтобы выяснить, как много команд являются в действительности командными файлами. Можно ли это сделать с помощью одной команды? Подсказка: посмотрите file(1) . Насколько точно предположение, основанное на длине файла?

 

3.4 Аргументы и параметры команд

Хотя команда nu, как она задумывалась, удовлетворяет своему назначению, многие программы на языке shell могут обрабатывать аргументы, так что при их запуске можно задавать имена файлов и флаги.

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

$ cx nu

есть сокращенная запись для

$ chmod +x nu

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

chmod +x filename

Единственное, что требуется выяснить — как сообщить команде cx имя файла, так как при каждом запуске cx оно будет иным.

Если интерпретатор выполняет командный файл, то каждое вхождение $1 заменяется первым аргументом, каждое вхождение $2 — вторым и т.д. до $9. Поэтому если файл cx содержит строку

chmod +x $1

то при выполнении команды

$ cx nu

порожденный интерпретатор заменит "$1" на первый аргумент "nu". Рассмотрим всю последовательность операций:

$ echo 'chmod +x $1' >cx      Вначале создадим cx

$ sh cx сх                    Сделать сам файл cx выполняемым

$ echo echo Hi, there! >hello Приготовим тест

$ hello                       Попробуем

hello: cannot execute

$ cx hello                    Сделаем файл выполняемым

$ hello                       Попробуем снова

Hi, there!                    Работает

$ mv cx /usr/you/bin          Установим команду cx

$ rm hello                    Уберем ненужное

$

Заметьте, что мы задали

$ sh cx сх

в точности так, как сделал бы автоматически интерпретатор, если бы cx была выполняемой и можно было бы задать

$ cx сх

А как быть, если нужно работать с несколькими аргументами, например, заставить программу cx воздействовать сразу на несколько файлов? Прямолинейное решение состоит в том, чтобы включить девять аргументов в командный файл:

chmod +x $1 $2 $3 $4 $5 $6 $7 $8 $9

(Это годится только для девяти аргументов, так как конструкция $10 распознается как "первый аргумент, за которым следует 0"!) Если пользователь такого командного файла задаст меньше девяти аргументов, то недостающие окажутся пустыми строками. Это приведет к тому, что только настоящие аргументы будут переданы chmod порожденным интерпретатором. Такое решение, конечно, приемлемо, но не вполне корректно и не подходит для случая с числом аргументов более девяти.

С учетом упомянутой выше трудности интерпретатор предоставляет сокращенную запись $*, означающую "все аргументы". В этом случае правильно определить cx:

chmod +x $*

что является эффективным при любом числе аргументов.

Используя $* в своем репертуаре, вы можете создать некоторые полезные командные файлы, такие, как lc или m:

$ cd /usr/you/bin

$ cat lc

#lc: подсчет числа строк в файлах

wc -l $*

$ cat m

#m: точный способ послать почту

mail $*

$

Обе команды можно осмысленно использовать и без аргументов. Если нет аргументов, $* будет пустым, и wc и mail вообще не получат никаких аргументов. С аргументами или без них команда вызывается правильно:

$ lc /usr/you/bin/*

 1 /usr/you/bin/cx

 2 /usr/you/bin/lc

 2 /usr/you/bin/m

 1 /usr/you/bin/nu

 2 /usr/you/bin/what

 1 /usr/you/bin/where

 9 total

$ ls /usr/you/bin | lc

 6

$

Эти и другие команды, описываемые в настоящей главе, являются командами пользователя, т.е. вы создаете их для себя и помещаете в свой каталог /bin, поэтому вряд ли они должны стать общедоступными. В гл. 5 мы исследуем вопрос создания общедоступных программ на языке shell.

Аргументами командного файла не обязательно должны быть имена файлов. Рассмотрим в качестве примера поиск в каталоге, где хранится личный телефонный справочник. Если у вас есть файл с именем /usr/you/lib/phone-book, содержащий строки следующего вида:

dial-a-joke      212-976-3838

dial-a-prayer    212-246-4200

dial santa       212-976-3636

dow jones report 212-976-4141

то для поиска в нем можно воспользоваться командой grep. (Ваш собственный каталог lib — хорошее хранилище таких частных баз данных.) Поскольку команда grep не определяет формат информации, можно искать имена, адреса, индексы или еще какие-нибудь нужные вам сведения. Составим справочную программу для каталога, которой дадим имя 411 по номеру одной из телефонных справочных служб:

$ echo 'grep $* /usr/you/lib/phone-book' > 411

$ cx 411

$ 411 joke

dial-a-joke      212-976-3838

$ 411 dial

dial-a-joke      212-976-3838

dial-a-prayer    212-246-4200

dial santa       212-976-3636

$ 411 'dow jones'

grep: can't open jones Что-то не так

$

Последний пример вскрывает потенциальную проблему: хотя dow jones представляет для команды 411 единый аргумент, он содержит пробел и уже не заключен в апострофы, поэтому порожденный интерпретатор, выполняющий команду 411, преобразует его в два аргумента для grep, как если бы вы задали

$ grep dow jones /usr/you/lib/phone-book

что, очевидно, неверно.

Один из возможных путей обойти эту проблему основан на том, как интерпретатор трактует кавычки. Хотя все, что заключено в '...', не затрагивается, интерпретатор "заглядывает" внутрь "..." в поиске комбинаций с $, \, `...`. Поэтому если изменить команду 411 следующим образом:

$ grep "$*" /usr/you/lib/phone-book

то $* заменяется на аргументы, но команде grep передается как один аргумент, даже при наличии пробелов:

$ 411 dow jones

dow jones report 212-976-4141

$

Кстати, можно сделать с помощью флага -y команду grep (а значит, и 411) независимой от использования строчных или прописных букв:

$ grep -y pattern ...

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

Более подробно аргументы команд мы рассмотрим в гл. 5, но одно важное замечание необходимо сделать здесь. Аргумент $0 — это имя выполняемой программы; в случае cx $0 есть "cx". Новое применение $0 находит в реализации программ 2, 3, 4, …, которые печатают свой выходной поток в несколько столбцов:

$ who | 2

drh tty0 Sep 28 21:23 cvw tty5 Sep 28 21:09

dmr tty6 Sep 28 21:10 scj tty7 Sep 28 22:11

you tty9 Sep 28 23:00 jib ttyb Sep 28 19:58

$

Реализация команд 2, 3, … идентична. По существу, они являются связями с одним файлом:

$ ln 2 3; ln 2 4; ln 2 5; ln 2 6

$ ls -l [1-9]

167222 -rwxrwxrwx 5 you 51 Sep 28 23:21 2

167222 -rwxrwxrwx 5 you 51 Sep 28 23:21 3

167222 -rwxrwxrwx 5 you 51 Sep 28 23:21 4

167222 -rwxrwxrwx 5 you 51 Sep 28 23:21 5

167222 -rwxrwxrwx 5 you 51 Sep 28 23:21 6

$ ls /usr/you/bin | 5

2    3     4    411   5

6    cx    lc   m     nu

what where

$ cat 5

# 2, 3, ...: печать в n столбцов

pr -$0 -t -11 $*

$

Флаг -t убирает заголовки в начале страницы, а флаг -ln устанавливает размер страницы равным n строк. Имя программы становится числом столбцов, т.е. аргументов для команды pr, так что выходной поток печатается строками по несколько столбцов, число которых определено аргументом $0.

 

3.5 Результат выполнения программы в качестве аргумента

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

$ echo At the tone the time will be `date`.

At the tone the time will be Thu Sep 29 00:02:15 EDT 1983.

$

Небольшое изменение показывает, что `...` интерпретируется и внутри кавычек "...":

$ echo "At the tone

> the time will be `date`."

At the tone

the time will be Thu Sep 29 00:03:07 EDT 1983.

$

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

$ mail `cat mailinglist`

Запуск команды cat порождает список имен пользователей, и эти имена становятся аргументами команды mail. (При обработке результата выполнения команды, помещенной между знаками слабого ударения и используемой в качестве аргумента, интерпретатор считает символы перевода строки разделителями слов, а не символами завершения командной строки; подробнее данный вопрос обсуждается в гл. 5.) Работать со знаками слабого ударения нетрудно, и поэтому, действительно, нет нужды вводить отдельный флаг команды mail, задающий список адресатов.

Несколько иной подход требуется для преобразования файла mailinglist из простого списка имен в программу, выдающую список имен:

$ cat mailinglist

echo don whr ejs mb Новая версия

$ cx mailinglist

$ mailinglist

don whr ejs mb

$

Теперь посылка писем адресатам из списка реализуется командой:

$ mail `mailinglist`

Добавив еще одну программу, получим возможность даже изменять список пользователей в диалоге. Такая программа называется pick:

$ pick аргументы...

и выдает свои аргументы по одному, ожидая каждый раз ответа. Результатом действия команды pick являются те аргументы, на которые был дан ответ y (yes — да); при всяком другом ответе аргумент отбрасывается. Например,

$ pr `pick *.с` | lpr

Здесь вначале выдаются имена файлов, оканчивающиеся на .с. Выбранные имена печатаются с помощью команд pr и lpr. (Команда pick не входит в состав команд седьмой версии, но она столь проста и полезна, что мы включили ее варианты в гл. 5 и 6).

Допустим, вы используете второй вариант команды mailinglist. Тогда посылка писем адресатам don и mb выглядит так:

$ mail `pick \`mailinglist\``

don? y

whr?

ejs?

mb? y

$

Обратите внимание на вложенные знаки слабого ударения; обратная дробная черта запрещает обработку вложенной конструкции `...` при разборе внешних знаков слабого ударения.

Упражнение 3.10

Что произойдет, если опустить символы обратной дробной черты в команде

$ echo `echo \`date\``

Упражнение 3.11

Попробуйте ввести

$`date`

и объясните результат.

Упражнение 3.12

Команда

$ grep -l pattern filenames

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

$ command `grep -l pattern filenames`

 

3.6 Переменные языка

shell

Подобно большинству языков программирования, shell имеет переменные, которые на программистском жаргоне называются параметрами. Такие строки, как $1, являются позиционными параметрами-переменными, хранящими аргументы командного файла. Цифра показывает положение параметра в командной строке. Ранее мы имели дело с другими переменными языка shell: PATH — список каталогов, в которых происходит поиск команд, НОМЕ — ваш начальный каталог и т.д. В отличие от переменных в обычном языке переменные, задающие позиционные параметры, не могут быть изменены; хотя PATH представляет собой переменную со значением $PATH, нет переменной 1 со значением $1, т.е. $1 — это не что иное, как компактное обозначение первого аргумента.

Если забыть о позиционных параметрах, переменные языка shell можно создавать, выбирать и изменять. Например,

$ PATH=:/bin:/usr/bin

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

$ PATH=$PATH:/usr/games

$ echo $PATH

:/usr/you/bin:/bin:/usr/bin:/usr/games

$ PATH=:/usr/you/bin:/bin:/usr/bin Восстановим значение

$

He все переменные имеют специальное значение для интерпретатора. Можно создавать новые переменные, присваивая им значения. По традиции переменные, имеющие специальное значение, обозначаются прописными буквами, а обычные переменные — строчными. Типичным примером использования переменных является хранение в них длинных строк, таких, как имена файлов:

$ pwd

/usr/you/bin

$ dir=`pwd`        Запомним, где находимся

$ cd /usr/mary/bin Перейдем в другое место

$ ln $dir/cx .     Используем переменную в имени файла

$ ...              Поработаем некоторое время

$ cd $dir          Вернемся

$ pwd

/usr/you/bin

$

Встроенная в интерпретатор команда set показывает значения всех определенных вами переменных. Для просмотра одной или двух переменных более подходит команда echo:

$ set

HOME=/usr/you

IFS=

PATH=:/usr/you/bin:/bin/:/usr/bin

PS1=$

PS2=>

dir=/usr/you/bin

$ echo $dir

/usr/you/bin

$

Значение переменной связано с той копией интерпретатора, который создал ее, и автоматически не передается процессам — потомкам интерпретатора.

$ x=Hello Создание x

$ sh      Новый shell

$ echo $x Происходит только перевод строки,

 x не определено в порожденном интерпретаторе

$ ctl-d   Возврат в исходный интерпретатор

$ echo $x

Hello     x по-прежнему определено

$

Это означает, что в командном файле нельзя изменить значение переменной, поскольку выполнением командного файла управляет порожденный интерпретатор:

$ echo 'x="Good bye" Создание shell-файла из двух строк…

> echo $x' >setx     …для определения и печати x

$ cat setx

x="Good Bye"

echo $x

$ echo $x

Hello                x есть Hello в исходном интерпретаторе

$ sh setx

Good Bye             x есть Good Bye в порожденном интерпретаторе…

$ echo $x

Hello                …но по-прежнему есть Hello в текущем интерпретаторе

$

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

$ cat /usr/you/bin/games

PATH=$PATH:/usr/games Добавим /usr/games к PATH

$ echo $PATH

:/usr/you/bin:/bin:/usr/bin

$ . games

$ echo $PATH

:/usr/you/bin:/bin:/usr/bin:/usr/games

$

Поиск файла для команды '.' осуществляется с помощью переменной PATH, так что его можно поместить в ваш каталог bin.

Когда используется команда '.', только условно можно считать, что выполняется командный файл. Файл не "выполняется" в обычном смысле этого слова. Команды из него запускаются, как если бы вы ввели их в диалоговом режиме: стандартный входной поток интерпретатора временно переключается на файл. Поскольку файл читается, не нужно иметь право на его выполнение. Другое отличие состоит в том, что файл не получает аргументов командной строки; $1, $2 и т.д. являются пустыми строками. Было бы неплохо, если бы аргументы передавались, но этого не происходит.

Есть еще один способ установить значение переменной в порожденном интерпретаторе — присвоить его явно в командной строке перед самой командой:

$ echo 'echo $x' >echox

$ cx echox

$ echo $x

Hello Как и прежде

x не определено в порожденном интерпретаторе

$ x=Hi echox

Hi    Значение x передается порожденному интерпретатору

$

(Первоначально присваивания всюду в командной строке передавались команде, но это противоречило dd(1).)

Операцию '.' следует использовать, чтобы навсегда изменить значение переменной, тогда как присваивания в командной строке предназначены для временных изменений. В качестве примера рассмотрим еще раз поиск команд в каталоге /usr/games, не указанном в вашей переменной PATH:

$ ls /usr/games | grep fort

fortune Игровая команда fortune

$ fortune

fortune: not found

$ echo $PATH

:/usr/you/bin:/bin:/usr/bin /usr/games не входит в PATH

$ PATH=/usr/games fortune

Позвони в звонок; закрой книгу; задуй свечу.

$ echo $PATH

:/usr/you/bin:/bin:/usr/bin PATH не изменилось.

$ cat /usr/you/bin/games    команда games все еще здесь

$ . games

$ fortune

Непродуманная оптимизация - источник всех бед - Кнут

$ echo $PATH

:/usr/you/bin:/bin:/usr/bin:/usr/games Сейчас PATH изменилось

$

Можно использовать оба средства в одном командном файле. Вы можете несколько видоизменить команду games для запуска одной игровой программы без изменения переменной PATH или постоянно переопределять PATH, чтобы она включала /usr/games:

$ cat /usr/you/bin/games

PATH=$PATH:/usr/games $*    Обратите внимание на $*

$ cx /usr/you/bin/games

$ echo $PATH

:/usr/you/bin:/bin:/usr/bin /usr/games не входит

$ games fortune

Готов отдать свою правую руку, чтобы одинаково владеть обеими

$ echo $PATH

:/usr/you/bin:/bin:/usr/bin Все еще не входит

$ . games

$ echo $PATH

:/usr/you/bin:/bin:/usr/bin:/usr/games Теперь входит

$ fortune

Тот, кто медлит, иногда спасается

$

При первом обращении к games командный файл выполняется в порожденном интерпретаторе, в котором переменная PATH временно изменена так, чтобы включать каталог /usr/games. В то же время во втором примере файл обрабатывается текущим интерпретатором при значении $*, являющемся пустой строкой, поэтому в строке нет команд и переменная PATH изменяется. Применение команды games в обоих случаях достаточно нетривиально, но в результате получаем удобное и естественное для использования средство.

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

$ x=Hello

$ export x

$ sh           Новый интерпретатор

$ echo $x

Hello          x доступно в порожденном интерпретаторе

$ x='Good Bye' Изменим значение x

$ echo $x

Good Bye

$ ctl-d        Выйдем из порожденного интерпретатора

$              Снова в исходном интерпретаторе

$ echo $x

Hello          x по-прежнему Hello

$

Семантика команды export нетривиальна, но по крайней мере для повседневных нужд достаточно придерживаться основного правила: никогда не экспортируйте временные переменные, служащие для краткосрочных целей, и всегда экспортируйте переменные, необходимые вам во всех порожденных интерпретаторах (включая, например, интерпретаторы, запускаемые командой ! редактора ed). Поэтому переменные, имеющие специальное значение для интерпретатора, такие, как PATH и НОМЕ, следует экспортировать.

Упражнение 3.13

Почему в значение переменной PATH всегда включается текущий каталог? Куда его нужно поместить?

 

3.7 Еще раз о переключении ввода-вывода

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

$ diff file1 file2 >diff.out

diff: file2: No such file or directory

$

Без сомнения, сообщения об ошибке должны появляться подобным образом — было бы крайне неприятно, если бы они исчезли в файле diff.out, оставляя вас в уверенности, что ошибочная команда diff выполнена правильно.

В начале выполнения каждой программы определены по умолчанию три файла, обозначаемые небольшими целыми числами и называемые дескрипторами файла (мы рассмотрим их в гл. 7). Со стандартными входным (0) и выходным (1) потоками вы уже знакомы: они часто переключаются на файл или программный канал. Последний поток с номером 2 представляет собой стандартный поток диагностики и обычно предназначается для вывода на терминал.

Иногда программы осуществляют вывод в стандартный поток диагностики, даже если они работают правильно. Типичным примером является программа time, которая выполняет команду и выдает в стандартный поток диагностики сообщение о том, сколько времени заняло выполнение:

$ time wc ch3.1

931 4288 22691 ch3.1

real 1.0

user 0.4

sys  0.4

$ time wc ch3.1 >wc.out

real 2.0

user 0.4

sys  0.3

$ time wc ch3.1 >wc.out 2>time.out

$ cat time.out

real 1.0

user 0.4

sys  0.3

$

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

Допустимо также слияние двух выходных потоков:

$ time wc ch3.1 >wc.out 2>&1

$ cat wc.out

931 4288 22691 ch3.1

real 1.0

user 0.4

sys  0.3

$

Обозначение 2>&1 является указанием интерпретатору, что стандартный поток диагностики нужно поместить в тот же поток, что и стандартный выходной. Амперсанд не содержит какого-либо мнемонического смысла; это просто идиома, которую следует запомнить. Для добавления стандартного выходного потока к стандартному потоку диагностики можно использовать 1>&2:

echo ... 1>&2

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

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

$ cat 411

grep "$*" <

dial-a-joke      212-976-3838

dial-a-prayer    212-246-4200

dial santa       212-976-3636

dow jones report 212-976-4141

End

$

Программирующие на языке shell называют такую конструкцию "документ здесь", т.е. входной поток находится здесь, а не в каком-нибудь файле. Началом конструкции служит <<; последующее слово (в нашем примере End) является ограничителем входного потока, включающего все строки до той, которая содержит только данное слово. Интерпретатор выполняет замену конструкций $, `...` и \ в "документе здесь", если только часть слова не экранирована кавычками или обратной дробной чертой, — в этом случае весь документ берется без изменений. В конце главы мы рассмотрим еще более интересный пример с конструкцией "документ здесь".

В табл. 3.2 перечислены различные виды переключения ввода-вывода, допускаемые интерпретатором.

Таблица 3.2: Переключение ввода-вывода интерпретатора

Упражнение 3.14

Сравните версии программы 411: использующую "документ здесь" и первоначальную. Какую легче сопровождать? Какая более подходит в качестве основы общего служебного средства?

 

3.8 Циклы в shell-программах

Язык shell — действительно язык программирования: в нем есть переменные, циклы, ветвления и т.п. Здесь мы обсудим основные циклы, а структуры управления рассмотрим более подробно в гл. 5.

Типичным считается цикл по последовательности имен файлов, и оператор for языка shell является единственной структурой управления, которую обычно задают с терминала, а не помещают в файл для последующего выполнения. Синтаксис оператора for таков:

for перем in список_слов

do

 команды

done

Например, для получения эха имен файлов по одному на строке достаточно задать:

$ for i in *

> do

>  echo $i

> done

Вместо i можно применять любую переменную языка shell, но это обозначение традиционно. Заметьте, что значение переменной получается с помощью $i, однако в заголовке цикла переменную указывают как i. Мы задействовали * для выбора всех файлов текущего каталога, но можно использовать и любой другой список аргументов. Обычно нужно сделать что-нибудь более интересное, чем печать имен файлов. Нам часто приходилось сравнивать набор файлов с их предыдущими версиями, например старую версию гл. 2 (хранимую в каталоге old) с текущей:

$ ls ch2. * | 5

ch2.1 ch2.2 ch2.3 ch2.4 ch2.5

ch2.6 ch2.7

$ for i in ch2.*

> do

>  echo $i

>  diff -b old/$i $i

> echo Добавим пустую строку для красоты

> done | pr -h "diff `pwd`/old `pwd` | lpr &

3712   Номер процесса

$

Выходной поток направлен по конвейеру через команды pr и lpr просто для того, чтобы показать, что это возможно: стандартный выходной поток программ, находящихся внутри цикла for, попадает в стандартный выходной поток самой команды for. С помощью флага -h в команде pr мы поместили в выходной поток заголовок с "архитектурными излишествами", используя два вложенных обращения к pwd. Вся последовательность команд запущена асинхронно (&), так что не нужно ждать ее окончания; & применяется ко всякому циклу и конвейеру.

Мы предпочитаем указанный формат для цикла for, но вы можете сократить его. Единственное ограничение заключается в том, что do и done распознаются как ключевые слова, только если они появляются сразу после перевода строки или точки с запятой. В зависимости от размера цикла for иногда лучше помещать все на одной строке:

for i in список; do команды; done

Следует использовать цикл for для обработки составных команд или в тех случаях, когда не подходит встроенная обработка отдельных команд. Но не применяйте его там, где в отдельной команде есть цикл по именам файлов:

# Плохая идея:

for i in $*

do

 chmod +x $i

done

Предпочтительнее сделать так:

chmod +x $*

поскольку в цикле for отдельная команда chmod выполняется для каждого файла, что требует больших вычислительных ресурсов. (Убедитесь в том, что вы понимаете разницу между командами

for i in *

в которой цикл выполняется по всем именам файлов текущего каталога, и

for i in $*

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

Список аргументов для цикла for часто получают путем выбора имен файлов по шаблону, но можно получать и любым другим способом, в частности:

for i in `cat ...`

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

$ for i in 3 4 5 6; do ln 2 $i; done

$

Цикл for имеет и более интересное назначение. Выберем с помощью команды pick те файлы, которые будут сравниваться с файлами из каталога старых версий:

$ for i in `pick ch2.*`

> do

>  echo $i:

>  diff old/$i $i

> done | pr | lpr

ch2.1? y

ch2.2

ch2.3

ch2.4? y

ch2.5? y

ch2.6?

ch2.7?

$

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

Упражнение 3.15

Если цикл с командой diff хранится в командном файле, поместите ли вы туда команду pick? Объясните, почему.

Упражнение 3.16

Что произойдет, если последняя строка приведенного цикла будет иметь вид:

> done | pr | lpr &

т.е. кончаться амперсандом? Попробуйте сделать прогноз, а затем проверьте его.

 

3.9 Программа

bundle

: соберем все воедино

Чтобы лучше понять, как создаются командные файлы, обратимся к такому примеру. Предположим, вы получили почту от приятеля с другой машины: "где-то!боб" (Существует несколько вариантов обозначений для адресата на другой машине. Наиболее общим является следующее: машина!пользователь. См. справочное руководство по mail(1)), и он хотел бы скопировать командные файлы из вашего каталога bin. Самый простой способ их пересылки заключается в ответной почте, так что вы могли бы начать вводить:

$ cd /usr/you/bin

$ for i in `pick *`

> do

>  echo ============== Это файл $i ==============

>  cat $i

> done | mail где-то!боб

$

Однако посмотрим на это с точки зрения адресата "где-то!боб": он должен получить почту, в которой все файлы четко разделены, но ему придется воспользоваться редактором для разбивки сообщений на отдельные файлы. Для того чтобы адресату ничего не надо было делать, почтовое сообщение, построенное подходящим образом, должно автоматически распаковать себя, а значит, оно должно быть командным файлом, содержащим и сами файлы, и операции по их распаковке. Вторая идея заключается в том, что конструкция языка shell "документ здесь" является удобным способом задания информации для команды при ее запуске. Тогда остальная часть задачи сводится к тому, чтобы правильно расставить кавычки. Ниже приведена работающая программа bundle, которая группирует файлы в выходной поток самодокументированного командного файла:

$ cat bundle

# bundle: группирует файлы в распределенный пакет

echo '# Для разбиения на файлы вызовите sh с этим файлом'

for i

do

 echo "echo $i 1>&2"

 echo "cat >$i <<'End of $i'"

 cat $i

 echo "End of $i"

done

$

Поскольку мы взяли в кавычки "End of $i", любые метасимволы из файлов будут игнорироваться.

Естественно, что вам следует выполнить пробный запуск программы, чтобы не нанести ущерб адресату "где-то!боб":

$ bundle cx lc >junk                Пробный запуск bundle

$ cat junk

# Для разбиения на файлы вызовите sh с этим файлом

echo cx 1>&2

cat >cx <<'End of cx'

chmod +x сх

End of cx

echo lc 1>&2

cat >lc <<'End of lc'

# lc: подсчет числа строк в файлах

wc -l $*

End of lc

$ mkdir test

$ sh ../junk                        Попробуем

cx

lc

$ ls

cx

lc

$ cat cx

chmod +x $*

$ cat lc

# lc: подсчет числа строк в файлах

wc -l $* Похоже верно

$ cd ..

$ rm junk test/*; rmdir test        Удалим ненужное

$ pwd

/usr/you/bin

$ bundle `pick *` | mail где-то!боб Посылка файлов

$

Здесь могут возникнуть трудности, если окажется, что один из посылаемых файлов содержит строку вида

End of имя_файла

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

Программа bundle является хорошим примером приспособляемости программного мира UNIX: в ней используются циклы языка shell, переключение ввода-вывода, конструкция "документ здесь" и командные файлы. Она непосредственно обращается к команде mail, и, что особенно интересно, порождает программу. Это одна из самых "красивых" среди известных вам shell-программ: файл в несколько строк предлагает простое и элегантное решение.

Упражнение 3.17

Как бы вы использовали bundle для посылки всех файлов с учетом вложенных каталогов? Подсказка : командные файлы могут быть рекурсивными.

Упражнение 3.18

Модифицируйте программу bundle так, чтобы к каждому файлу она добавляла информацию, выведенную командой ls -l , в частности права доступа и время его последнего изменения. Сравните возможности bundle и архивной программы ar(1) .

 

3.10 Для чего нужно программировать на языке shell!

Программа shell системы UNIX не относится к типичным интерпретаторам команд, хотя и дает возможность запускать команды обычным способом. Тем не менее это язык программирования, который позволяет достичь большего. Имеет смысл сделать ретроспективный обзор данной главы, поскольку здесь приведен довольно обширный материал, и, кроме того (что является главной причиной), мы обещали вам обсудить "средства общего пользования", а затем увлеклись примерами программирования на языке shell. Дело в том, что используя язык shell, вы все время пишите маленькие, практически однострочные программы, в частности конвейер — это программа, равноценная фразе "Чай готов". Однако вы выполняете свою работу так легко и естественно (если умеете), что даже не считаете ее программированием.

Интерпретатор дает вам такие средства, как циклы, переключение ввода-вывода с помощью < и >, порождение имен файлов с помощью *, причем применение этих средств единообразно во всех программах. Некоторые средства, например командные файлы и программные каналы, на самом деле обеспечиваются ядром, но язык shell предоставляет естественную запись для их создания. Они не только удобны, но и увеличивают мощность системы в целом.

Базой для интерпретатора служит ядро системы UNIX, например, хотя интерпретатор и определяет конвейеры, именно ядро осуществляет передачу данных по ним. Способ, которым система обрабатывает выполняемые файлы, позволяет программировать командные файлы так, чтобы они выполнялись подобно оттранслированным программам. Пользователь не должен думать о том, что это командные файлы, — для передачи их на выполнение не требуется специальная команда типа RUN. Сам интерпретатор является программой, а не частью ядра. Его можно настраивать, расширять и обращаться с ним, как с любой другой программой. Такой подход не является уникальным, но здесь он реализован полнее, чем где бы то ни было.

В гл. 5 мы вернемся к теме программирования на языке shell, а пока запомните: вне зависимости от того, как вы работаете с интерпретатором, вы программируете на его языке (чем в основном и объясняются его достоинства).

Историческая и библиографическая справка

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

Седьмая версия интерпретатора была создана С. Боурном, которому оказал помощь и идейную поддержку Д. Мэшей. Как вы увидите в гл. 5, здесь есть все необходимое для программирования. Кроме того, реорганизована работа с входным и выходным потоками: теперь можно без ограничения переключать ввод-вывод из командных файлов и в них. Неотъемлемым свойством интерпретатора является обработка метасимволов в именах файлов; в ранних версиях, которые остались лишь на очень маленьких машинах, она реализовывалась отдельной программой.

Другой вариант интерпретатора, с которым вы могли встречаться (а может быть, вы предпочитаете с ним работать) — csh , так называемый Си- shell , созданный Б. Джоем на базе интерпретатора шестой версии. По сравнению с интерпретатором Боурна этот интерпретатор лучше обеспечивает диалог. Он предоставляет средство "история", позволяющее повторять в сокращенной записи (возможно, с небольшим редактированием) предварительно введенные команды. Отличается также и синтаксис команд интерпретатора Джоя. Но, поскольку Си- shell , базируется на интерпретаторе ранней версии, в нем содержится меньше средств для программирования; это скорее диалоговый интерпретатор команд, чем язык программирования. В частности, исключена передача по программному каналу из (или в) командного файла со структурами управления.

Команда pick предложена Т. Даффом, а команда bundle — независимо А. Хьитом и Д. Гослингом.