Perl Language
Pakete und Module

Syntax

• erfordern Modul :: Name; # Nach Name von @INC erforderlich
• erfordern "Pfad / zu / Datei.pm"; # Erfordert relativen Pfad von @INC
• use Module :: Name; # erfordern und Standardimport bei BEGIN
• Verwenden Sie Module :: Name (); # erfordern und kein Import bei BEGIN
• use Module :: Name (@ARGS); # erfordern und importieren mit args bei BEGIN
• use Module :: Name VERSION; # required, Versionsprüfung und Standardimport bei BEGIN
• use Module :: Name VERSION (); # required, Versionsprüfung und kein Import bei BEGIN
• use Module :: Name VERSION (@ARGS); # erfordern, Versionsprüfung, Import mit args bei BEGIN
• mach "Pfad / zu / Datei.pl"; # die angegebene Datei laden und auswerten

Den Inhalt einer anderen Datei ausführen

do './config.pl';

Dadurch wird der Inhalt der Datei config.pl eingelesen und ausgeführt. (Siehe auch: perldoc -f do .)

Hinweis: Vermeiden do Golfspielen oder ähnliches, da keine Fehlerprüfung erfolgt. Verwenden Sie zum Einschließen von Bibliotheksmodulen die require oder die use .

Laden eines Moduls zur Laufzeit

require Exporter;

Dadurch wird sichergestellt, dass das Exporter Modul zur Laufzeit geladen wird, wenn es noch nicht importiert wurde. (Siehe auch: perldoc -f require .)

NB: Die meisten Benutzer sollten use Module anstatt require sie. Im Gegensatz zu use , require Sie die Importmethode des Moduls nicht anrufen und wird zur Laufzeit, nicht während der Kompilierung ausgeführt.

Diese Art des Ladens von Modulen ist nützlich, wenn Sie nicht vor der Laufzeit entscheiden können, welche Module Sie benötigen, z. B. mit einem Plug-In-System:

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

Dies würde versuchen, My::Package::Plugins::One und My::Package::Plugins::Two zu laden. @plugins sollten natürlich von einer Benutzereingabe oder einer Konfigurationsdatei stammen, um dies sinnvoll zu machen. Beachten Sie den Substitutionsoperator s!::!/!g , der jedes Doppelpunkt durch einen Schrägstrich ersetzt. Dies liegt daran , dass Sie Module laden können die bekannten Modulname Syntax verwenden , use nur , wenn der Modulname ein Bareword ist. Wenn Sie einen String oder eine Variable übergeben, muss dieser einen Dateinamen enthalten.

Verwendung eines Moduls

use Cwd;

Dadurch wird das Cwd Modul zur Kompilierzeit importiert und seine Standardsymbole werden importiert. Das Cwd , dass einige der Variablen und Funktionen des Moduls für den Code verfügbar sind. (Siehe auch: perldoc -f use .)

Im Allgemeinen wird dies das Richtige tun. Manchmal möchten Sie jedoch steuern, welche Symbole importiert werden. Fügen Sie nach dem Modulnamen eine Liste mit Symbolen hinzu, die exportiert werden sollen:

use Cwd 'abs_path';

Wenn Sie dies tun, werden nur die von Ihnen angegebenen Symbole importiert (dh der Standardsatz wird nicht importiert).

Wenn Sie mehrere Symbole importieren, ist es idiomatisch, das qw() -Listenerstellungskonstrukt zu verwenden:

use Cwd qw(abs_path realpath);

Einige Module exportieren eine Teilmenge ihrer Symbole, aber es kann gesagt werden, dass alles mit folgenden Elementen exportiert wird :all :

use Benchmark ':all';

(Beachten Sie, dass nicht alle Module das :all Tag erkennen oder verwenden).

Verwenden eines Moduls in einem Verzeichnis

use lib 'includes';
use MySuperCoolModule;

use lib 'includes'; fügt das relative Verzeichnis @INC includes/ als weiteren @INC in @INC . MySyperCoolModule.pm Sie also an, Sie haben eine Moduldatei MySyperCoolModule.pm in MySyperCoolModule.pm includes/ , die MySyperCoolModule.pm enthält:

package MySuperCoolModule;

Wenn Sie möchten, können Sie beliebig viele eigene Module in einem einzigen Verzeichnis gruppieren und mit einer use lib Anweisung auffindbar machen.

An dieser Stelle müssen Sie für die Verwendung der Subroutinen im Modul dem Namen der Subroutine den Paketnamen voranstellen:

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

Um die Unterprogramme ohne das Präfix verwenden zu können, müssen Sie die Namen der Unterprogramme exportieren, damit sie vom aufrufenden Programm erkannt werden. Der Export kann als automatisch eingerichtet werden, also:

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

In der Datei, use das Modul verwendet, sind diese Unterprogramme automatisch verfügbar:

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

Oder Sie können das Modul so einrichten, dass Unterprogramme bedingt exportiert werden.

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

In diesem Fall müssen Sie die gewünschten Subroutinen im Skript explizit anfordern exportiert werden, use das Modul s:

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

CPAN.pm

CPAN.pm ist ein Perl-Modul, mit dem Module von CPAN-Standorten abgefragt und installiert werden können.

Es unterstützt den interaktiven Modus, der mit aufgerufen wird

cpan

oder

perl -MCPAN -e shell

Module abfragen

Namentlich:

cpan> m MooseX::YAML

Durch Regex gegen Modulnamen:

cpan> m /^XML::/

Hinweis: Um einen Pager zu aktivieren oder auf eine Datei umzuleiten, verwenden Sie | oder > Shell-Umleitung (Leerzeichen sind um das | und > obligatorisch), zB: m /^XML::/ | less

Durch Verteilung:

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

Module installieren

Namentlich:

cpan> install MooseX::YAML

Durch Verteilung:

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

Alle installierten Module auflisten

Von der Kommandozeile:

cpan -l

Aus einem Perl-Skript:

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