Мануал по PERL

Собственно, сабж.
Лучше на русском.

А чем не устраивают имеющиеся в Интернете ?

Ладно. не будем занудствовать...
ссылка
ссылка
ссылка
ссылка

Вообще в гугле всё это надо искать, или на профильных форумах.

Pilat66, спасибо

И ещё возник вопрос: в Perl есть встроенные методы работы с XML?

Цитата ("SolNikolay"):

И ещё возник вопрос: в Perl есть встроенные методы работы с XML?

Что значит встроенные?
Если имеете ввиду бинарник перла -то туда ничего не встроено кроме парсера синтаксиса, компилятора и т.д.
А вообще с перлом в комплекте идут сотни библиотек, из которых большое количество для работы с XML.
Если чего-то не хватает - всегда можете скачать и установить со CPAN или интерактивно, или вручную.

Поддержка XML в Perl намного богаче чем во многих других языках, включая PHP 5.

tvv, вот про библиотеки я и спрашиваю. Какие ставить-то надо?

Цитата ("SolNikolay"):

tvv, вот про библиотеки я и спрашиваю. Какие ставить-то надо?

А это зависит от того, что Вы хотите с XML делать.
Если какие-то простые операции, то ничего дополнительного ставить не потребуется, того что идет в комплекте может быть достаточно.
Кстати, и сборки перла бывают разные, некоторые сборки (например ActiveState) имеют очень большой набор библиотек в том числе и для расширенной работы с XML, другие имеют меньший набор библиотек, и т.д.

tvv, гмм, парсить имеющиеся, создавать новые. А что с ними ещё можно делать?

Цитата ("SolNikolay"):

tvv, гмм, парсить имеющиеся, создавать новые. А что с ними ещё можно делать?

Очень многое можно делать. Слышали ли например про XSLT и про XPath? Очень рекомендую, ознакомьтесь, откроются глаза на многие вещи. Например окажется, что очень большое количество задач можно решать вообще без программирования, используя только лишь возможности XML-based технологий.

SolNikolay, скачайте себе Perl ActiveState, там в комплекте идут необходимые библиотеки, и отличнейший мануал с примерами.

Вот ссылка: ссылка
Можете не только в Linux работать, но и в Windows. В Linux тоже можете или использовать сборку с ActiveState, или использовать любую другую. Но если другую, то, возможно, понадобится скачать с CPAN либы, которых может не быть (я не могу сказать какие, так как я не имею представления какая у Вас сборка Perl).

tvv, про XSLT и про XPath слыщал. За ссылку спасибо.

А скачать под Unix/Linux элементарно - если скрипт ругается на отсутствие той или иной либы, просто выполняете делаете
perl -MCPAN -e shell
затем в открывшейся консоли например
install yourpackagename
и т.д. смотрите что будет, возможно следуете подсказкам визарда и т.д.

tvv, спасибо, но у меня винда Вот решил попробовать написать грабер маленький. Помнится вы говорили, что Perl для этого больше подходит, нежели php. Вот и проверим

Цитата ("SolNikolay"):

tvv, спасибо, но у меня винда Вот решил попробовать написать грабер маленький. Помнится вы говорили, что Perl для этого больше подходит, нежели php. Вот и проверим

Ну тогда вообще без проблем - скачиваете оборку Perl ActiveState, там есть все что Вам на этом этапе понадобится для работы с XML, и там же после установки будет доступен отличнейший мануал, в том числе и по либам для работы с XML, с примерами кода.

Для грабера Вас еще понадобится LWP, он тоже входит в сборку Perl ActiveState. Для доступа к внешним ресурсам. Вот это действительно мощь, если до этого Вы работали только с PHP/CURL, то сможете осознать насколько больше возможностей имеет Perl.

Цитата ("tvv"):

А скачать под Unix/Linux элементарно - если скрипт ругается на отсутствие той или иной либы, просто выполняете делаете
perl -MCPAN -e shell
затем в открывшейся консоли например
install yourpackagename
и т.д. смотрите что будет, возможно следуете подсказкам визарда и т.д.

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

Цитата ("Pilat66"):

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

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

Собранных пакетов таких перловых модулей обычно бывает всего лишь 25-30, покрываются самые распространенные модули. А вот если Вам нужно что-то другое из тысяч модулей со CPAN, а пакета такого нет для данной сборки линукса, что Вы тогда делать будете? Не говоря уже о том, что в пакетах обычно далеко не последние версии модулей. Я считаю этот подход непрофессиональным.

