Поиск…


Синтаксис

  • требуется Module :: Name; # Требовать по имени от @INC
  • требуется «путь / в / файл.pm»; # Требовать относительный путь от @INC
  • используйте Module :: Name; # require и импорт по умолчанию на BEGIN
  • используйте Module :: Name (); # требуется и не импортировать в BEGIN
  • используйте Module :: Name (@ARGS); # требуется и импортировать с помощью args в BEGIN
  • use Module :: Name VERSION; # require, проверка версии и импорт по умолчанию в BEGIN
  • используйте Module :: Name VERSION (); # require, проверка версии и отсутствие импорта в BEGIN
  • используйте Module :: Name VERSION (@ARGS); # require, проверка версии, импорт с args в BEGIN
  • do "path / to / file.pl"; # загрузить и eval данный файл

Выполнение содержимого другого файла

do './config.pl';

Это прочитает содержимое файла config.pl и выполнит его. (См. Также: perldoc -f do .)

NB: Избегайте do если do не играете в гольф или что-то еще, поскольку проверка ошибок отсутствует. Для включения библиотеки модулей, использование require или use .

Загрузка модуля во время выполнения

require Exporter;

Это обеспечит загрузку модуля Exporter во время выполнения, если он еще не был импортирован. (См. Также: perldoc -f require .)

NB: Большинство пользователей должны use модули, а не require их. В отличие от use , require не вызывает метод импорта модуля и выполняется во время выполнения, а не во время компиляции.

Этот способ загрузки модулей полезен, если вы не можете решить, какие модули вам нужны до запуска, например, с помощью системы плагинов:

package My::Module;
my @plugins = qw( One Two );
foreach my $plugin (@plugins) {
    my $module = __PACKAGE__ . "::Plugins::$plugin";
    $module =~ s!::!/!g;
    require "$module.pm";
}

Это попытается загрузить My::Package::Plugins::One и My::Package::Plugins::Two . @plugins должен, конечно, поступать из некоторого пользовательского ввода или конфигурационного файла, чтобы это имело смысл. Обратите внимание на оператор подстановки s!::!/!g который заменяет каждую пару двоеточий косой чертой. Это связано с тем, что вы можете загружать модули с использованием синтаксиса знакомого имени модуля из use только если имя модуля является делом. Если вы передаете строку или переменную, она должна содержать имя файла.

Использование модуля

use Cwd;

Это будет импортировать модуль Cwd во время компиляции и импортировать его символы по умолчанию, то есть сделать некоторые из переменных и функций модуля доступными для кода, используя его. (См. Также: perldoc -f use .)

Как правило, это будет правильно. Иногда, однако, вам нужно будет контролировать, какие символы импортированы. Добавьте список символов после имени модуля для экспорта:

use Cwd 'abs_path';

Если вы это сделаете, будут импортированы только указанные вами символы (т. Е. Набор по умолчанию не будет импортирован).

При импорте нескольких символов идиоматично использовать конструкцию построения qw() :

use Cwd qw(abs_path realpath);

Некоторые модули экспортируют подмножество своих символов, но можно сказать, что они экспортируют все с помощью :all :

use Benchmark ':all';

(Обратите внимание, что не все модули распознают или используют тег :all ).

Использование модуля внутри каталога

use lib 'includes';
use MySuperCoolModule;

use lib 'includes'; добавляет относительный каталог, includes/ как другой путь поиска модуля в @INC . Предположим, что у вас есть файл модуля MySyperCoolModule.pm внутри includes/ , который содержит:

package MySuperCoolModule;

Если вы хотите, вы можете сгруппировать столько модулей из своего собственного внутри одного каталога и сделать их доступными с помощью одного оператора use lib .

На этом этапе использование подпрограмм в модуле потребует префикса имени подпрограммы с именем пакета:

MySuperCoolModule::SuperCoolSub_1("Super Cool String");

Чтобы иметь возможность использовать подпрограммы без префикса, вам нужно экспортировать имена подпрограмм, чтобы они были распознаны программой, вызывающей их. Экспортирование может быть настроено так, чтобы быть автоматическим, таким образом:

package MySuperCoolModule;
use base 'Exporter';
our @EXPORT = ('SuperCoolSub_1', 'SuperCoolSub_2');

Затем в файле, который use этот модуль, эти подпрограммы будут автоматически доступны:

use MySuperCoolModule;
SuperCoolSub_1("Super Cool String");

Или вы можете настроить модуль для условного экспорта подпрограмм, таким образом:

package MySuperCoolModule;
use base 'Exporter';
our @EXPORT_OK = ('SuperCoolSub_1', 'SuperCoolSub_2');

В этом случае вам нужно явно запросить нужные подпрограммы для экспорта в скрипт, который use модуль:

use MySuperCoolModule 'SuperCoolSub_1';
SuperCoolSub_1("Super Cool String");

CPAN.pm

CPAN.pm - это модуль Perl, который позволяет запрашивать и устанавливать модули с сайтов CPAN.

Он поддерживает интерактивный режим, вызываемый с помощью

cpan

или же

perl -MCPAN -e shell

Запросы модулей

По имени:

cpan> m MooseX::YAML

Режимом по имени модуля:

cpan> m /^XML::/

Примечание: для включения пейджера или перенаправления на файл используйте | или > перенаправление оболочки (пробелы являются обязательными в пределах | и > ), например: m /^XML::/ | less .

По распределению:

cpan> d LMC/Net-Squid-Auth-Engine-0.04.tar.gz

Установка модулей

По имени:

cpan> install MooseX::YAML

По распределению:

cpan> install LMC/Net-Squid-Auth-Engine-0.04.tar.gz

Список всех установленных модулей

Из командной строки:

cpan -l

Из сценария Perl:

use ExtUtils::Installed;
my $inst = ExtUtils::Installed->new();
my @modules = $inst->modules();


Modified text is an extract of the original Stack Overflow Documentation
Лицензировано согласно CC BY-SA 3.0
Не связан с Stack Overflow