Advanced Bash-Scripting Guide: различия между версиями

Материал из Home wiki
Перейти к навигации Перейти к поиску
Строка 186: Строка 186:
  
 
Сигнатура #! может быть опущена, если вы не используете специфичных команд. Во втором примере (см. выше) использование сигнатуры #! обязательно, поскольку сценарий использует специфичную конструкцию присваивания значения переменной lines=50. Еще раз замечу, что сигнатура #!/bin/sh вызывает командный интерпретатор по-умолчанию -- /bin/bash в Linux-системах.
 
Сигнатура #! может быть опущена, если вы не используете специфичных команд. Во втором примере (см. выше) использование сигнатуры #! обязательно, поскольку сценарий использует специфичную конструкцию присваивания значения переменной lines=50. Еще раз замечу, что сигнатура #!/bin/sh вызывает командный интерпретатор по-умолчанию -- /bin/bash в Linux-системах.
−
 
−
'''Important'''
 
 
 
−
В данном руководстве приветствуется модульный подход к построению сценариев. Записывайте, собирайте свою коллекцию участков кода, который может вам встретиться. В конечном итоге вы соберете свою "библиотеку" подпрограмм, которые затем сможете использовать при написании своих сценариев. Например, следующий отрывок сценария проверяет количество аргументов в командной строке:
+
[[Файл:Important.gif]] В данном руководстве приветствуется модульный подход к построению сценариев. Записывайте, собирайте свою коллекцию участков кода, который может вам встретиться. В конечном итоге вы соберете свою "библиотеку" подпрограмм, которые затем сможете использовать при написании своих сценариев. Например, следующий отрывок сценария проверяет количество аргументов в командной строке:
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
if [ $# -ne Number_of_expected_args ]
 
if [ $# -ne Number_of_expected_args ]
Строка 223: Строка 221:
  
 
=== Глава 3. Служебные символы ===
 
=== Глава 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 поиска по шаблону] символ # так же не воспринимается как начало комментария.

Версия 18:51, 11 октября 2018

Advanced Bash-Scripting Guide

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

Автор: Mendel Cooper

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

thegrendel@theriver.com

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

kis_an@mail.ru

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

Последнюю версию документа, в виде .bz2 архива, содержащем исходные тексты в формате SGML и HTML, вы найдете на домашней страничке автора. Там же вы найдете и change log.

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

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

Глава 1. Зачем необходимо знание языка Shell?

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

Язык сценариев легок в изучении, в нем не так много специфических операторов и конструкций. [1]. Синтаксис языка достаточно прост и прямолинеен, он очень напоминает команды, которые приходится вводить в командной строке. Короткие скрипты практически не нуждаются в отладке, и даже отладка больших скриптов отнимает весьма незначительное время.

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 позаимствовал некоторые особенности, [2] и C Shell и его производных. (Примечательно, что C Shell не рекомендуется к использованию из-за отдельных проблем, отмеченных Томом Кристиансеном (Tom Christiansen) в октябре 1993 года на Usenet post

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

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

Если вы не можете самостоятельно написать скрипт, вы можете найти исполнителя на сайте Toptal.

Глава 2. Для начала о Sha-Bang

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

Пример 2-1. cleanup: Сценарий очистки лог-файлов в /var/log 

# cleanup
# Для работы сценария требуются права root.

cd /var/log
cat /dev/null > messages
cat /dev/null > wtmp
echo "Лог-файлы очищены."

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

Пример 2-2. cleanup: Расширенная версия предыдущего сценария. 

#!/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
#+ указывает на успешное завершение работы сценария.

Если вы не желаете полностью вычищать системные логи, то выше представлена улучшенная версия предыдущего сценария. Здесь сохраняются последние несколько строк (по-умолчанию -- 50).

Если файл сценария начинается с последовательности #!, которая в мире UNIX называется sha-bang, то это указывает системе какой интерпретатор следует использовать для исполнения сценария. Это двухбайтовая последовательность, или [4] -- специальный маркер, определяющий тип сценария, в данном случае -- сценарий командной оболочки (см. man magic). Более точно, sha-bang определяет интерпретатор, который вызывается для исполнения сценария, это может быть командная оболочка (shell), иной интерпретатор или утилита. [5] 

#!/bin/sh
#!/bin/bash
#!/usr/bin/perl
#!/usr/bin/tcl
#!/bin/sed -f
#!/usr/awk -f

Каждая, из приведенных выше сигнатур, приводит к вызову различных интерпретаторов, будь то /bin/sh -- командный интерпретатор по-умолчанию (bash для Linux-систем), либо иной. [6] При переносе сценариев с сигнатурой #!/bin/sh на другие UNIX системы, где в качестве командного интерпретатора задан другой shell, вы можете лишиться некоторых особенностей, присущих bash. Поэтому такие сценарии должны быть POSIX совместимыми. [7]

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

Сигнатура #! может быть опущена, если вы не используете специфичных команд. Во втором примере (см. выше) использование сигнатуры #! обязательно, поскольку сценарий использует специфичную конструкцию присваивания значения переменной lines=50. Еще раз замечу, что сигнатура #!/bin/sh вызывает командный интерпретатор по-умолчанию -- /bin/bash в Linux-системах.

Important.gif В данном руководстве приветствуется модульный подход к построению сценариев. Записывайте, собирайте свою коллекцию участков кода, который может вам встретиться. В конечном итоге вы соберете свою "библиотеку" подпрограмм, которые затем сможете использовать при написании своих сценариев. Например, следующий отрывок сценария проверяет количество аргументов в командной строке: 

if [ $# -ne Number_of_expected_args ]
then
  echo "Usage: `basename $0` whatever"
  exit $WRONG_ARGS
fi

Запуск сценария

Запустить сценарий можно командой sh scriptname [8] или bash scriptname. (Не рекомендуется запуск сценария командой sh <scriptname>, поскольку это запрещает использование устройства стандартного ввода stdin в скрипте). Более удобный вариант -- сделать файл скрипта исполняемым, командой chmod.

Это: 

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

или 

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

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


После того, как вы сделаете файл сценария исполняемым, вы можете запустить его примерно такой командой ./scriptname. [10] Если, при этом, текст сценария начинается с корректной сигнатуры ("sha-bang"), то для его исполнения будет вызван соответствующий интерпретатор.

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

Упражнения

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

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

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

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

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

#

Комментарии. Строки, начинающиеся с символа # (за исключением комбинации #!) -- являются комментариями. 

# Эта строка -- комментарий.

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

echo "Далее следует комментарий." # Это комментарий.

Комментариям могут предшествовать пробелы (пробел, табуляция). 

       # Перед комментарием стоит символ табуляции.

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

Note.gif Само собой разумеется, экранированный символ # в операторе echo не воспринимается как начало комментария. Более того, он может использоваться в операциях подстановки параметров и в константных числовых выражениях.

Само собой разумеется, экранированный символ # в операторе echo не воспринимается как начало комментария. Более того, он может использоваться в операциях подстановки параметров и в константных числовых выражениях. 

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

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

# Спасибо, S.C.

Кавычки " ' и \ экранируют действие символа #.

В операциях поиска по шаблону символ # так же не воспринимается как начало комментария.

  1. ↑ Их так же называют встроенными конструкциями языка командной оболочки shell.
  2. ↑ Многие особенности ksh88 и даже ksh93 перекочевали в Bash.
  3. ↑ В соответствии с соглашениями, имена файлов с shell-скриптами, такими как Bourne shell и совместимыми, имеют расширение .sh. Все стартовые скрипты, которые вы найдете в /etc/rc.d, следуют этому соглашению.
  4. ↑ Некоторые разновидности UNIX (основанные на 4.2BSD) требуют, чтобы эта последовательность состояла из 4-х байт, за счет добавления пробела после !, #! /bin/sh.
  5. ↑ В shell-скриптах последовательность #! должна стоять самой первой и задает интерпретатор (sh или bash). Интерпретатор, в свою очередь, воспринимает эту строку как комментарий, поскольку она начинается с символа #. Если в сценарии имеются еще такие же строки, то они воспринимаются как обычный комментарий. 
     #!/bin/bash  
 echo "Первая часть сценария." 
 a=1  

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

 echo "Вторая часть сценария." 
 echo $a  # Значение переменной $a осталось равно 1.
  6. ↑ Эта особенность позволяет использовать различные хитрости. 
     
 #!/bin/rm 
 # Самоуничтожающийся сценарий. 

 # Этот скрипт ничего не делает -- только уничтожает себя. 
  WHATEVER=65  echo "Эта строка никогда не будет напечатана."
  exit $WHATEVER
  # Не имеет смысла, поскольку работа сценария завершается не здесь.

    Попробуйте запустить файл README с сигнатурой #!/bin/more (предварительно не забудьте сделать его исполняемым).

  7. ↑ Portable Operating System Interface, попытка стандартизации UNIX-подобных операционных систем.
  8. ↑ Внимание: вызов Bash-скрипта с помощью команды sh scriptname отключает специфичные для Bash расширения, что может привести к появлению ошибки и аварийному завершению работы сценария.
  9. ↑ Сценарий должен иметь как право на исполнение, так и право на чтение, поскольку shell должен иметь возможность прочитать скрипт.
  10. ↑ Почему бы не запустить сценарий просто набрав название файла scriptname, если сценарий находится в текущем каталоге? Дело в том, что из соображений безопасности, путь к текущему каталогу "." не включен в переменную окружения $PATH. Поэтому необходимо явно указывать путь к текущему каталогу, в котором находится сценарий, т.е. ./scriptname.
Источник — https://wiki.eve.ks.ua/index.php?title=Advanced_Bash-Scripting_Guide&oldid=128