Дейв Тейлор - Сценарии командной оболочки. Linux, OS X и Unix. 2-е издание

Сценарии, использующие переменные окружения (такие как MAILER или PAGER), таят в себе скрытую опасность: некоторые их настройки могут ссылаться на несуществующие программы. Для тех, кто не сталкивался прежде с этими переменными окружения, отметим, что MAILER должна хранить путь к программе электронной почты (например, /usr/bin/mailx), а PAGER должна ссылаться на программу постраничного просмотра длинных документов. Например, если вы решите увеличить гибкость сценария и вместо системной программы постраничного просмотра по умолчанию (обычно more или less) использовать для отображения вывода сценария переменную PAGER, необходимо убедиться, что эта переменная содержит действительный путь к существующей программе.

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

Листинг 1.1.Сценарий inpath с определениями функций

#!/bin/bash

# inpath — Проверяет допустимость пути к указанной программе

# или ее доступность в каталогах из списка PATH

in_path()

{

··# Получает команду и путь, пытается отыскать команду. Возвращает 0, если

··#·· команда найдена и является выполняемым файлом; 1 — если нет. Обратите

··#·· внимание, что эта функция временно изменяет переменную окружения

··#·· IFS (Internal Field Separator — внутренний разделитель полей), но

··#·· восстанавливает ее перед завершением.

··cmd=$1········ourpath=$2···· result=1

··oldIFS=$IFS·· IFS=":"

··for directory in "$ourpath"

··do

····if [-x $directory/$cmd]; then

······result=0······ # Если мы здесь, значит, команда найдена.

····fi

··done

··IFS=$oldIFS

··return $result

}

checkForCmdInPath()

{

··var=$1

··if ["$var"!= ""]; then

····if ["${var:0:1}" = "/"]; then

······if [! -x $var]; then

········return 1

······fi

····elif! in_path $var "$PATH"; then

······return 2

····fi

··fi

}

В главе 0 мы рекомендовали создать в своем домашнем каталоге новую папку scripts и добавить полный путь к ней в свою переменную окружения PATH. Выполните команду echo $PATH, чтобы увидеть текущее значение переменной PATH, и добавьте в сценарий входа ( .login, profile, bashrc или .bash_profile , в зависимости от оболочки) строку, изменяющую значение PATH. Подробности ищите в разделе «Настройка оболочки входа» в главе 0.

Если попробовать вывести список файлов в каталоге с помощью команды ls, некоторые специальные файлы, такие как .bashrc и .bash_profile , могут не отображаться. Это объясняется тем, что файлы, имена которых начинаются с точки, например .bashrc , считаются «скрытыми». (Как оказывается, эта «ошибка, превратившаяся в «фишку» была допущена еще в самом начале развития Unix.) Чтобы вывести все файлы, включая скрытые, добавьте в команду ls флаг −a.

Напомним еще раз: все наши сценарии написаны в предположении, что они будут выполняться командной оболочкой bash. Обратите внимание: этот сценарий явно указывает в первой строке (называется shebang ), что для его интерпретации должен использоваться интерпретатор /bin/bash. Многие системы поддерживают также строку shebang /usr/bin/env bash, которая определяет местонахождение интерпретатора в момент запуска сценария.

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

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

Функция checkForCmdInPath отличает значение параметра с одним только именем программы (например, echo) от значения, содержащего полный путь, плюс имя файла (например, /bin/echo). Для этого она сравнивает первый символ в переданном ей значении с символом /; для чего ей требуется изолировать первый символ от остального значения параметра.

Обратите внимание на синтаксис ${var:0:1} — это сокращенная форма извлечения подстроки: указывается начальная позиция в исходной строке и длина извлекаемой подстроки (если длина не указана, возвращается остаток строки до конца). Выражение ${var:10}, например, вернет остаток строки в $var начиная с десятого символа, а ${var:10:6} вернет только символы, заключенные между позициями 10 и 15 включительно. Что это означает, демонстрирует следующий пример:

$ var="something wicked this way comes…"

$ echo ${var:10}

wicked this way comes…

$ echo ${var:10:6}

wicked

$

В листинге 1.1 данный синтаксис используется, чтобы определить, начинается ли указанный путь с символа слеша. Если это так, то далее функция проверяет наличие указанного файла в файловой системе по указанному пути. Пути, начинающиеся с символа /, являются абсолютными, и для их проверки можно использовать оператор −x . В противном случае значение параметра передается в функцию inpath , чтобы проверить наличие указанного файла в одном из каталогов, перечисленных в PATH.

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

if [$# −ne 1]; then

··echo "Usage: $0 command" >&2

··exit 1

fi

checkForCmdInPath "$1"

case $? in

··0) echo "$1 found in PATH";;

··1) echo "$1 not found or not executable";;

··2) echo "$1 not found in PATH";;

esac

exit 0

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