Глава 1. Отсутствующая библиотека

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

Но есть еще кое-что, о чем необходимо поговорить в самом начале: среда программирования на языке командной оболочки не так сложна, как другие среды программирования на настоящих языках. Perl, Python, Ruby и даже C имеют структуры и библиотеки, предлагающие дополнительные возможности, тогда как сценарии на языке командной оболочки — это в большей степени ваш собственный мир. Сценарии в данной главе помогут вам найти в нем свой путь. Далее они послужат строительными блоками для создания более мощных сценариев.

Наибольшую сложность при разработке сценариев представляют также тонкие различия между разновидностями Unix и дистрибутивами GNU/Linux. Даже при том, что стандарты IEEE POSIX определяют общую функциональную основу для всех реализаций Unix, иногда все же бывает непросто начать пользоваться системой OS X после нескольких лет работы в окружении Red Hat GNU/Linux. Команды различаются, хранятся в разных каталогах и часто имеют тонкие различия в интерпретации флагов. Эти различия могут сделать создание сценариев командной оболочки непростым занятием, но мы познакомим вас с некоторыми хитростями, помогающими справляться с этими сложностями.

Что такое POSIX?

В первые дни Unix был сродни Дикому Западу: разные компании создавали новые версии операционной системы и развивали их в разных направлениях, одновременно уверяя клиентов, что все эти новые версии — просто разновидности Unix, совместимые между собой. Но в дело вмешался Институт инженеров электротехники и электроники (Institute for Electrical and Electronic Engineers, IEEE) и, объединив усилия всех основных производителей, разработал стандартное определение Unix под названием «Интерфейс переносимой операционной системы» (Portable Operating System Interface, или POSIX), которому должны были соответствовать все коммерческие и открытые реализации Unix. Нельзя купить операционную систему POSIX как таковую, но все доступные версии Unix и GNU/Linux в общих чертах соответствуют требованиям POSIX (хотя некоторые ставят под сомнение необходимость стандарта POSIX, когда GNU/Linux сам стал стандартом де-факто).

Однако иногда даже POSIX-совместимые реализации Unix отличаются друг от друга. В качестве примера можно привести команду echo, о которой рассказывается далее в этой главе. Отдельные версии этой команды поддерживают флаг -n, который запрещает добавлять символ перевода строки по умолчанию. Другие версии echo поддерживают экранированную последовательность \c, которая интерпретируется как «не включать перевод строки», а третьи вообще не дают возможности запретить добавление этого символа в конце вывода. Более того, отдельные системы Unix имеют командные оболочки, где команда echo реализована как встроенная функция, которая игнорирует флаги -n и \c, а также включают стандартную реализацию команды в виде двоичного файла /bin/echo, обрабатывающую эти флаги. В результате возникают сложности со сценариями запросов на ввод данных, потому что сценарии должны работать одинаково в как можно большем количестве версий Unix. Следовательно, для нормальной работы сценариев важно нормализовать поведение команды echo, чтобы оно было единообразным в разных системах. Далее в этой главе, в сценарии № 8, вы увидите, как заключить команду echo в сценарий командной оболочки, чтобы получить такую нормализованную версию.

ПРИМЕЧАНИЕ

Некоторые сценарии в этой книге используют дополнительные возможности bash, поддерживаемые не всеми POSIX-совместимыми командными оболочками.

Но хватит теории — приступим к знакомству со сценариями, которые будут включены в нашу библиотеку!

№ 1. Поиск программ в PATH

