Szukaj…


Składnia

  • wymagają modułu :: Nazwa; # Wymagaj według nazwy z @INC
  • wymagają „path / to / file.pm”; # Wymagaj według ścieżki względnej z @INC
  • użyj modułu :: Nazwa; # wymagaj domyślnego importu na BEGIN
  • użyj Module :: Name (); # wymaga i nie wymaga importu w BEGIN
  • użyj Module :: Name (@ARGS); # wymagaj i importuj z argumentami na BEGIN
  • użyj modułu :: Nazwa WERSJA; # wymagają, sprawdź wersję i domyślny import na BEGIN
  • użyj Module :: Name VERSION (); # wymagają, sprawdź wersję i nie importuj na BEGIN
  • użyj Module :: Name VERSION (@ARGS); # wymagają, sprawdź wersję, importuj z argumentami na BEGIN
  • do „path / to / file.pl”; # załaduj i ewaluuj podany plik

Wykonywanie zawartości innego pliku

do './config.pl';

Przeczyta to zawartość pliku config.pl i uruchomi go. (Zobacz też: perldoc -f do .)

Uwaga: Unikaj do chyba że grasz w golfa lub coś takiego, ponieważ nie ma sprawdzania błędów. Aby dołączyć moduły biblioteczne, użyj require lub use .

Ładowanie modułu w czasie wykonywania

require Exporter;

Zapewni to załadowanie modułu Exporter w czasie wykonywania, jeśli nie został jeszcze zaimportowany. (Zobacz też: perldoc -f require .)

Uwaga: większość użytkowników powinna raczej use modułów niż ich require . W odróżnieniu od use , require nie wywołuje metody importu modułu i jest wykonywane w czasie wykonywania, a nie podczas kompilacji.

Ten sposób ładowania modułów jest przydatny, jeśli nie możesz zdecydować, które moduły potrzebujesz przed uruchomieniem, na przykład w systemie wtyczek:

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

Spowoduje to próbę załadowania My::Package::Plugins::One i My::Package::Plugins::Two . @plugins powinno oczywiście pochodzić z danych wejściowych użytkownika lub pliku konfiguracyjnego, aby miało to sens. Zwróć uwagę na operator podstawienia s!::!/!g który zastępuje każdą parę dwukropków ukośnikiem. Wynika to z faktu, że moduły można ładować przy użyciu znanej składni nazwy modułu z use tylko wtedy, gdy nazwa modułu jest gołym słowem. Jeśli przekażesz ciąg znaków lub zmienną, musi ona zawierać nazwę pliku.

Korzystanie z modułu

use Cwd;

Spowoduje to zaimportowanie modułu Cwd w czasie kompilacji i zaimportowanie jego domyślnych symboli, tj. Udostępnienie niektórych zmiennych i funkcji modułu kodowi, który go używa. (Zobacz też: perldoc -f use .)

Ogólnie rzecz biorąc, zrobi to dobrze. Czasami jednak będziesz chciał kontrolować, które symbole są importowane. Dodaj listę symboli po nazwie modułu, aby wyeksportować:

use Cwd 'abs_path';

Jeśli to zrobisz, tylko określone przez Ciebie symbole zostaną zaimportowane (tzn. Domyślny zestaw nie zostanie zaimportowany).

Podczas importowania wielu symboli idiomatyczne jest używanie konstrukcji budującej listy qw() :

use Cwd qw(abs_path realpath);

Niektóre moduły eksportują podzbiór ich symboli, ale można powiedzieć, że eksportuje wszystko za pomocą :all :

use Benchmark ':all';

(Uwaga: nie wszystkie moduły rozpoznają lub używają znacznika :all ).

Korzystanie z modułu w katalogu

use lib 'includes';
use MySuperCoolModule;

use lib 'includes'; dodaje katalog względny includes/ jako kolejną ścieżkę wyszukiwania modułów w @INC . Załóżmy, że masz plik modułu MySyperCoolModule.pm wewnątrz includes/ , który zawiera:

package MySuperCoolModule;

Jeśli chcesz, możesz zgrupować dowolną liczbę własnych modułów w jednym katalogu i uczynić je możliwymi do znalezienia za pomocą jednej instrukcji use lib .

W tym momencie użycie podprogramów w module będzie wymagało poprzedzenia nazwy podprogramu nazwą pakietu:

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

Aby móc korzystać z podprogramów bez prefiksu, musisz wyeksportować nazwy podprogramów, aby zostały rozpoznane przez program je wywołujący. Eksport można ustawić na automatyczny, a zatem:

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

Następnie w pliku use modułu te podprogramy będą automatycznie dostępne:

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

Lub możesz skonfigurować moduł do warunkowego eksportu podprogramów, a zatem:

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

W takim przypadku musisz jawnie poprosić o wyeksportowanie żądanych podprogramów w skrypcie use modułu:

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

CPAN.pm

CPAN.pm to moduł Perla, który pozwala wyszukiwać i instalować moduły z witryn CPAN.

Obsługuje wywoływany tryb interaktywny

cpan

lub

perl -MCPAN -e shell

Moduły zapytań

Wg nazwy:

cpan> m MooseX::YAML

Przez wyrażenie regularne względem nazwy modułu:

cpan> m /^XML::/

Uwaga: aby włączyć pager lub przekierowanie do pliku użyj | lub > przekierowanie powłoki (spacje są obowiązkowe wokół | i > ), np .: m /^XML::/ | less

Według dystrybucji:

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

Instalowanie modułów

Wg nazwy:

cpan> install MooseX::YAML

Według dystrybucji:

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

Wyświetl wszystkie zainstalowane moduły

Z linii poleceń:

cpan -l

Ze skryptu Perla:

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


Modified text is an extract of the original Stack Overflow Documentation
Licencjonowany na podstawie CC BY-SA 3.0
Nie związany z Stack Overflow