Вы наверное не в курсе, что при таком (perl -MCPAN -e shell) способе установки максимально корректно учитываются зависимости между перловыми модулями и их версиями, и если какой-то другой модуль, необходимый для работы данного модуля, не установлен, то его установка произведется автоматически. Проблем не вижу.

Цитата ("tvv"):

Цитата ("Pilat66"):

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

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

Собранных пакетов таких перловых модулей обычно бывает всего лишь 25-30, покрываются самые распространенные модули. А вот если Вам нужно что-то другое из тысяч модулей со CPAN, а пакета такого нет для данной сборки линукса, что Вы тогда делать будете? Не говоря уже о том, что в пакетах обычно далеко не последние версии модулей. Я считаю этот подход непрофессиональным.

25-30? А Вы считали? К примеру, в Debian больше тысячи перловых пакетов, некоторые из них содержат по несколько модулей из CPAN (например libtime-modules-perl - 5 модулей). Очень немногие модули не в дистрибутиве - по крайней мере те, которые нужны на практике.

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

Даже простая сборка собственных пакетов (в Debian -
это .deb , в RedHat - это .rpm файлы) прибавляет любой системе надёжности, а проекту - переносимость с машины на машину.

Цитата ("tvv"):

Вы наверное не в курсе, что при таком (perl -MCPAN -e shell) способе установки максимально корректно учитываются зависимости между перловыми модулями и их версиями, и если какой-то другой модуль, необходимый для работы данного модуля, не установлен, то его установка произведется автоматически. Проблем не вижу.

Вы не видите проблем, потому что не практик.

Сборка модуля под perl - это не вызов "perl -MCPAN -e shell", как может показаться на первый взгляд. Это ещё и установка дополнительных библиотек. Некоторые модули в принципе плохо ставятся автоматически. Некоторые приходится править. Например, для поддержки того же XML придётся что-то поставить, что именно - можно прочитать в документации, но cpan это делать не будет. Некоторые модули имеют необязательные зависимости, которые тоже надо учитывать.

Если в перловом модуле будет найдена критическая ошибка, есть вероятность, что при очередном обновлении системы будет установлена новая версия. Самостоятельно таскать модули из CPAN - непозволительная роскошь, чего будет стоить один запуск юниттестов для каждого такого апдейта и потом поиск причин ошибок.

В общем, не стоит так категорически рассуждать о малознакомом предмете. Хотя странно, в резюме у Вас есть достаточно работ, хотя с перлом только одна. Неужели ничего из того, о чём я написал, Вы не встречали на практике? Ведь всё это относится не только к перлу, а и к другому языку с набором библиотек.

Цитата ("Pilat66"):

Вы не видите проблем, потому что не практик.

В общем, не стоит так категорически рассуждать о малознакомом предмете. Хотя странно, в резюме у Вас есть достаточно работ, хотя с перлом только одна. Неужели ничего из того, о чём я написал, Вы не встречали на практике? Ведь всё это относится не только к перлу, а и к другому языку с набором библиотек.

Как-никак, использую Perl с 1998 года, он остается моим основным языком программирования и до сих пор помимо Java и PHP. В том числе и тут на Webalncer.net выполнил несколько перловых проектов для разных заказчиков.

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

Вы согласны? Или на практике Вы не встречали такого? Я больше склонен считать что именно Вам не хватает практики, если не встречали таких проблем.

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

Кстати, раз уж критикуете мое портфолио, потрудитесь выложить свое. Сейчас у Вас вообще портфолио отсутствует. Но заметьте, я не утверждаю что у Вас нет портфолио потому, что Вы не знаете Perl. Скорее всего у Вас его "нет" по той же причине что и у меня - лень добавлять туда работы.

Pilat66, Насчет пакетов... Кстати, из множества дистрибутивов линуксов предпочитаю именно Slackware. И то что там нет жесткой привязки к логике зависимостей пакетов считаю скорее плюсом чем минусом. Чем уже рамки позволенного, тем больше стабильность, но только в пределах этих узких рамок. Впрочем это уже холивар, у каждого свои подходы.

он остается моим основным языком программирования
а я то думаю почему он "лучше работает с XML"... да и с сокетами тоже