Ricerca…


Sintassi

  • richiede Module :: Name; # Richiede per nome da @INC
  • richiede "percorso / su / file.pm"; # Richiede per percorso relativo da @INC
  • usa Module :: Name; # require e default import su BEGIN
  • usa Module :: Name (); # require e no import in BEGIN
  • usa Module :: Name (@ARGS); # richiede e importa con argomenti in BEGIN
  • usa Module :: Name VERSION; # richiedono, controllo versione e importazione predefinita in BEGIN
  • usa Module :: Name VERSION (); # richiedono, controllo versione e nessuna importazione in BEGIN
  • usa Module :: Name VERSION (@ARGS); # require, check versione, import con args in BEGIN
  • fai "path / to / file.pl"; # carica ed eval il file specificato

Esecuzione del contenuto di un altro file

do './config.pl';

Questo leggerà il contenuto del file config.pl e lo eseguirà. (Vedi anche: perldoc -f do .)

NB: Evitare di do meno di giocare a golf o qualcosa di simile in quanto non vi è alcun controllo degli errori. Per includere i moduli di libreria, utilizzare require o use .

Caricamento di un modulo in fase di runtime

require Exporter;

Ciò assicurerà che il modulo Exporter sia caricato in fase di runtime se non è già stato importato. (Vedi anche: perldoc -f require .)

NB: la maggior parte degli utenti dovrebbe use moduli anziché require . Diversamente use , require non chiama il metodo di importazione del modulo e viene eseguito in fase di runtime, non durante la compilazione.

Questo metodo di caricamento dei moduli è utile se non è possibile decidere quali moduli sono necessari prima del runtime, ad esempio con un sistema di plugin:

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

Questo proverebbe a caricare My::Package::Plugins::One e My::Package::Plugins::Two . @plugins , @plugins dovrebbe provenire da qualche input dell'utente o da un file di configurazione per avere un senso. Notare l'operatore di sostituzione s!::!/!g che sostituisce ogni coppia di due punti con una barra. Questo perché è possibile caricare i moduli utilizzando la sintassi del nome del modulo familiare da use solo se il nome del modulo è un bareword. Se passi una stringa o una variabile, deve contenere un nome di file.

Utilizzando un modulo

use Cwd;

Questo importerà il modulo Cwd in fase di compilazione e importerà i suoi simboli predefiniti, cioè renderà alcune delle variabili e funzioni del modulo disponibili per il codice che lo utilizza. (Vedi anche: perldoc -f use .)

Generalmente questo farà la cosa giusta. A volte, tuttavia, si desidera controllare quali simboli vengono importati. Aggiungi un elenco di simboli dopo il nome del modulo da esportare:

use Cwd 'abs_path';

Se si esegue questa operazione, verranno importati solo i simboli specificati (ad esempio, il set predefinito non verrà importato).

Quando si importano più simboli, è idiomatico usare il costrutto list-building qw() :

use Cwd qw(abs_path realpath);

Alcuni moduli esportano un sottoinsieme dei loro simboli, ma si può dire di esportare tutto con :all :

use Benchmark ':all';

(Nota che non tutti i moduli riconoscono o usano il tag :all ).

Usare un modulo in una directory

use lib 'includes';
use MySuperCoolModule;

use lib 'includes'; aggiunge la directory relativa includes/ come un altro percorso di ricerca del modulo in @INC . Supponiamo quindi di avere un file di modulo MySyperCoolModule.pm all'interno includes/ , che contiene:

package MySuperCoolModule;

Se lo desideri, puoi raggruppare tutti i tuoi moduli all'interno di una singola directory e renderli reperibili con una sola istruzione use lib .

A questo punto, l'uso delle subroutine nel modulo richiederà il prefisso del nome della subroutine con il nome del pacchetto:

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

Per poter utilizzare le subroutine senza il prefisso, è necessario esportare i nomi delle subroutine in modo che vengano riconosciuti dal programma che li chiama. L'esportazione può essere impostata per essere automatica, quindi:

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

Quindi nel file che use s il modulo, quelle subroutine saranno automaticamente disponibili:

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

Oppure puoi impostare il modulo per esportare in modo condizionale le subroutine, quindi:

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

In tal caso, è necessario richiedere esplicitamente le subroutine desiderate da esportare nello script che use il modulo:

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

CPAN.pm

CPAN.pm è un modulo Perl che consente di interrogare e installare moduli da siti CPAN.

Supporta la modalità interattiva invocata con

cpan

o

perl -MCPAN -e shell

Moduli di interrogazione

Per nome:

cpan> m MooseX::YAML

Da una regex contro il nome del modulo:

cpan> m /^XML::/

Nota: per abilitare un cercapersone o il reindirizzamento a un file, utilizzare | o > reindirizzamento della shell (gli spazi sono obbligatori attorno a | e > ), ad esempio: m /^XML::/ | less .

Dalla distribuzione:

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

Installazione dei moduli

Per nome:

cpan> install MooseX::YAML

Dalla distribuzione:

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

Elenca tutti i moduli installati

Dalla riga di comando:

cpan -l

Da uno script Perl:

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


Modified text is an extract of the original Stack Overflow Documentation
Autorizzato sotto CC BY-SA 3.0
Non affiliato con Stack Overflow