2009-07-22 2 views
5

Я нахожусь в процессе ответа на запрос тендера по контракту, который требует приличного количества обработки текста. Основная проблема заключается в том, что клиент хочет иметь возможность запускать это на любой платформе UNIX (HPUX, Solaris, AIX, FreeBSD) или Linux (SLES, RHEL), что может ограничить то, что я использую для этого. Они не хотят, чтобы установка дополнительных инструментов была обязательной.Существуют ли платформы Unix, где Perl не установлен по умолчанию?

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

Было бы удобно перечислить эти платформы в RFT и предоставить клиенту вариант, по какому пути они хотят идти. У меня есть смутное воспоминание о том, что это не во FreeBSD при установке по умолчанию, и может также быть, что на платформах, отличных от Linux, также нет этого.

Любые другие инструменты могут быть предложены, но, учитывая мое знакомство с Perl и awk, они, вероятно, будут единственными в списке.

ответ

13

Вы можете получить версию Perl, скомпилированную практически для любого варианта unix. Perl не должен быть «установлен», но может работать внутри каталога вашего приложения. Я бы связал Perl с моим дистрибутивом, так что вы можете убедиться, что используете ту же версию.

Очень сложно написать скрипт с полной кроссплатформенной оболочкой без тестирования на целевой ОС. Если вы разрабатываете awk-скрипт, вы, вероятно, собираетесь разрабатывать с использованием варианта GNU в Linux, который является надмножеством POSIX awk. Я часто настраиваю исходный исходный код packages on Solaris, и я постоянно нахожу проблемы, когда люди предполагают, что вы используете современную версию инструмента. Например, в Solaris bash не является стандартной оболочкой bourne (/ bin/sh), а echo не принимает никаких параметров. Если вы попытаетесь выполнить код с помощью POSIX awk, вы можете оказаться ограниченным библиотекой регулярных выражений или устаревшими соглашениями.

Perl's artistic licens e позволяет вам связывать его с вашей программой, если вы следуете нескольким простым вещам, таким как сохранение авторских прав в такте.

+0

На самом деле, это хорошая идея (связывание в подкаталоге), поскольку она позволяет мне также управлять версией, хотя мне придется отправлять несколько пакетов (или один пакет с большим количеством поддиректориев perl, выбранных во время выполнения, по одному на платформу). Я проверю лицензию. +1. – paxdiablo

3

Почти каждый * nix (за исключением некоторых для очень ограниченного дискового пространства) установлен Perl. AFAIK, даже FreeBSD. На всякий случай это не так, вы можете преобразовать программу Perl в исполняемый файл, который не нужен perl с PAR::Packer.

+1

Почему * даже * FreeBSD? –

+0

@ Синан, я догадываюсь «даже BSD», так как я смутно думал, что они не отправили его как стандартное, а через порты. – paxdiablo

+2

@Pax Duh! Тогда его ответ имеет смысл. Я использовал FreeBSD с 5-й версии, и все они устанавливали по умолчанию Perl. Система Perl, как правило, старше портов Perl, но есть сценарий оболочки, который позволяет root выбирать, какой Perl будет использоваться по умолчанию. –

2

, даже если Perl может быть установлен почти на всех платформах nix, они могут быть не одной и той же версией, поэтому имейте это в виду. С требованием, чтобы он работал на большинстве * nix, вы можете просто скопировать утилиты shell +. Для разбора файлов awk + shell также может выполнять эту работу. вам просто нужно написать его в «переносном» формате. check this для получения дополнительной информации

+1

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

+1

Я предполагаю, что это будет Perl 5.6. – innaM

+2

Есть несколько (очень странных) платформ, у которых нет хороших портов Perl за пределами 5.004, но в целом 5.6 - хорошая цель - она ​​используется с 2000 года. – ephemient

4

Если клиент не имеет Perl на своих машинах, вы всегда можете использовать Par::Packer для создания исполняемого файла для этой платформы. Это также означает, что вам не нужно беспокоиться об использовании модулей, так как они также будут включены в исполняемый файл.

+0

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

+0

Хм, я бы сказал, что один, вы можете восстановить исходный код из исполняемого файла, и, пока вы его не изменяете, CPAN должен считать, что источник доступен. –

+0

@Weegee, Par :: Packer просто застегивает файлы, поэтому тривиально извлекать любой код. LGPL может потребовать от пользователя создания нового исполняемого файла с измененным кодом, что может быть проблемой. Самый простой способ справиться с этим - включить любые библиотеки в отдельный файл par. Затем ваш основной файл может загрузить дополнительный файл. – daotoad

2

Хотя я бы догадался, что все текущие версии операционных систем, о которых вы упоминаете, устанавливают Perl, конечно же, будут более старые версии, которые этого не сделали и не имеют. Вы также должны знать, что даже такие инструменты, как awk, не были установлены на очень старых версиях UN * X, так как они и другие инструменты программирования были дополнительными дополнениями (за дополнительную плату). Я помню системы Altos, где даже стек TCP/IP был дополнительный пункт расходов, но предположительно не будет идти так далеко назад :-)

Итог: Если ваше приложение действительно нуждается в Perl, вы должны проверить его (через скрипт оболочки Bourne - если он не работает, вы действительно ввернуты), и если не обеспечить какой-либо способ его установки.

0

Коммерческие структуры, как правило, в комплекте с очень старыми версиями Perl.

Смежные вопросы