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

… 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.

Типичная система Unix или Linux по умолчанию включает сотни команд, которые, с учетом многообразия флагов и способов сочетания команд посредством каналов, дают миллионы разных вариантов работы в командной строке.

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

Листинг 2.1.Подсчет количества выполняемых и невыполняемых файлов в текущем списке PATH

#!/bin/bash

# Подсчет количества команд: простой сценарий для подсчета количества выполняемых

#·· команд в каталогах из списка PATH

IFS=":"

count=0; nonex=0

for directory in $PATH; do

··if [-d "$directory"]; then

····for command in "$directory"/*; do

······if [-x "$command"]; then

········count="$(($count + 1))"

······else

········nonex="$(($nonex + 1))"

······fi

····done

··fi

done

echo "$count commands, and $nonex entries that weren't executable"

exit 0

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

Очевидно, что разные версии Linux и Unix предлагают разное количество команд и сценариев. Почему их так много? Ответ заключается в основополагающей философии Unix: всякая команда должна делать что-то одно и делать это хорошо. Текстовый процессор, включающий функции проверки орфографии, поиска файлов и работы с электронной почтой, возможно, хорошо подходит для мира Windows и Mac, но в командной строке все эти функции должны существовать и быть доступны по отдельности.

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

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

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

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

Однако в некоторых системах Unix команда fmt отсутствует. В особенности это относится к устаревшим системам, часто имевшим минимальную реализацию.

Как оказывается, команда nroff, входившая в состав Unix с самого начала, является сценарием-оберткой и может использоваться для переноса длинных строк и заполнения коротких строк для их выравнивания, как показано в листинге 2.2.

Листинг 2.2.Сценарий fmt для форматирования длинных текстовых строк

··#!/bin/bash

··# fmt — утилита форматирования текста, действующая как обертка для nroff

··#·· Добавляет два флага: −w X, для задания ширины строк,

··#·· и −h, для расстановки переносов и улучшения выравнивания

··while getopts "hw: " opt; do