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

t В системе UUIX замените команлу dir /В Is -1 open(RHAKDLE, "dir /в sort

die "Ошибка при откргтие конвейера для чтения: $!";

В этом примере функция open открывает конвейер для чтения данных, полученных в результате выполнения цепочки команд dir /В sort. Вертикальная черта, расположенная в цепочке команд крайней справа, говорит о том, что конвейер открывается для чтения. При выполнении функции open Perl запускает цепочку команд dir /В sort и помещает полученные от команды sort данные во временный файл. Поэтому при чтении дескриптора ЬИШЕ эти данные нoнaдJ- в программу на Perl для дальнейщей обработки.

А теперь рассмотрим еще один пример: open(WHANDLE, " more")

die "Ошибка при открытии конвейера для записи: $!";

В этом случае функция open открывает конвейер для записи данных, которые подаются на вход команды more. Вертикальная черта, расположенная в цепочке команд крайней слева, говорит о том, что конвейер открывается для записи. Таким образом, все данные, выведенные в дескриптор tPNDH, будут переданы в буфер программы more для поэкранного отображения. Кстати, вот вам один из способов, как можно заставить программу отображать данные постранично.

После того как будут закончены все операции чтения/записи с дескрипторами наподобие БВ*М11Е и WHnII нужно обязательно закрыть эти дескрипторы и соответствующие им конвейеры. Тогда сможет корректно завершиться программа, запушенная функцией open. Если же после окончания работы с конвейером оставить дескриптор открытым, то внешняя программа останется в подвешенном состоянии после того, как программа на Perl завершит свою работу.

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

успешно или нет был закрыт конвейер, как показано ниже: close (HHAHDLE) 1} vBcn "СПив Зсьлии коер: $1";

При изучении материала этого раздела у вас мог возникнуть вопрос; "Почему во время открытия конвейера с помощью функции open по коду возврата нельзя судить о том, успещно или нет была выполнена обработка данных?" Все дело в архитектуре системы UNIX. После того как интерпретатор Perl создал конвейер и выдал команду на его запуск, операционная система не обязательно сразу его запустит на выполнение. Поэтому остается надеяться, что если конвейер создан правильно и успешно запущен, то он корректно и завершит свою работу. После того как последняя программа в цепочке закончит свою работу, она должна вер-нь соответствующий код возврата. Функция close считывает этот код, анализирует его, принимает решение о том, успешно или нет была выполнена обработка данных, и возвращает соответствующий код возврата.

Общие сведения о переносимости программ

Переносимость - это одно из основных преимуществ г1, благодаря которому он и завоевал столь широкую популярность- Интерпретатор Perl гарантирует, что программа практически без изменений будет работать одинаково на любой из поддерживаемых

компьютерна: opJH (VMS, UNIX, Macintosh или DOS). Если в программе используются средства взаимодействия с операционной системой, такие как операции ввода/вывода, интерпретатор пытается самостоятельно выполнить всю черновую работу

и скрыть от программиста детали, обеспечивая при этом работоспособность кода. Однако в некоторых редких случаях требуется вмешательство программиста.

На 16-м занятии, "Сообщество РегГ, мы обсудим более подробно причины столь высокой переносимости программ на Perl.

На этом занятии мы уже не раз отмечали, что некоторые участки программ будут

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

программы создает проблемы при разработке версии программы для третьей операци-

оппой системы, например MacOS 9.

сказанное выше вовсе не означает, что профаммы на написанные для

одной компьютерной платформы, например Windows NT, не будут работать на другой, например UNIX. Более того, чаще всего именно так и происходит - профаммист работает в одной системе, а пользователи профаммы в другой. У некоторых пользователей даже складывается такое впечатление, что, поскольку интерпретатор Perl создан для большинства современных компьютерных платформ, выполнение

программы в среде Windows NT ничем не отличается от среды UNIX. Переносимые

профаммы имеет смысл создавать только в том случае, если они предназначены для работы на различных компьютерных платформах, как, например, Web-серверы и вспомогательные профаммы для них.

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

• Всегда включайте режим выдачи предупреждений и используйте директиву use strict. Это позволит гарантировать, что ваш код будет корректно выполняться различными интерпретаторами Perl и что в профамме не будет фубых ошибок, о которых может предупредить компилятор.

• Всегда проверяйте коды возврата после вызова системных функций. Например, при открытии файла используйте конструкцию open 11 die. Никогда не используйте оператор open сам по себе. Проверка кодов возврата позволяет выявить ошибки при переносе профамм с одного сервера на другой, а не

только от одной платформы на другую.

• Выводите краткие, но понятные сообщения об ошибках.

• По возможности отдавайте приоритет встроенным функциям перед функцией system и помещением вызова внешней профаммы в обратные кавычки.

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

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

С третьей рекомендацией о выводе понятных сообщений об ошибках трудно не

согласиться. В самом деле, что может быть понятнее сообщений, приведенных ниже?

(по message, or rong output) Died at line 15.

Cannot open Foofile.txt: No such file or directory

Cannot open Foofile.txt: No such file or directory at myscript.pl line 24

Очевидно, что последняя строка наиболее информативна. И даже если с момента написания программы пройдет достаточно много времени, вы всегда сможете определить место в программе (файл myscript.pl, строка 24), где произошла ошибка, и причину (не найден файл Foofile.txt) сбоя. Такая подробная информация поможет быстро устранить проблему. При написании программы не жалейте нескольких минут времени на создание хороших, информативных сообщений об ошибке. В будущем оно окупится сторицей.

Четвертая рекомендация означает, что везде, где только возможно, нужно использовать встроенные средства Pert. Например, для получения списка файлов каталога проще всего воспользоваться оператором наподобие $dir=dir\ Однако он не будет

работать на платформах, отличных от Windows. Поэтому лучше воспользоваться конструкцией <*> либо набором • функций opendir/readdir/closedir (что предпочтительнее). При таком подходе ваша программа будет работать на любой платформе.

Как быть с отличиями?

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

При написании программ на Perl не стоит забывать, что рано или поздно настанет момент, когда их придется запускать в другой операционной системе или на компьютере другого типа. А вдруг вы создадите нечто наподобие Web-сервера ашагоп.сот, и ваш IBM PC не будет справляться с нахлынувшим потоком посетителей? Тогда вам придется перенести свой сервер на более мощный компьютер под управлением Windows NT или UNIX, или даже поместить его в кластер, состоящий из 10000 серверов

UNIX на базе Sun Enterprise. Или другой более реалистичный пример. Предположим,

что вы пользуетесь некоторым CGI-сценарием и решили поменять Web-провайдера,

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

Итак, как же программа сможет определить, на какой платформе она выполняется, и учесть отличия между Windows и UNIX? Все очень просто. В Perl предусмотрена специальная переменная SO (знак доллара, за которым следуют символ вставки и прописная буква О), содержащая имя архитектуры компьютерной платформы, на которой выполняется программа. Например, в среде Windows и DOS ей присвоена строка MSWin32. В UNIX с помощью данной переменной можно определить тип операционной системы: linux, aix, solaris, freebsd и т.д.

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

• Поиск какой-либо информации, относящейся к конфигурации операционной системы.