Просмотр кода страницы Advanced Bash-Scripting Guide

'''Advanced Bash-Scripting Guide'''

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

Автор: Mendel Cooper

Версия 2.8.7 (22 Августа 2004)

thegrendel@theriver.com

Перевод: Андрей Киселев

kis_an@mail.ru

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

Последнюю версию документа, в виде [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#BZIPREF .bz2] архива, содержащем исходные тексты в формате SGML и HTML, вы найдете на [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html домашней страничке автора]. Там же вы найдете и [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html change log].

== Часть 1. Введение ==

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

=== Глава 1. Зачем необходимо знание языка Shell? ===
Знание языка командной оболочки является залогом успешного решения задач администрирования системы. Даже если вы не предполагаете заниматься написанием своих сценариев. Во время загрузки Linux выполняется целый ряд сценариев из /etc/rc.d, которые настраивают конфигурацию операционной системы и запускают различные сервисы, поэтому очень важно четко понимать эти скрипты и иметь достаточно знаний, чтобы вносить в них какие либо изменения.

Язык сценариев легок в изучении, в нем не так много специфических операторов и конструкций. <ref>Их так же называют [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#BUILTINREF встроенными] конструкциями языка командной оболочки shell.</ref>. Синтаксис языка достаточно прост и прямолинеен, он очень напоминает команды, которые приходится вводить в командной строке. Короткие скрипты практически не нуждаются в отладке, и даже отладка больших скриптов отнимает весьма незначительное время.

Shell-скрипты очень хорошо подходят для быстрого создания прототипов сложных приложений, даже не смотря на ограниченный набор языковых конструкций и определенную "медлительность". Такая метода позволяет детально проработать структуру будущего приложения, обнаружить возможные "ловушки" и лишь затем приступить к кодированию на C, C++, Java, или Perl.

Скрипты возвращают нас к классической философии UNIX -- "разделяй и влавствуй" т.е. разделение сложного проекта на ряд простых подзадач. Многие считают такой подход наилучшим или, по меньшей мере, наиболее эстетичным способом решения возникающих проблем, нежели использование нового поколения языков -- "все-в-одном", таких как Perl.

Для каких задач неприменимы скрипты

*для ресурсоемких задач, особенно когда важна скорость исполнения (поиск, сортировка и т.п.)
*для задач, связанных с выполнением математических вычислений, особенно это касается вычислений с плавающей запятой, вычислений с повышенной точностью, комплексных чисел (для таких задач лучше использовать C++ или FORTRAN)
*для кросс-платформенного программирования (для этого лучше подходит язык C)
*для сложных приложений, когда структурирование является жизненной необходимостью (контроль за типами переменных, прототипами функций и т.п.)
*для целевых задач, от которых может зависеть успех предприятия.
*когда во главу угла поставлена безопасность системы, когда необходимо обеспечить целостность системы и защитить ее от вторжения, взлома и вандализма.
*для проектов, содержащих компоненты, очень тесно взаимодействующие между собой.
*для задач, выполняющих огромный объем работ с файлами
*для задач, работающих с многомерными массивами
*когда необходимо работать со структурами данных, такими как связанные списки или деревья
*когда необходимо предоставить графический интерфейс с пользователем (GUI)
*когда необходим прямой доступ к аппаратуре компьютера
*когда необходимо выполнять обмен через порты ввода-вывода или сокеты
*когда необходимо использовать внешние библиотеки
*для проприетарных, "закрытых" программ (скрипты представляют из себя исходные тексты программ, доступные для всеобщего обозрения)

Если выполняется хотя бы одно из вышеперечисленных условий, то вам лучше обратиться к более мощным скриптовым языкам программирования, например Perl, Tcl, Python, Ruby или к высокоуровневым компилирующим языкам -- C, C++ или Java. Но даже в этом случае, создание прототипа приложения на языке shell может существенно облегчить разработку.

Название BASH -- это аббревиатура от "Bourne-Again Shell" и игра слов от, ставшего уже классикой, "Bourne Shell" Стефена Бурна (Stephen Bourne). В последние годы BASH достиг такой популярности, что стал стандартной командной оболочкой de facto для многих разновидностей UNIX. Большинство принципов программирования на BASH одинаково хорошо применимы и в других командных оболочках, таких как Korn Shell (ksh), от которой Bash позаимствовал некоторые особенности, <ref>Многие особенности ksh88 и даже ksh93 перекочевали в Bash.</ref> и C Shell и его производных. (Примечательно, что C Shell не рекомендуется к использованию из-за отдельных проблем, отмеченных Томом Кристиансеном (Tom Christiansen) в октябре 1993 года на [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html Usenet post]

Далее, в тексте документа вы найдете большое количество примеров скриптов, иллюстрирующих возможности shell. Все примеры -- работающие. Они были протестированы, причем некоторые из них могут пригодиться в повседневной работе. Уважаемый читатель можеть "поиграть" с рабочим кодом скриптов, сохраняя их в файлы, с именами scriptname.sh. <ref>В соответствии с соглашениями, имена файлов с shell-скриптами, такими как Bourne shell и совместимыми, имеют расширение .sh. Все стартовые скрипты, которые вы найдете в /etc/rc.d, следуют этому соглашению.</ref> Не забудьте выдать этим файлам право на исполнение (chmod u+rx scriptname), после чего сценарии можно будет запустить на исполнение и проверить результат их работы. Вам следует помнить, что описание некоторых примеров следует после исходного кода этого примера, поэтому, прежде чем запустить сценарий у себя -- ознакомьтесь с его описанием.

Скрипты были написаны автором книги, если не оговаривается иное.

Если вы не можете самостоятельно написать скрипт, вы можете найти исполнителя на сайте [http://www.toptal.com/#hire-just-validated-hackers-today Toptal].

=== Глава 2. Для начала о Sha-Bang ===
В простейшем случае, скрипт -- это ни что иное, как простой список команд системы, записанный в файл. Создание скриптов поможет сохранить ваше время и силы, которые тратятся на ввод последовательности команд всякий раз, когда необходимо их выполнить.

''Пример 2-1. cleanup: Сценарий очистки лог-файлов в /var/log''
<syntaxhighlight lang="bash">
# cleanup
# Для работы сценария требуются права root.

cd /var/log
cat /dev/null > messages
cat /dev/null > wtmp
echo "Лог-файлы очищены."
</syntaxhighlight>
Здесь нет ничего необычного, это простая последовательность команд, которая может быть набрана в командной строке с консоли или в xterm. Преимущество размещения последовательности команд в скрипте состоит в том, что вам не придется всякий раз набирать эту последовательность вручную. Кроме того, скрипты легко могут быть модифицированы или обобщены для разных применений.

''Пример 2-2. cleanup: Расширенная версия предыдущего сценария.''
<syntaxhighlight lang="bash">
#!/bin/bash
# cleanup, version 2
# Для работы сценария требуются права root.

LOG_DIR=/var/log
ROOT_UID=0     # Только пользователь с $UID 0 имеет привилегии root.
LINES=50       # Количество сохраняемых строк по-умолчанию.
E_XCD=66       # Невозможно сменить каталог?
E_NOTROOT=67   # Признак отсутствия root-привилегий.


if [ "$UID" -ne "$ROOT_UID" ]
then
  echo "Для работы сценария требуются права root."
  exit $E_NOTROOT
fi

if [ -n "$1" ]
# Проверка наличия аргумента командной строки.
then
  lines=$1
else
  lines=$LINES # Значение по-умолчанию, если число не задано в командной строке
fi


#  Stephane Chazelas предложил следующее,
#+ для проверки корректности аргумента, переданного из командной строки,
#+ правда это достаточно сложно для данного руководства.
#
#    E_WRONGARGS=65  # Не числовой аргумент
#
#    case "$1" in
#    ""      ) lines=50;;
#    *[!0-9]*) echo "Usage: `basename $0` file-to-cleanup"; exit $E_WRONGARGS;;
#    *       ) lines=$1;;
#    esac
#
#* Конец проверки корректности аргумента


cd $LOG_DIR

if [ `pwd` != "$LOG_DIR" ]  # или   if [ "$PWD" != "$LOG_DIR" ]
                            # Не в /var/log?
then
  echo "Невозможно перейти в каталог $LOG_DIR."
  exit $E_XCD
fi  # Проверка каталога перед очисткой лог-файлов.

# более эффективный вариант:
#
# cd /var/log || {
#   echo "Невозможно перейти в требуемый каталог." >&2
#   exit $E_XCD;
# }


tail -$lines messages > mesg.temp # Сохранить последние строки в лог-файле.
mv mesg.temp messages


# cat /dev/null > messages
#* Необходимость этой команды отпала, поскольку очистка выполняется выше.

cat /dev/null > wtmp  #  команды ': > wtmp' и '> wtmp'  имеют тот же эффект.
echo "Лог-файлы очищены."

exit 0
#  Возвращаемое значение 0
#+ указывает на успешное завершение работы сценария.
</syntaxhighlight>
Если вы не желаете полностью вычищать системные логи, то выше представлена улучшенная версия предыдущего сценария. Здесь сохраняются последние несколько строк (по-умолчанию -- 50).

Если файл сценария начинается с последовательности #!, которая в мире UNIX называется sha-bang, то это указывает системе какой интерпретатор следует использовать для исполнения сценария. Это двухбайтовая последовательность, или <ref>Некоторые разновидности UNIX (основанные на 4.2BSD) требуют, чтобы эта последовательность состояла из 4-х байт, за счет добавления пробела после !, #! /bin/sh.</ref> -- специальный маркер, определяющий тип сценария, в данном случае -- сценарий командной оболочки (см. man magic). Более точно, sha-bang определяет интерпретатор, который вызывается для исполнения сценария, это может быть командная оболочка (shell), иной интерпретатор или утилита. <ref>В shell-скриптах последовательность #! должна стоять самой первой и задает интерпретатор (sh или bash). Интерпретатор, в свою очередь, воспринимает эту строку как комментарий, поскольку она начинается с символа #.  Если в сценарии имеются еще такие же строки, то они воспринимаются как обычный комментарий.
<syntaxhighlight lang="bash">
 #!/bin/bash  
 echo "Первая часть сценария." 
 a=1  

 #!/bin/bash 
 # Это *НЕ* означает запуск нового сценария.  

 echo "Вторая часть сценария." 
 echo $a  # Значение переменной $a осталось равно 1.
</syntaxhighlight>
</ref>
<syntaxhighlight lang="bash">
#!/bin/sh
#!/bin/bash
#!/usr/bin/perl
#!/usr/bin/tcl
#!/bin/sed -f
#!/usr/awk -f
</syntaxhighlight>

Каждая, из приведенных выше сигнатур, приводит к вызову различных интерпретаторов, будь то /bin/sh -- командный интерпретатор по-умолчанию (bash для Linux-систем), либо иной. <ref>Эта особенность позволяет использовать различные хитрости. 
<syntaxhighlight lang="bash"> 
 #!/bin/rm 
 # Самоуничтожающийся сценарий. 

 # Этот скрипт ничего не делает -- только уничтожает себя. 
  WHATEVER=65  echo "Эта строка никогда не будет напечатана."
  exit $WHATEVER
  # Не имеет смысла, поскольку работа сценария завершается не здесь.
</syntaxhighlight>
Попробуйте запустить файл README с сигнатурой #!/bin/more (предварительно не забудьте сделать его исполняемым).</ref> При переносе сценариев с сигнатурой #!/bin/sh на другие UNIX системы, где в качестве командного интерпретатора задан другой shell, вы можете лишиться некоторых особенностей, присущих bash. Поэтому такие сценарии должны быть POSIX совместимыми. <ref>Portable Operating System Interface, попытка стандартизации UNIX-подобных операционных систем.</ref>

Обратите внимание на то, что сигнатура должна указывать правильный путь к интерпретатору, в противном случае вы получите сообщение об ошибке -- как правило это "Command not found".

Сигнатура #! может быть опущена, если вы не используете специфичных команд. Во втором примере (см. выше) использование сигнатуры #! обязательно, поскольку сценарий использует специфичную конструкцию присваивания значения переменной lines=50. Еще раз замечу, что сигнатура #!/bin/sh вызывает командный интерпретатор по-умолчанию -- /bin/bash в Linux-системах.
	
[[Файл:Important.gif]] В данном руководстве приветствуется модульный подход к построению сценариев. Записывайте, собирайте свою коллекцию участков кода, который может вам встретиться. В конечном итоге вы соберете свою "библиотеку" подпрограмм, которые затем сможете использовать при написании своих сценариев. Например, следующий отрывок сценария проверяет количество аргументов в командной строке:
<syntaxhighlight lang="bash">
if [ $# -ne Number_of_expected_args ]
then
  echo "Usage: `basename $0` whatever"
  exit $WRONG_ARGS
fi
</syntaxhighlight>

==== Запуск сценария ====
Запустить сценарий можно командой sh scriptname <ref>Внимание: вызов Bash-скрипта с помощью команды sh scriptname отключает специфичные для Bash расширения, что может привести к появлению ошибки и аварийному завершению работы сценария.</ref> или bash scriptname. (Не рекомендуется запуск сценария командой sh <scriptname>, поскольку это запрещает использование устройства стандартного ввода stdin в скрипте). Более удобный вариант -- сделать файл скрипта исполняемым, командой chmod.

Это:
 chmod 555 scriptname (выдача прав на чтение/исполнение любому пользователю в системе) <ref>Сценарий должен иметь как право на исполнение, так и право на чтение, поскольку shell должен иметь возможность прочитать скрипт.</ref>

или
 chmod +rx scriptname (выдача прав на чтение/исполнение любому пользователю в системе)

 chmod u+rx scriptname (выдача прав на чтение/исполнение только "владельцу" скрипта)



После того, как вы сделаете файл сценария исполняемым, вы можете запустить его примерно такой командой ./scriptname. <ref>Почему бы не запустить сценарий просто набрав название файла scriptname, если сценарий находится в текущем каталоге? Дело в том, что из соображений безопасности, путь к текущему каталогу "." не включен в переменную окружения $PATH. Поэтому необходимо явно указывать путь к текущему каталогу, в котором находится сценарий, т.е. ./scriptname.</ref> Если, при этом, текст сценария начинается с корректной сигнатуры ("sha-bang"), то для его исполнения будет вызван соответствующий интерпретатор.

И наконец, завершив отладку сценария, вы можете поместить его в каталог /usr/local/bin (естественно, что для этого вы должны обладать правами root), чтобы сделать его доступным для себя и других пользователей системы. После этого сценарий можно вызвать, просто напечатав название файла в командной строке и нажав клавишу '''<nowiki>[ENTER]</nowiki>'''.

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

Напишите сценарий, который выводит [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#DATEREF дату, время], [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#WHOREF список зарегистрировавшихся пользователей], и [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#UPTIMEREF uptime] системы и [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#IOREDIRREF сохраняет эту информацию] в системном журнале.

== Часть 2. Основы ==

=== Глава 3. Служебные символы ===

Служебные символы, используемые в текстах сценариев.

 #
Комментарии. Строки, начинающиеся с символа # ([http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#MAGNUMREF за исключением комбинации #!]) -- являются комментариями.
<syntaxhighlight lang="bash">
# Эта строка -- комментарий.
</syntaxhighlight>

Комментарии могут располагаться и в конце строки с исполняемым кодом.
<syntaxhighlight lang="bash">
echo "Далее следует комментарий." # Это комментарий.
</syntaxhighlight>

Комментариям могут предшествовать [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#WHITESPACEREF пробелы] (пробел, табуляция).
<syntaxhighlight lang="bash">
       # Перед комментарием стоит символ табуляции.
</syntaxhighlight>

[[Файл:Caution.gif]] Исполняемые команды не могут следовать за комментарием в той же самой строке. Пока что еще не существует способа отделения комментария от "исполняемого кода", следующего за комментарием в той же строке.

[[Файл:Note.gif]] Само собой разумеется, экранированный символ # в операторе echo не воспринимается как начало комментария. Более того, он может использоваться в [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#PSUB2 операциях подстановки параметров] и в [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#PSUB2 константных числовых выражениях].
	
Само собой разумеется, экранированный символ # в операторе echo не воспринимается как начало комментария. Более того, он может использоваться в операциях подстановки параметров и в константных числовых выражениях.

<syntaxhighlight lang="bash">
echo "Символ # не означает начало комментария."
echo 'Символ # не означает начало комментария.'
echo Символ \# не означает начало комментария.
echo А здесь символ # означает начало комментария.

echo ${PATH#*:}       # Подстановка -- не комментарий.
echo $(( 2#101011 ))  # База системы счисления -- не комментарий.

# Спасибо, S.C.
</syntaxhighlight>

[http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#QUOTINGREF Кавычки " ' и \] экранируют действие символа #. 

В операциях [http://rus-linux.net/MyLDP/BOOKS/abs-guide/flat/abs-book.html#PSOREX1 поиска по шаблону] символ # так же не воспринимается как начало комментария.