Эрик Реймонд - Искусство программирования для Unix

Однако по мере увеличения своего размера, shell-программы часто становятся скорее узкоспециальными. Некоторые моменты синтаксиса shell (особенно правила использования кавычек и синтаксис операторов) могут сбить с толку. Данные недостатки, как правило, обусловлены компромиссами в той части конструкции shell, которая связана с языком программирования. Эти компромиссы были внесены, для того чтобы сохранить эффективность shell как интерактивного интерпретатора командной строки.

Программы описывают как "shell-программы" даже если они не написаны исключительно на shell, но в них интенсивно используются С-фильтры, такие как sort(1) , и стандартные мини-языки обработки текста, такие как sed(1) или awk(1) . Однако данный вид программирования в течение нескольких лет идет на убыль. В наши дни подобная сложная связующая логика обычно пишется на Perl или Python, a shell резервируется для простейших упаковщиков (для которых данные языки были бы чрезмерно сложными) и сценариев инициализации системы (которая не предполагает, что они доступны).

Базовое shell-программирование достаточно описано в любой вводной книге по Unix. "The Unix Programming Environment" [39] остается одним из лучших источников для программистов среднего и высокого класса. Реализации или клоны Korn shell представлены в каждой Unix-системе.

Сложные shell-сценарии часто имеют проблемы переносимости не столько из-за самой оболочки, а ввиду сделанных в них предположений о доступности той или иной программы в качестве компонента. Несмотря на то, что в отдельных случаях клоны bash и ksh доступны в операционных системах, отличных от Unix, shell-программы (практически) вообще невозможно перенести за пределы Unix.

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

Почти никогда не возникает необходимость компилировать или устанавливать shell, поскольку все Unix-системы и эмуляторы Unix поставляются с подобными оболочками. Стандартной оболочкой для Linux и других передовых вариантов Unix в настоящее время является bash.

xmlto — управляющий сценарий, который вызывает все команды, необходимые для представления какого-либо XML-DocBook-документа в виде HTML, PostScript, простого текста или любого другого доступного формата (более подробно DocBook рассматривается в главе 18). Сценарий xmltoнаписан в bash.

Детали вызова XSLT-процессора обрабатываются в xmlto с помощью соответствующей таблицы стилей, затем результаты передаются постпроцессору. Для HTML и XHTML вся обработка сводится к трансформации. Для получения простого текста XML также трансформируется в HTML, а затем передается постпроцессору — lynx(1) в режиме -dump, который преобразовывает HTML в простой текст. Для получения PostScript XML трансформируется в XML FO (Formatting Objects — объекты форматирования), которые постпроцессор затем преобразовывает в T EX-макрос, DVI-формат посредством tex(1) , а затем, наконец, в PostScript с помощью широко известного инструмента dvi2ps(1) .

xmltoсостоит из одного интерфейсного shell-сценария. Он вызывает одну из нескольких подключаемых подпрограмм, каждая из которых названа по имени целевого формата. Каждая подключаемая подпрограмма представляет собой shell-сценарий. В зависимости от того как она вызвана, подключаемая подпрограмма либо предоставляет клиентской части таблицу стилей, либо вызывает соответствующий постпроцессор (или постпроцессоры) с различными заранее заданными аргументами.

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

Программа xmltoявляется хорошим примером shell-приложения среднего размера. Использование С или С++ не имело бы смысла, поскольку они неудобны для написания сценариев. Для такой программы можно было бы использовать любой из языков сценариев, описанных в данной главе; однако программа состоит только из простых команд управления без внутренних структур данных или сложной логики, поэтому достаточно использовать shell, так как это дает значительное преимущество — повсеместное распространение на целевых системах.