Сценарии, использующие переменные окружения (такие как 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

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

Результаты

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

Листинг 1.2. Тестирование сценария inpath

$ inpath echo

echo found in PATH

$ inpath MrEcho

MrEcho not found in PATH

$ inpath /usr/bin/MrEcho

/usr/bin/MrEcho not found or not executable

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

Усовершенствование сценария

Для желающих начать овладевать мастерством программирования с первого сценария, покажем, как заменить выражение ${var:0:1} его более сложной формой: ${var%${var#?}}. Такой метод извлечения подстрок определяет стандарт POSIX. Эта галиматья в действительности включает два выражения извлечения подстроки. Внутреннее выражение ${var#?} извлекает из var все, кроме первого символа, где # удаляет первое совпадение с заданным шаблоном, а ? — это регулярное выражение, которому соответствует точно один символ.

Внешнее выражение ${var%pattern} возвращает подстроку из строки слева, оставшуюся после удаления указанного шаблона pattern из var. В данном случае удаляемый шаблон pattern — это результат внутреннего выражения, то есть внешнее выражение вернет первый символ в строке.

Для тех, кому POSIX-совместимый синтаксис кажется пугающим, отметим, что большинство командных оболочек (включая bash, ksh и zsh) поддерживает другой метод извлечения подстрок, ${varname:start:size}, который был использован в сценарии.

Те, кому не нравится ни один из представленных способов извлечения первого символа, могут использовать системные команды: $(echo $var | cut -c1). В программировании на bash практически любую задачу, будь то извлечение, преобразование или загрузка данных из системы, можно решить несколькими способами. При этом важно понимать, что наличие нескольких способов не означает, что один способ лучше другого.

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

if [ "$BASH_SOURCE" = "$0" ]

Это сработает и с любым другим сценарием. Однако мы предлагаем вам, дорогой читатель, дописать остальной код после экспериментов!

ПРИМЕЧАНИЕ

Сценарий № 47 в главе 6 тесно связан с этим сценарием. Он проверяет каталоги в PATH и переменные в окружении пользователя.

№ 2. Проверка ввода: только алфавитно-цифровые символы

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

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

Код

Листинг 1.3. Сценарий validalnum

#!/bin/bash

# validAlphaNum – проверяет, содержит ли строка только

# алфавитные и цифровые символы

validAlphaNum()

{

  # Проверка аргумента: возвращает 0, если все символы в строке являются

  #   буквами верхнего/нижнего регистра или цифрами; иначе возвращает 1

  # Удалить все недопустимые символы.

  validchars="$(echo $1 | sed -e 's/[^[:alnum:]]//g’)"

  if [ "$validchars" = "$1" ] ; then

    return 0

  else

    return 1

  fi

}

# НАЧАЛО ОСНОВНОГО СЦЕНАРИЯ -- УДАЛИТЕ ИЛИ ЗАКОММЕНТИРУЙТЕ ВСЕ, ЧТО НИЖЕ,

# ЧТОБЫ ЭТОТ СЦЕНАРИЙ МОЖНО БЫЛО ПОДКЛЮЧАТЬ К ДРУГИМ СЦЕНАРИЯМ.

# =================

/bin/echo -n "Enter input: "

read input

# Проверка ввода

if ! validAlphaNum "$input" ; then

  echo "Please enter only letters and numbers." >&2

  exit 1

else

  echo "Input is valid."

fi

exit 0

Как это работает

Логика работы сценария проста: сначала с помощью редактора sed создается новая версия введенных данных, из которой удалены все недопустимые символы . Затем новая версия сравнивается с оригиналом . Если две версии оказались одинаковыми, все в порядке. В противном случае, если в результате обработки редактором sed потерялись данные, значит, исходная версия содержит недопустимые символы.

В основе работы сценария лежит операция подстановки редактора sed, которая удаляет любые символы, не входящие в множество [:alnum:], где [:alnum:] — это сокращение POSIX для регулярного выражения, соответствующего всем алфавитно-цифровым символам. Если результат операции подстановки не совпадает с исходным вводом, значит, в исходной строке присутствуют другие символы, кроме алфавитно-цифровых, недопустимые в данном случае. Функция возвращает ненулевое значение, чтобы сообщить о проблеме. Имейте в виду: в этом примере предполагается, что введенные данные являются текстом ASCII.

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

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

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

Результаты

Сценарий validalnum прост в применении, он предлагает пользователю ввести строку для проверки. В листинге 1.4 показано, как сценарий реагирует на допустимый и недопустимый ввод.

Листинг 1.4. Тестирование сценария validalnum

$ validalnum

Enter input: valid123SAMPLE

Input is valid.

$ validalnum

Enter input: this is most assuredly NOT valid, 12345

Please enter only letters and numbers.

Усовершенствование сценария

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

Хотите потребовать, чтобы ввод содержал только буквы верхнего регистра, пробелы, запятые и точки? Просто измените шаблон подстановки в строке , как показано ниже:

sed 's/[^[:upper:] ,.]//g'

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

sed 's/[^- [:digit:]\(\)]//g'

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

sed 's/[^[:digit:]]//g'

Однако он будет пропускать только положительные целые числа. А что, если вам необходимо разрешить ввод отрицательных чисел? Если вы просто добавите знак «минус» в множество допустимых символов, функция признает допустимой строку -3-4, хотя совершенно очевидно, что она не является допустимым целым числом. Обработка отрицательных чисел демонстрируется в сценарии № 5.

№ 3. Нормализация форматов дат

Разработчикам сценариев часто приходится иметь дело с большим количеством разнообразных форматов представления дат, нормализация которых может быть сопряжена с разными сложностями. Самые серьезные проблемы связаны с датами, потому что они записываются самыми разными способами. Даже если потребовать ввести дату в определенном формате, например месяц-день-год, вы почти наверняка получите несовместимый ввод: номер месяца вместо названия, сокращенное название вместо полного или даже полное название со всеми буквами в верхнем регистре. По этой причине функция нормализации дат, даже самая простенькая, послужит очень хорошим строительным блоком для многих сценариев, особенно таких, как сценарий № 7.

Код

Сценарий в листинге 1.5 нормализует строки с датами, используя относительно простой набор критериев: месяц должен задаваться именем или числом в диапазоне от 1 до 12, а год — четырехзначным числом. Нормализованная строка с датой включает название месяца (в виде трехсимвольного сокращения), за которым следуют день месяца и четырехзначный год.

Листинг 1.5. Сценарий normdate

  #!/bin/bash

  # normdate -- Нормализует поле месяца в строке с датой в трехсимвольное

  #   представление, с первой буквой в верхнем регистре.

  #   Вспомогательная функция для сценария № 7, valid-date.

  #   В случае успеха возвращает 0.

  monthNumToName()

  {

    # Присвоить переменной 'month’ соответствующее значение.

    case $1 in

      1 ) month="Jan" ;; 2 ) month="Feb" ;;

      3 ) month="Mar" ;; 4 ) month="Apr" ;;

      5 ) month="May" ;; 6 ) month="Jun" ;;

      7 ) month="Jul" ;; 8 ) month="Aug" ;;

      9 ) month="Sep" ;; 10) month="Oct" ;;

      11) month="Nov" ;; 12) month="Dec" ;;

      * ) echo "$0: Unknown month value $1" >&2

        exit 1

    esac

    return 0

  }

  

  # НАЧАЛО ОСНОВНОГО СЦЕНАРИЯ -- УДАЛИТЕ ИЛИ ЗАКОММЕНТИРУЙТЕ ВСЕ, ЧТО НИЖЕ,

  # ЧТОБЫ ЭТОТ СЦЕНАРИЙ МОЖНО БЫЛО ПОДКЛЮЧАТЬ К ДРУГИМ СЦЕНАРИЯМ.

  # =================

  # Проверка ввода

  if [ $# -ne 3 ] ; then

    echo "Usage: $0 month day year" >&2

    echo "Formats are August 3 1962 and 8 3 1962" >&2

    exit 1

  fi

  if [ $3 -le 99 ] ; then

    echo "$0: expected 4-digit year value." >&2

    exit 1

  fi

  # Месяц введен как число?

  if [ -z $(echo $1|sed 's/[[:digit:]]//g') ]; then

    monthNumToName $1

  else

  # Нормализовать до 3 первых букв, первая в верхнем регистре, остальные в нижнем.

    month="$(echo $1|cut -c1|tr '[:lower:]' '[:upper:]')"

    month="$month$(echo $1|cut -c2-3 | tr '[:upper:]' '[:lower:]')"

  fi

  echo $month $2 $3

  exit 0

Как это работает

Обратите внимание на третий условный оператор в этом сценарии . Он выбрасывает из поля с месяцем все цифры и затем с помощью оператора -z проверяет, получилась ли в результате пустая строка. Если получилась, это означает, что в поле содержатся только цифры, соответственно, его можно напрямую преобразовать в название месяца вызовом функции monthNumToName, которая дополнительно проверяет номер месяца на попадание в диапазон от 1 до 12. Иначе предполагается, что первое поле во введенной строке содержит название месяца, которое нормализуется сложной последовательностью команд cut и tr с использованием двух подоболочек (то есть последовательности команд заключены в скобки $( и ), которые вызывают заключенные в них команды и возвращают их вывод).

Первая последовательность команд в подоболочке, в строке , извлекает первый символ из поля с названием месяца и с помощью tr преобразует его в верхний регистр (последовательность echo $1|cut -c1 можно также записать в стиле POSIX: ${1%${1#?}}, как было показано выше). Вторая последовательность, в строке , извлекает второй и третий символы и преобразует их в нижний регистр. В результате получается трехсимвольное сокращенное название месяца с первым символом в верхнем регистре. Обратите внимание, что в данном случае не проверяется — содержит ли исходное поле ­допустимое название месяца, в отличие от случая, когда месяц задается числом.

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

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

Результаты

Листинг 1.6. Тестирование сценария normdate

$ normdate 8 3 62

normdate: expected 4-digit year value.

$ normdate 8 3 1962

Aug 3 1962

$ normdate AUGUST 03 1962

Aug 03 1962

Обратите внимание, что этот сценарий нормализует только представление месяца; представление дня (в том числе с ведущими нулями) и года не изменяется.

Усовершенствование сценария

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

Одно из изменений, которые можно внедрить уже сейчас, касается включения поддержки дат в форматах MM/DD/YYYY и MM-DD-YYYY, для чего достаточно добавить следующий код непосредственно перед первым условным оператором:

if [ $# -eq 1 ] ; then # Чтобы компенсировать форматы с / и -

  set -- $(echo $1 | sed 's/[\/\-]/ /g')

fi

С этим изменением сценарий позволяет вводить и нормализовать даты в следующих распространенных форматах:

$ normdate 6-10-2000

Jun 10 2000

$ normdate March-11-1911

Mar 11 1911

$ normdate 8/3/1962

Aug 3 1962

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

№ 4. Удобочитаемое представление больших чисел

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

Код

Листинг 1.7. Сценарий nicenumber форматирует большие числа, делая их удобочитаемыми

  #!/bin/bash

  # nicenumber -- Отображает переданное число в формате представления с запятыми.

  #   Предполагает наличие переменных DD (decimal point delimiter -- разделитель

  #   дробной части) и TD (thousands delimiter -- разделитель групп разрядов).

  #   Создает переменную nicenum с результатом, а при наличии второго аргумента

  #   дополнительно выводит результат в стандартный вывод.

  nicenumber()

  {

    # Обратите внимание: предполагается, что для разделения дробной и целой

    #   части во входном значении используется точка.

    #   В выходной строке в качестве такого разделителя используется точка, если

    #   пользователь не определил другой символ с помощью флага -d.

    integer=$(echo $1 | cut -d. -f1) # Слева от точки

    decimal=$(echo $1 | cut -d. -f2) # Справа от точки

    # Проверить присутствие дробной части в числе.

    if [ "$decimal" != "$1" ]; then

      # Дробная часть есть, включить ее в результат.

      result="${DD:= '.'}$decimal"

    fi

  thousands=$integer

  while [ $thousands -gt 999 ]; do

    remainder=$(($thousands % 1000)) # Три последние значимые цифры

    # В 'remainder' должно быть три цифры. Требуется добавить ведущие нули?

    while [ ${#remainder} -lt 3 ] ; do # Добавить ведущие нули

      remainder="0$remainder"

    done

    result="${TD:=","}${remainder}${result}" # Конструировать справа налево

    thousands=$(($thousands / 1000)) # Оставить остаток, если есть

  done

  nicenum="${thousands}${result}"

  if [ ! -z $2 ] ; then

    echo $nicenum

  fi

}

DD="." # Десятичная точка для разделения целой и дробной части

TD="," # Разделитель групп разрядов

# Начало основного сценария

# =================

  while getopts "d:t:" opt; do

    case $opt in

      d ) DD="$OPTARG" ;;

      t ) TD="$OPTARG" ;;

    esac

  done

  shift $(($OPTIND - 1))

  # Проверка ввода

  if [ $# -eq 0 ] ; then

    echo "Usage: $(basename $0) [-d c] [-t c] number"

    echo " -d specifies the decimal point delimiter"

    echo " -t specifies the thousands delimiter"

    exit 0

  fi

  nicenumber $1 1 # Второй аргумент заставляет nicenumber вывести результат.

  exit 0

Как это работает

Основная работа в этом сценарии выполняется циклом while внутри функции nicenumber() , который последовательно удаляет три младших значащих разряда из числового значения в переменной thousands  и присоединяет их к создаваемой форматированной версии числа . Затем цикл уменьшает числовое значение в thousands  и повторяет итерацию, если необходимо. Вслед за функцией nicenumber() начинается основная логика сценария. Сначала с помощью getopts , анализируются параметры, переданные в сценарий, и затем вызывается функция nicenumber()  с последним аргументом, указанным пользователем.

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

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

Результат можно внедрить в сообщение, как показано ниже:

echo "Do you really want to pay \$$(nicenumber $price)?"

Результаты

Сценарий nicenumber может также принимать дополнительные параметры. Лис­тинг 1.8 демонстрирует форматирование нескольких чисел с использованием сценария.

Листинг 1.8: Тестирование сценария nicenumber

$ nicenumber 5894625

5,894,625

$ nicenumber 589462532.433

589,462,532.433

$ nicenumber -d, -t. 589462532.433

589.462.532,433

Усовершенствование сценария

В разных странах используют разные символы в качестве десятичной точки и для разделения групп разрядов, поэтому в сценарии предусмотрена возможность передачи дополнительных флагов. Например, в Германии и Италии сценарию следует передать -d "." и -t ",", во Франции -d "," и -t " ", а в Швейцарии, где четыре государственных языка, следует использовать -d "." и -t "'". Это отличный пример ситуации, когда гибкость оказывается ценнее жестко определенных значений, потому что инструмент становится полезным для более широкого круга пользователей.

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

Ниже показано одно из решений:

integer=$(echo $1 | cut -d$DD -f1) # Слева от точки

decimal=$(echo $1 | cut -d$DD -f2) # Справа от точки

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

separator="$(echo $1 | sed 's/[[:digit:]]//g')"

if [ ! -z "$separator" -a "$separator" != "$DD" ] ; then

  echo "$0: Unknown decimal separator $separator encountered." >&2

  exit 1

fi

№ 5. Проверка ввода: целые числа

Как было показано в сценарии № 2, проверка целых чисел осуществляется очень просто, пока дело не доходит до отрицательных значений. Проблема в том, что всякое отрицательное число может содержать только один знак «минус», который обязан быть первым. Процедура проверки в листинге 1.9 оценивает правильность форматирования отрицательных чисел и, что особенно ценно, может проверить вхождение значений в установленный пользователем диапазон.

Код

Листинг 1.9. Сценарий validint

#!/bin/bash

# validint -- Проверяет целые числа, поддерживает отрицательные значения

validint()

{

  # Проверяет первое значение и сравнивает с минимальным значением $2 и/или

  #   с максимальным значением $3, если они заданы. Если проверяемое значение

  #   вне заданного диапазона или не является допустимым целым числом,

  #   возвращается признак ошибки.

  number="$1"; min="$2"; max="$3"

  if [ -z $number ] ; then

    echo "You didn't enter anything. Please enter a number." >&2

    return 1

  fi

  # Первый символ –- знак "минус"?

  if [ "${number%${number#?}}" = "-" ] ; then

    testvalue="${number#?}" # Оставить для проверки все, кроме первого символа

  else

    testvalue="$number"

  fi

  # Удалить все цифры из числа для проверки.

  nodigits="$(echo $testvalue | sed 's/[[:digit:]]//g')"

  # Проверить наличие нецифровых символов.

  if [ ! -z $nodigits ] ; then

    echo "Invalid number format! Only digits, no commas, spaces, etc." >&2

    return 1

  fi

  if [ ! -z $min ] ; then

    # Входное значение меньше минимального?

    if [ "$number" -lt "$min" ] ; then

      echo "Your value is too small: smallest acceptable value is $min." >&2

      return 1

    fi

  fi

  if [ ! -z $max ] ; then

    # Входное значение больше максимального?

    if [ "$number" -gt "$max" ] ; then

      echo "Your value is too big: largest acceptable value is $max." >&2

      return 1

    fi

  fi

  return 0

}

Как это работает

Проверка целочисленных значений реализуется очень просто благодаря тому что такие значения состоят исключительно из последовательности цифр (от 0 до 9), перед которой может находиться единственный знак «минус». Если в вызов функции validint() передать минимальное и (или) максимальное значение, она также проверит вхождение заданного значения в указанный диапазон.

Сначала функция проверяет ввод непустого значения  (еще один пример, когда важно использовать двойные кавычки, чтобы предотвратить появление сообщения об ошибке в случае ввода пустой строки). Затем, в строке , она проверяет наличие знака «минус» и в строке  удаляет из введенного значения все цифры. Если в результате получилась непустая строка, значит, введено значение, не являющееся целым числом, и функция возвращает признак ошибки.

Если введенное значение допустимо, оно сравнивается с минимальным и максимальным значениями . Наконец, в случае ошибки функция возвращает 1 и 0 — в случае успеха.

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

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

Листинг 1.10. Дополнительная поддержка, превращающая сценарий в самостоятельную команду

# Проверка ввода

if validint "$1" "$2" "$3" ; then

    echo "Input is a valid integer within your constraints."

fi

Результаты

После добавления кода из листинга 1.10, сценарий можно использовать, как показано в листинге 1.11:

Листинг 1.11. Тестирование сценария validint

$ validint 1234.3

Invalid number format! Only digits, no commas, spaces, etc.

$ validint 103 1 100

Your value is too big: largest acceptable value is 100.

$ validint -17 0 25

Your value is too small: smallest acceptable value is 0.

$ validint -17 -20 25

Input is a valid integer within your constraints.

Усовершенствование сценария

Обратите внимание на строку , которая проверяет, не является ли первый символ знаком «минус»:

if [ "${number%${number#?}}" = "-" ] ; then

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

В данном случае велик соблазн использовать логический оператор И (-a), чтобы объединить выражения и избавиться от вложенных инструкций if. Например, на первый взгляд кажется, что следующий код должен работать:

if [ ! -z $min -a "$number" -lt "$min" ] ; then

  echo "Your value is too small: smallest acceptable value is $min." >&2

  exit 1

fi

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

№ 6. Проверка ввода: вещественные числа

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

Код

Листинг 1.12. Сценарий validfloat

#!/bin/bash

# validfloat – Проверяет допустимость вещественного значения.

#   Имейте в виду, что сценарий не распознает научную форму записи (1.304e5).

# Чтобы проверить вещественное значение, его нужно разбить на две части:

#   целую и дробную. Первая часть проверяется как обычное целое число,

#   а дробная – как положительное целое число. То есть число -30.5 оценивается

#   как допустимое, а -30.-8 нет.

# Подключение других сценариев к текущему осуществляется с помощью оператора "."

# Довольно просто.

. validint

validfloat()

{

  fvalue="$1"

  # Проверить наличие десятичной точки.

  if [ ! -z $(echo $fvalue | sed 's/[^.]//g') ] ; then

    # Извлечь целую часть числа, слева от десятичной точки.

    decimalPart="$(echo $fvalue | cut -d. -f1)"

    # Извлечь дробную часть числа, справа от десятичной точки.

    fractionalPart="${fvalue#*\.}"

    # Проверить целую часть числа, слева от десятичной точки

    if [ ! -z $decimalPart ] ; then

      # "!" инвертирует логику проверки, то есть ниже проверяется

      #   "если НЕ допустимое целое число"

      if ! validint "$decimalPart" "" "" ; then

        return 1

      fi

    fi

    # Теперь проверим дробную часть.

    # Прежде всего, она не может содержать знак "минус" после десятичной точки,

    #   например: 33.-11, поэтому проверим знак '-’ в дробной части.

    if [ "${fractionalPart%${fractionalPart#?}}" = "-" ] ; then

      echo "Invalid floating-point number: '-' not allowed \

        after decimal point." >&2

      return 1

    fi

    if [ "$fractionalPart" != "" ] ; then

      # Если дробная часть НЕ является допустимым целым числом...

      if ! validint "$fractionalPart" "0" "" ; then

        return 1

      fi

    fi

  else

    # Если все значение состоит из единственного знака "-",

    #   это недопустимое значение.

    if [ "$fvalue" = "-" ] ; then

      echo "Invalid floating-point format." >&2

      return 1

    fi

    # В заключение проверить, что оставшиеся цифры представляют

    # допустимое целое число.

    if ! validint "$fvalue" "" "" ; then

      return 1

    fi

  fi

  return 0

}

Как это работает

Сценарий сначала проверяет наличие десятичной точки во входном значении . Если точки в числе нет, это не вещественное число. Далее для анализа извлекаются целая  и дробная  части числа. Затем, в строке , сценарий проверяет, является ли целая часть (слева от десятичной точки) допустимым целым числом. Следующая последовательность проверок сложнее, потому что требуется проверить  отсутствие дополнительного знака «минус» (чтобы исключить такие странные числа, как 17. –30) и убедиться, что дробная часть (справа от десятичной точки) является допустимым целым числом.

Последняя проверка в строке  выясняет, не является ли проверяемое значение единственным знаком «минус» (такое число выглядело бы слишком странно, чтобы пропустить его).

Все проверки выполнились успешно? Тогда сценарий возвращает 0, указывающий, что ввод пользователя содержит допустимое вещественное число.

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

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

if validfloat $1 ; then

  echo "$1 is a valid floating-point value."

fi

exit 0

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

Результаты

Сценарий validfloat принимает единственный аргумент для проверки. Листинг 1.13 демонстрирует проверку нескольких значений с помощью validfloat.

Листинг 1.13. Тестирование сценария validfloat

$ validfloat 1234.56

1234.56 is a valid floating-point value.

$ validfloat -1234.56

-1234.56 is a valid floating-point value.

$ validfloat -.75

-.75 is a valid floating-point value.

$ validfloat -11.-12

Invalid floating-point number: '-' not allowed after decimal point.

$ validfloat 1.0344e22

Invalid number format! Only digits, no commas, spaces, etc.

Если вы увидите лишний вывод, это может объясняться присутствием строк, добавленных ранее в validint для тестирования, которые вы забыли удалить перед переходом к этому сценарию. Просто вернитесь назад, к описанию сценария № 5 и закомментируйте или удалите строки, добавленные для тестирования функции.

Усовершенствование сценария

Было бы круто добавить в функцию поддержку научной формы записи, продемонстрированной в последнем примере. Это не так уж трудно. Вам нужно проверить присутствие в числе символа 'e’ или 'E’ и затем разбить его на три сегмента: целую часть (всегда представлена единственной цифрой), дробную часть и степень числа 10. После этого каждую часть можно проверить с помощью validint.

№ 7. Проверка форматов дат

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

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

• Если год не кратен 4, он не високосный.

• Если год делится на 4 и на 400 — это високосный год.

• Если год делится на 4 и не делится на 400, но делится на 100 — это не високосный год.

• Все остальные годы, кратные 4, являются високосными.

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

Код

Листинг 1.14. Сценарий valid-date

  #!/bin/bash

  # valid-date – Проверяет дату с учетом правил определения високосных лет

  normdate="укажите здесь имя файла, в котором вы сохранили сценарий normdate.sh"

  exceedsDaysInMonth()

  {

    # С учетом названия месяца и числа дней в этом месяце, данная функция

    # вернет: 0, если указанное число меньше или равно числу дней в месяце;

    # 1 -- в противном случае.

    case $(echo $1|tr '[:upper:]' '[:lower:]') in

      jan* ) days=31 ;; feb* ) days=28 ;;

      mar* ) days=31 ;; apr* ) days=30 ;;

      may* ) days=31 ;; jun* ) days=30 ;;

      jul* ) days=31 ;; aug* ) days=31 ;;

      sep* ) days=30 ;; oct* ) days=31 ;;

      nov* ) days=30 ;; dec* ) days=31 ;;

        * ) echo "$0: Unknown month name $1" >&2

            exit 1

    esac

    if [ $2 -lt 1 -o $2 -gt $days ] ; then

      return 1

    else

      return 0 # Число месяца допустимо.

    fi

  }

  isLeapYear()

  {

    # Эта функция возвращает 0, если указанный год является високосным;

    #   иначе возвращается 1.

    # Правила проверки високосного года:

    #   1. Если год не делится на 4, значит, он не високосный.

    #   2. Если год делится на 4 и на 400, значит, он високосный.

    #   3. Если год делится на 4, не делится на 400 и делится

    #      на 100, значит, он не високосный.

    #   4. Любой другой год, который делится на 4, является високосным.

    year=$1

    if [ "$((year % 4))" -ne 0 ] ; then

      return 1 # Nope, not a leap year.

    elif [ "$((year % 400))" -eq 0 ] ; then

      return 0 # Yes, it's a leap year.

    elif [ "$((year % 100))" -eq 0 ] ; then

      return 1

    else

      return 0

    fi

  }

  # Начало основного сценария

  # =================

  if [ $# -ne 3 ] ; then

    echo "Usage: $0 month day year" >&2

    echo "Typical input formats are August 3 1962 and 8 3 1962" >&2

    exit 1

  fi

  # Нормализовать дату и сохранить для проверки на ошибки.

  newdate="$($normdate "$@")"

  if [ $? -eq 1 ] ; then

    exit 1 # Error condition already reported by normdate

  fi

  # Разбить нормализованную дату, в которой

  #   первое слово = месяц, второе слово = число месяца

  #   третье слово = год.

  month="$(echo $newdate | cut -d\ -f1)"

  day="$(echo $newdate | cut -d\ -f2)"

  year="$(echo $newdate | cut -d\ -f3)"

  # После нормализации данных проверить допустимость

  #   числа месяца (например, Jan 36 является недопустимой датой).

  if ! exceedsDaysInMonth $month "$2" ; then

    if [ "$month" = "Feb" -a "$2" -eq "29" ] ; then

      if ! isLeapYear $3 ; then

        echo "$0: $3 is not a leap year, so Feb doesn't have 29 days." >&2

        exit 1

      fi

    else

      echo "$0: bad day value: $month doesn't have $2 days." >&2

      exit 1

    fi

  fi

  echo "Valid date: $newdate"

  exit 0

Как это работает

Этот сценарий было очень интересно писать, потому что он требует проверки большого количества непростых условий: числа месяца, високосного года и так далее. Логика сценария не просто проверяет месяц как число от 1 до 12 или день — от 1 до 31. Чтобы сценарий проще было писать и читать, в нем используются специализированные функции.

Первая функция, exceedsDaysInMonth(), анализирует месяц, указанный пользователем, разрешая вероятные допущения (например, пользователь может передать название JANUAR, и оно будет правильно опознано). Анализ выполняется инструкцией case в строке , которая преобразует свой аргумент в нижний регистр и затем сравнивает полученное значение с константами, чтобы получить число дней в месяце. Единственный недостаток – для февраля функция всегда возвращает 28 дней.

Вторая функция, isLeapYear(), с помощью простых арифметических проверок выясняет, содержит ли февраль в указанном году 29-е число .

В основном сценарии исходные данные передаются сценарию normdate, представленному выше, для нормализации  и затем разбиваются на три поля: $month, $day и $year. Затем вызывается функция exceedsDaysInMonth для проверки допустимости указанного числа для данного месяца, при этом 29 февраля обрабатывается отдельно – в этом случае вызовом функции isLeapYear проверяется год  и при необходимости выводится сообщение об ошибке. Если пользовательская дата успешно преодолела все проверки, значит, она допустимая!

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

Запуская сценарий (как показано в листинге 1.15), введите в командной строке дату в формате месяц-день-год. Месяц можно указать в виде трехсимвольного сокращения, полного названия или числа; год должен состоять из четырех цифр.

Результаты

Листинг 1.15. Тестирование сценария valid-date

$ valid-date august 3 1960

Valid date: Aug 3 1960

$ valid-date 9 31 2001

valid-date: bad day value: Sep doesn’t have 31 days.

$ valid-date feb 29 2004

Valid date: Feb 29 2004

$ valid-date feb 29 2014

valid-date: 2014 is not a leap year, so Feb doesn’t have 29 days.

Усовершенствование сценария

Подход, аналогичный используемому в этом сценарии, можно применить для проверки значения времени в 24-часовом формате или в 12-часовом формате с суффиксом AM/PM (Ante Meridiem/Post Meridiem — пополуночи/пополудни). Разбив значение времени по двоеточиям, нужно убедиться, что число минут и секунд (если указано) находится в диапазоне от 0 до 59, и затем проверить первое поле на вхождение в диапазон от 0 до 12, если присутствует суффикс AM/PM, или от 0 до 24, если предполагается 24-часовой формат. К счастью, несмотря на существование секунд координации (високосных секунд) и других небольших корректировок, помогающих сохранить сбалансированность календарного времени, их можно игнорировать в повседневной работе, то есть нет необходимости использовать замысловатые вычисления.

При наличии доступа к GNU-команде date в Unix или GNU/Linux можно использовать совершенно иной способ проверки високосных лет. Попробуйте выполнить следующую команду и посмотрите, что получится:

$ date -d 12/31/1996 +%j

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

Наконец, данный сценарий слишком терпимо относится к названиям месяцев, например, название febmama будет опознано как допустимое, потому что инструкция case в строке  проверяет только первые три буквы. Эту проблему можно устранить, организовав точную проверку общепринятых сокращений (таких как feb) и полных названий месяцев (february), и даже некоторых типичных опечаток (febuary). Все это легко реализуется, было бы желание!

№ 8. Улучшение некачественных реализаций echo

Как упоминалось в разделе «Что такое POSIX?» в начале этой главе, большинство современных реализаций Unix и GNU/Linux включают команду echo, поддерживающую флаг -n, который подавляет вывод символа перевода строки в конце, но такая поддержка имеется не во всех реализациях. Некоторые для подавления поведения по умолчанию используют специальный символ \c, другие просто добавляют символ перевода строки, не давая никакой возможности изменить это поведение.

Выяснить, какая реализация echo используется в текущей системе, довольно просто: введите следующие команды и посмотрите, что из этого получится:

$ echo -n "The rain in Spain"; echo " falls mainly on the Plain"

Если команда echo поддерживает флаг -n, вы увидите следующий вывод:

The rain in Spain falls mainly on the Plain

Если нет, вывод будет иметь следующий вид:

-n The rain in Spain

falls mainly on the Plain

Гарантировать определенный формат вывода очень важно, и эта важность будет расти с увеличением интерактивности сценариев. Так что мы напишем альтернативную версию echo, с именем echon, которая всегда будет подавлять вывод завершающего символа перевода строки. Благодаря этому мы получим достаточно надежный инструмент, который сможем использовать, когда понадобится функциональность echo -n.

Код

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

Листинг 1.16. Простая альтернатива echo, использующая команду awk printf

echon()

{

  echo "$*" | awk '{ printf "%s", $0 }'

}

Однако есть возможность избежать накладных расходов на вызов команды awk. Если у вас в системе имеется команда printf, используйте ее в сценарии echon, как показано в листинге 1.17.

Листинг 1.17. Альтернатива echo, использующая команду printf

echon()

{

  printf "%s" "$*"

}

А как быть, если команды printf нет и вы не желаете использовать awk? Тогда отсекайте любые завершающие символы перевода строки с помощью команды tr, как показано в листинге 1.18.

Листинг 1.18. Простая альтернатива echo, использующая команду tr

echon()

{

  echo "$*" | tr -d '\n'

}

Это простой и эффективный способ с хорошей переносимостью.

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

Просто добавьте этот сценарий в каталог из списка PATH, и вы сможете заменить все вызовы echo -n командой echon, надежно помещающей текстовый курсор в конец строки после вывода.

Результаты

Для демонстрации функции echon сценарий принимает аргумент и выводит его, затем читает ввод пользователя. В листинге 1.19 показан сеанс тестирования сценария.

Листинг 1.19. Тестирование команды echon

$ echon "Enter coordinates for satellite acquisition: "

Enter coordinates for satellite acquisition: 12,34

Усовершенствование сценария

Скажем честно: тот факт, что одни командные оболочки имеют команду echo, поддерживающую флаг -n, другие предполагают использование специального символа \c в конце вывода, а третьи вообще не дают возможности подавить отображение символа перевода строки, доставляет массу проблем создателям сценариев. Чтобы устранить это несоответствие, можно написать свою функцию, которая автоматически проверит поведение echo, определит, какая версия используется в системе и затем изменит вызов соответственно. Например, можно выполнить команду echo -n hi | wc -c и проверить количество символов в результате: два (hi), три (hi плюс символ перевода строки), четыре (-n hi) или пять (-n hi плюс символ перевода строки).

№ 9. Вычисления произвольной точности с вещественными числами

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

echo $(( 1 / 2 ))

То есть вычисления с большей точностью превращаются в проблему. Существует не так много хороших программ-калькуляторов, работающих в командной строке. Одна из них — замечательная программа bc, которой владеют очень немногие пользователи Unix. Позиционирующая себя как калькулятор для вычислений с произвольной точностью, bc появилась на заре развития Unix, славится малопонятными сообщениями об ошибках и отсутствием подсказок. Предполагается, что пользователь и так знает, что делает. Но в этом есть свои плюсы. Мы можем написать сценарий-обертку, делающий программу bc более дружественной, как показано в листинге 1.20.

Код

Листинг 1.20. Сценарий scriptbc

  #!/bin/bash

  # scriptbc -- обертка для 'bc’, возвращающая результат вычислений

  if ["$1" = "-p" ] ; then

    precision=$2

    shift 2

  else

    precision=2 # По умолчанию

  fi

  bc -q -l << EOF

    scale=$precision

    $*

  quit

EOF

exit 0

Как это работает

Синтаксис << в строке  позволяет включить в сценарий произвольное содержимое и интерпретировать его как текст, введенный непосредственно в поток ввода, что в данном случае дает простой способ передачи команд программе bc. Такие вставки называют встроенными документами (here document). Вслед за парой символов << помещается текстовая метка, которая будет интерпретироваться как признак конца такого потока ввода (при условии, что она находится в отдельной строке). В листинге 1.20 используется метка EOF.

Этот сценарий демонстрирует также, как использовать аргументы для увеличения гибкости команд. В данном случае сценарий можно вызвать с флагом -p  и указать желаемую точность чисел для вывода. Если точность не указана, по умолчанию используется точность scale=2 .

Работая с программой bc, важно понимать разницу между ее параметрами length (длина) и scale (точность). В терминологии bc под длиной (length) понимается общее количество цифр в числе, а под точностью (scale) — количество цифр после десятичной точки. То есть число 10,25 имеет длину 4 и точность 2, а число 3,14159 имеет длину 6 и точность 5.

По умолчанию bc имеет переменное значение для length, но, так как параметр scale по умолчанию получает нулевое значение, без параметров программа bc действует подобно синтаксической конструкции $(( )). К счастью, если в вызов bc добавить параметр scale, она продемонстрирует огромную скрытую мощь, как показано в следующем примере, где вычисляется количество недель между 1962 и 2002 годами (исключая високосные дни):

$ bc

bc 1.06.95

Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation,

Inc.

This is free software with ABSOLUTELY NO WARRANTY.

For details type 'warranty’.

scale=10

(2002-1962)*365

14600

14600/7

2085.7142857142

quit

Чтобы получить доступ к возможностям bc из командной строки, сценарий-обертка должен удалить начальную информацию об авторских правах, если она имеется, однако большинство реализаций bc автоматически подавляют вывод начального баннера, если вводом является не терминал (stdin). Кроме того, сценарий-обертка определяет довольно разумное значение для масштаба (scale), передает программе bc фактическое выражение и затем завершает ее командой quit.

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

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

Результаты

Листинг 1.21. Тестирование сценария scriptbc

$ scriptbc 14600/7

2085.71

$ scriptbc -p 10 14600/7

2085.7142857142

№ 10. Блокировка файлов

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

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

while [ -f $lockfile ] ; do

  sleep 1

done

touch $lockfile

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

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

К счастью, Стефан ван ден Берг (Stephen van den Berg) и Филип Гюнтер (Philip Guenther), авторы программы procmail для фильтрации электронной почты, также создали утилиту командной строки lockfile, которая дает возможность безопасной и надежной работы с файлами-блокировками в сценариях командной оболочки.

Многие реализации Unix, включая GNU/Linux и OS X, устанавливают утилиту lockfile по умолчанию. Ее присутствие в системе можно проверить простой командой man 1 lockfile. Если в результате откроется страница справочного руководства, значит, удача сопутствует вам! Сценарий в листинге 1.22 предполагает наличие команды lockfile, и все последующие сценарии требуют работоспособности механизма надежной блокировки, реализованного в сценарии № 10, поэтому перед их использованием также проверьте наличие команды lockfile в вашей системе.

Код

Листинг 1.22. Сценарий filelock

  #!/bin/bash

  # filelock -- Гибкий механизм блокировки файлов

  retries="10"           # Число попыток по умолчанию

  action="lock"          # Действие по умолчанию

  nullcmd="’which true’" # Пустая команда для lockfile

  while getopts "lur:" opt; do

    case $opt in

      l ) action="lock" ;;

      u ) action="unlock" ;;

      r ) retries="$OPTARG" ;;

    esac

  done

  shift $(($OPTIND - 1))

  if [ $# -eq 0 ] ; then # Вывести в stdout многострочное сообщение об ошибке.

    cat << EOF >&2

      Usage: $0 [-l|-u] [-r retries] LOCKFILE

      Where -l requests a lock (the default), -u requests an unlock, -r X

      specifies a max number of retries before it fails (default = $retries).

  EOF

    exit 1

  fi

  # Проверка наличия команды lockfile.

  if [ -z "$(which lockfile | grep -v '^no ')" ] ; then

    echo "$0 failed: 'lockfile' utility not found in PATH." >&2

    exit 1

  fi

  if [ "$action" = "lock" ] ; then

    if ! lockfile -1 -r $retries "$1" 2> /dev/null; then

      echo "$0: Failed: Couldn't create lockfile in time." >&2

      exit 1

    fi

  else # Действие = разблокировка

    if [ ! -f "$1" ] ; then

      echo "$0: Warning: lockfile $1 doesn't exist to unlock." >&2

      exit 1

    fi

    rm -f "$1"

  fi

  exit 0

Как это работает

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

Если говорить более конкретно, первый блок  использует мощную функцию getopts для анализа всех поддерживаемых флагов (-l, -u, -r) в цикле while. Это наиболее типичный способ использования getopts, который снова и снова будет встречаться в книге. Обратите внимание на команду shift $(($OPTIND - 1 )) в строке : переменная OPTIND устанавливается функцией getopts, благодаря чему сценарий получает возможность сдвинуть входные параметры вниз (то есть значение параметра $2 сместится в параметр $1, например), вытолкнув тем самым обработанные параметры, начинающиеся с дефиса.

Поскольку этот сценарий использует системную утилиту lockfile, он сначала проверяет ее доступность в списке путей пользователя  и завершается с сообщением об ошибке, если утилита недоступна. Далее следует простая условная инструкция , выясняющая, какая операция запрошена — блокировка или разблокировка, — и производится соответствующий вызов утилиты lockfile.

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

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

Результаты

Сначала создадим заблокированный файл, как показано в листинге 1.23.

Листинг 1.23. Создание файла-блокировки командой filelock

$ filelock /tmp/exclusive.lck

$ ls -l /tmp/exclusive.lck

-r--r--r--  1 taylor  wheel  1 Mar 21 15:35 /tmp/exclusive.lck

Когда в следующий раз вы попытаетесь установить ту же блокировку, filelock выполнит указанное количество попыток (10 по умолчанию) и завершится с ошибкой (как показано в листинге 1.24):

Листинг 1.24. Ошибка при попытке создать файл-блокировку обращением к сценарию filelock

$ filelock /tmp/exclusive.lck

filelock : Failed: Couldn’t create lockfile in time.

Завершив работу с файлом, можно освободить блокировку, как показано в лис­тинге 1.25.

Листинг 1.25. Освобождение блокировки с помощью сценария filelock

$ filelock -u /tmp/exclusive.lck

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

Усовершенствование сценария

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

Скорее всего, это не затронет вас, но lockfile не поддерживает работу с сетевой файловой системой (NFS) на смонтированных сетевых устройствах. Действительно надежный механизм блокировки файлов в NFS чрезвычайно сложен в реализации. Лучшее решение этой проблемы — всегда создавать файлы-блокировки только на локальных дисках или задействовать специализированный сценарий, способный управлять блокировками, используемыми несколькими системами.

№ 11. ANSI-последовательности управления цветом

Вероятно, вы замечали, что разные приложения командной строки поддерживают разные стили отображения текста. Существует большое количество вариантов оформления. Например, сценарий может выводить определенные слова жирным шрифтом или красным цветом на желтом фоне. Однако работать с ANSI-последовательностями (American National Standards Institute — американский национальный институт стандартов) очень неудобно из-за их сложности. Чтобы упростить их применение, в листинге 1.26 создается набор переменных, значениями которых являются ANSI-последовательности, управляющие цветом и форматированием.

Код

Листинг 1.26. Функция initializeANSI

#!/bin/bash

# ANSI-последовательности управления цветом -- используйте эти переменные

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

#   Имена переменных, оканчивающиеся символом 'f’, соответствуют цветам шрифта

#   (foreground), а имена переменных, оканчивающиеся символом 'b’, соответствуют

#   цветам фона (background).

initializeANSI()

{

  esc="\033" # Если эта последовательность не будет работать,

             #   введите символ ESC непосредственно.

  # Цвета шрифта

  blackf="${esc}[30m";  redf="${esc}[31m";   greenf="${esc}[32m"

  yellowf="${esc}[33m"  bluef="${esc}[34m";  purplef="${esc}[35m"

  cyanf="${esc}[36m";   whitef="${esc}[37m"

  # Цвета фона

  blackb="${esc}[40m";  redb="${esc}[41m";   greenb="${esc}[42m"

  yellowb="${esc}[43m"  blueb="${esc}[44m";  purpleb="${esc}[45m"

  cyanb="${esc}[46m";   whiteb="${esc}[47m"

  # Жирный, наклонный, с подчеркиванием и инверсное отображение

  boldon="${esc}[1m";     boldoff="${esc}[22m"

  italicson="${esc}[3m";  italicsoff="${esc}[23m"

  ulon="${esc}[4m";       uloff="${esc}[24m"

  invon="${esc}[7m";      invoff="${esc}[27m"

  reset="${esc}[0m"

}

Как это работает

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

<b>this is in bold and <i>this is italics</i> within the bold</b>

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

${boldon}this is in bold and ${italicson}this is

italics${italicsoff}within the bold${reset}

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

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

initializeANSI

echo -e "${yellowf}This is a phrase in yellow${redb} and red${reset}"

echo -e "${boldon}This is bold${ulon} this is ul${reset} bye-bye"

echo -e "${italicson}This is italics${italicsoff} and this is not"

echo -e "${ulon}This is ul${uloff} and this is not"

echo -e "${invon}This is inv${invoff} and this is not"

echo -e "${yellowf}${redb}Warning I ${yellowb}${redf}Warning II${reset}"

Результаты

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

Листинг 1.27. Как можно оформить текст с применением переменных из листинга 1.26

This is a phrase in yellow and red

This is bold this is ul bye-bye

This is italics and this is not

This is ul and this is not

This is inv and this is not

Warning I Warning II

Усовершенствование сценария

Запустив этот сценарий, можно увидеть такой вывод:

\033[33m\033[41mWarning!\033[43m\033[31mWarning!\033[0m

Эта проблема может заключаться в отсутствии поддержки управляющих ANSI-последовательностей в программе терминала или неправильной интерпретации формы записи \033 в определении переменной esc. Чтобы устранить последнюю проблему, откройте сценарий в редакторе vi или в другом терминальном редакторе, удалите последовательность \033 и нажмите клавиши ^V (ctrl-V) и esc, в результате должна отобразиться последовательность ^[. Если результат на экране выглядит как esc="^[", все должно заработать, как ожидается.

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

№ 12. Создание библиотечных сценариев

Многие сценарии в этой главе написаны как функции, а не самостоятельные сценарии, то есть их легко можно включить в другие сценарии без увеличения накладных расходов на выполнение дополнительных команд. Даже при том, что в командной оболочке отсутствует директива #include, как в языке C, в ней имеется операция подключения файла-источника (sourcing), которая служит тем же целям, позволяя подключать другие сценарии как библиотечные функции.

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

$ echo "test=2" >> tinyscript.sh

$ chmod +x tinyscript.sh

$ test=1

$ ./tinyscript.sh

$ echo $test

1

Сценарий tinyscript.sh изменяет значение переменной test, но только внутри подоболочки, в которой он выполняется, то есть не затрагивая значение переменной test в текущей оболочке. Если выполнить сценарий с помощью точки (.), подключающей файл-источник, этот сценарий выполнится в текущей оболочке:

$ . tinyscript.sh

$ echo $test

2

Как нетрудно догадаться, если подключаемый таким способом сценарий выполнит команду exit 0, произойдет выход из текущей оболочки и окно программы терминала закроется, потому что операция подключения выполняет подключаемый сценарий в текущем процессе. В подоболочке команда exit произведет выход из нее, не вызвав остановки основного сценария. Это главное отличие и одна из причин, влияющих на выбор между командами . или source и exec (как будет показано ниже). Команда . фактически идентична команде source в bash; мы использовали точку просто потому, что такая форма подключения файлов более переносима между разными POSIX-совместимыми командными оболочками.

Код

Чтобы превратить функции, представленные в этой главе, в библиотеку для использования в других сценариях, извлеките все функции и необходимые глобальные переменные или массивы (то есть значения, общие для нескольких функций) и поместите их в один большой файл. Если назвать этот файл library.sh, его можно использовать, как показано в тестовом сценарии из листинга 1.28, для доступа ко всем функциям, написанным в этой главе, и их проверки.

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

  #!/bin/bash

  # Сценарий тестирования библиотеки

  # Сначала подключить (прочитать) файл library.sh.

  . library.sh

  initializeANSI # Настроить управляющие ANSI-последовательности.

  # Проверить функцию validint.

  echon "First off, do you have echo in your path? (1=yes, 2=no) "

  read answer

  while ! validint $answer 1 2 ; do

    echon "${boldon}Try again${boldoff}. Do you have echo "

    echon "in your path? (1=yes, 2=no) "

    read answer

  done

  # Проверить работу функции поиска команды в списке путей.

  if ! checkForCmdInPath "echo" ; then

    echo "Nope, can't find the echo command."

  else

    echo "The echo command is in the PATH."

  fi

  echo ""

  echon "Enter a year you think might be a leap year: "

  read year

  # Убедиться, что значение года находится в диапазоне между 1 и 9999,

  #   с помощью validint, передав ей минимальное и максимальное значения.

  while ! validint $year 1 9999 ; do

    echon "Please enter a year in the ${boldon}correct${boldoff} format: "

    read year

  done

  # Проверить, является ли год високосным.

  if isLeapYear $year ; then

    echo "${greenf}You're right! $year is a leap year.${reset}"

  else

    echo "${redf}Nope, that's not a leap year.${reset}"

  fi

  exit 0

Как это работает

Обратите внимание, что библиотека и все содержащиеся в ней функции включаются в окружение сценария выполнением единственной строки .

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

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

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

Результаты

Листинг 1.29. Запуск сценария library-test

$ library-test

First off, do you have echo in your PATH? (1=yes, 2=no) 1

The echo command is in the PATH.

Enter a year you think might be a leap year: 432423

Your value is too big: largest acceptable value is 9999.

Please enter a year in the correct format: 432

You’re right! 432 is a leap year.

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

Исторически 432 год не считается високосным, потому что учет високосных лет не производился до 1752 года. Но мы говорим о сценариях командной оболочки, а не о хитрости летоисчисления, так что оставим эту неточность без внимания.

№ 13. Отладка сценариев

Этот раздел не содержит настоящего сценария, но мы хотели бы потратить несколько страниц в книге, чтобы поговорить об основах отладки сценариев, потому что рано или поздно вы все равно столкнетесь с ошибками!

По нашему опыту, лучшая стратегия отладки — наращивать возможности сценариев постепенно. Некоторые программисты оптимистично надеются, что все заработает правильно с первого раза, но вы будете по-настоящему уверенно двигаться вперед, если начнете с малого. Кроме того, для трассировки переменных можно свободно использовать команды echo, а также запускать сценарии командой bash -x, чтобы обеспечить вывод отладочной информации, например:

$ bash -x myscript.sh

Как вариант, можно добавить команду set -x перед началом отлаживаемого фрагмента и set +x — после него, как показано ниже:

$ set -x

$ ./myscript.sh

$ set +x

Чтобы увидеть, как действуют флаги -x и +x, попробуем отладить простую игру «угадай число», представленную в листинге 1.30.

Код

Листинг 1.30. Сценарий hilow, возможно содержащий несколько ошибок, который нужно отладить. . .

  #!/bin/bash

  # hilow -- Простая игра "угадай число"

  biggest=100                # Максимальное возможное число

  guess=0                    # Число, предложенное игроком

  guesses=0                  # Количество попыток

  number=$(( $$ % $biggest ) # Случайное число от 1 до $biggest

  echo "Guess a number between 1 and $biggest"

  while [ "$guess" -ne $number ] ; do

    /bin/echo -n "Guess? " ; read answer

    if [ "$guess" -lt $number ] ; then

      echo "... bigger!"

    elif [ "$guess" -gt $number ] ; then

      echo "... smaller!

    fi

    guesses=$(( $guesses + 1 ))

  done

  echo "Right!! Guessed $number in $guesses guesses."

  exit 0

Как это работает

Чтобы было понятнее, как происходит получение случайного числа в , напомним, что специальная переменная $$ хранит числовой идентификатор процесса (Process ID, PID) командной оболочки, в которой выполняется сценарий. Обычно это 5- или 6-значное число. При каждом запуске сценарий получает новый PID. Последовательность % $biggest делит значение PID на заданное наибольшее значение и возвращает остаток. Иными словами, 5 % 4 = = 1, так же как 41 % 4. Это простой способ получения псевдослучайных чисел в диапазоне от 1 до $biggest.

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

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

$ echo $(( $$ % 100 ))

5

$ echo $(( $$ % 100 ))

5

$ echo $(( $$ % 100 ))

5

Операция работает, но числа не выглядят случайными. Если немного поразмыслить, становится понятно, почему так происходит: когда команда выполняется непосредственно в командной строке, она всегда получает одно и то же значение PID; но внутри сценария команда каждый раз будет выполняться в другой подоболочке, с другим значением PID.

Еще один способ получить случайное число — воспользоваться переменной окружения $RANDOM. Это не простая переменная! При каждом обращении к ней вы будете получать разные значения. Чтобы получить число в диапазоне от 1 до $biggest, используйте в строке  выражение $(( $RANDOM % $biggest + 1 )).

Следующий шаг — добавление основной логики игры. В  генерируется случайное число в диапазоне от 1 до 100; в  пользователь делает попытку угадать это число; затем пользователю сообщается, что число слишком большое  или слишком маленькое , пока он наконец не угадает правильное значение. После ввода всего основного кода можно попробовать запустить сценарий и посмотреть, как он работает. Ниже демонстрируется проверка работы сценария из листинга 1.30:

$ hilow

./013-hilow.sh: line 19: unexpected EOF while looking for matching '"’

./013-hilow.sh: line 22: syntax error: unexpected end of file

Опля! Мы столкнулись с проклятием разработчиков сценариев: неожиданный конец файла (EOF). Сообщение говорит, что ошибка находится в строке 19, но это не означает, что она действительно там. На самом деле строка 19 не содержит ошибок:

$ sed -n 19p hilow

echo "Right!! Guessed $number in $guesses guesses."

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

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

$ grep '"' 013-hilow.sh | egrep -v '.*".*".*'

echo "... smaller!

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

$ hilow

./013-hilow.sh: line 7: unexpected EOF while looking for matching ')’

./013-hilow.sh: line 22: syntax error: unexpected end of file

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

number=$(( $$ % $biggest ) # Случайное число от 1 до $biggest

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

$ hilow

Guess? 33

... bigger!

Guess? 66

... bigger!

Guess? 99

... bigger!

Guess? 100

... bigger!

Guess? ^C

Почти получилось. Но при попытке ввести максимально возможное значение 100 появляется ответ, что загаданное число больше (bigger), значит, в логике игры допущена ошибка. Искать такие ошибки особенно сложно, потому что никакая, даже самая замысловатая команда grep или sed не поможет выявить проблему. Вернитесь к коду и попробуйте найти ошибку самостоятельно.

Чтобы упростить поиск, можно добавить несколько команд echo, вывести значение, выбранное пользователем, и проверить, какое число введено и какое проверяется. Соответствующий раздел кода начинается в строке , но для удобства приведем эти строки еще раз:

/bin/echo -n "Guess? " ; read answer

if [ "$guess" -lt $number ] ; then

Изменив команду echo и исследовав эти две строки, мы заметили ошибку: ввод пользователя читается в переменную answer, а проверяется переменная guess. Глупая, но не такая уж редкая ошибка (особенно если имеются переменные с необычными для вас именами). Чтобы исправить ошибку, нужно заменить read answer на read guess.

Результаты

Наконец сценарий работает правильно, как показано в листинге 1.31.

Листинг 1.31. Сценарий hilow работает без ошибок

$ hilow

Guess? 50

... bigger!

Guess? 75

... bigger!

Guess? 88

... smaller!

Guess? 83

... smaller!

Guess? 80

... smaller!

Guess? 77

... bigger!

Guess? 79

Right!! Guessed 79 in 7 guesses.

Усовершенствование сценария

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

if [ -z "$guess" ] ; then

  echo "Please enter a number. Use ^C to quit"; continue;

fi

Но непустой ввод еще не означает, что введено число, и, если ввести произвольную сроку, например hi, сценарий все еще будет завершаться с ошибкой. Чтобы исправить эту проблему, добавьте вызов функции validint из сценария № 5.