Beim Programmieren werden Sie schnell feststellen, dass Sie bestimmte Routine-Aufgaben immer wieder ben�tigen. Immer wieder m�ssen Dateien eingelesen werden, in einer CGI-Umgebung m�ssen immer wieder Formulare verarbeitet werden, zur Kommunikation mit fernen Rechnern im Internet muss immer wieder eine Internet-Socket-Verbindung aufgebaut werden usw. Nun bietet der Perl-Interpreter ja bereits eine Menge 
Funktionen an, die solche Routine-Aufgaben bew�ltigen. Doch je mehr solcher Funktionen im Perl-Interpreter fest eingebaut sind, desto gr��er, langsamer und ressourcen-unfreundlicher wird der Interpreter. Daher gibt es einen zweiten Typ Funktionen, n�mlich solche, die nicht direkt in den Perl-Interpreter eingebaut sind, sondern in Form von Perl-Scripts zur Verf�gung stehen. Diese speziellen Perl-Scripts werden Module genannt. Module stellen Funktionen (aber auch Variablen) f�r bestimmte Routine-Aufgaben zur Verf�gung. Um in Ihren eigenen Perl-Scripts solche Funktionen verwenden zu k�nnen, binden Sie einfach die Module ein, in denen die gew�nschten Funktionen stehen. Anschlie�end k�nnen Sie auf die Funktionen und Variablen der Module zugreifen.
Mittlerweile gibt es tausende von Perl-Modulen, die frei verf�gbar sind. Es gibt praktisch kaum mehr ein Programmiergebiet, f�r das es nicht schon Module mit fertigen leistungsstarken Funktionen gibt. Die Module werden der Allgemeinheit von eifrigen und f�higen Perl-Programmierern im Internet zur Verf�gung gestellt. Einige dieser Module konkurrieren miteinander, und im Laufe der Zeit stellt sich heraus, dass eines der Module in der Praxis am tauglichsten ist. Nat�rlich gibt es auch Module, die h�ufiger zum Einsatz kommen als andere. Letzteres hat dazu gef�hrt, dass mittlerweile zwischen zwei wichtigen Klassen von �ffentlich verf�gbaren Modulen unterschieden wird: es gibt Standardmodule und CPAN-Module. Standardmodule sind solche, die zusammen mit dem Perl-Interpreter ausgeliefert werden, und CPAN-Module stehen im Internet zum Download zur Verf�gung. Standardmodule erhalten dadurch nat�rlich einen wesentlich h�heren Verbreitungsgrad. Da sie bei jeder typischen Installation des Perl-Interpreters mit installiert werden, k�nnen sie auch fast so bedenkenlos verwendet werden wie die fest eingebauten Funktionen von Perl. Denn auch wenn ein Perl-Script auf einen anderen Rechner portiert wird und dort seine Arbeit verrichten soll, stehen die gleichen Module zur Verf�gung - vorausgesetzt, eine entsprechend aktuelle Version des Perl-Interpreters ist installiert. Wenn Sie dagegen CPAN-Module downloaden und in Ihre eigenen Scripts einbinden, ist die Portierung eines Scripts auf einen anderen Rechner nicht ganz so unproblematisch. Denn das Script funktioniert dort erst, nachdem die gleichen CPAN-Module installiert sind.
Innerhalb dieses Kapitels finden Sie einen Abschnitt �ber die 
Standardmodule von Perl und einen Abschnitt �ber CPAN-Module. Dort erhalten Sie eine �bersicht, welche Module zur Verf�gung stehen.
Daneben ist es selbstverst�ndlich auch m�glich, eigene Module zu schreiben. F�r gr��ere Perl-Scripts ist es auch besser, den Code so zu verteilen, dass es nur noch ein schlankes Hauptscript mit eingebundenen Modulen f�r spezielle Aufgaben gibt. Angenommen, Sie programmieren ein Perl-Script, das eine Datei mit einer bestimmten Datenstruktur verarbeitet. Bei dieser Aufgabe k�nnten Sie ein Modul schreiben, das alle Funktionen zum Einlesen der Datei in geeignete Variablen und zum Zur�ckschreiben verarbeiteter Daten in die Datei enth�lt. Im Hauptscript k�nnen Sie dann einfach dieses Modul einbinden und auf dessen Funktionen und Variablen zugreifen. Sollte sich dann beispielsweise das Dateiformat der Datendatei �ndern, muss nur das Modul umgeschrieben werden, w�hrend das Hauptscript und m�gliche andere Module davon unber�hrt bleiben. Typische Beispiele zum Erstellen projekteigener Module finden Sie im Abschnitt �ber objektorientierte Programmierung. Das ist kein Zufall. Denn modul-orientiertes Arbeiten im modernen Stil und objektorientiertes Programmieren geh�ren bei Perl eng zusammen.
Perl-Module sind also (meistens) selber Perl-Scripts. Es handelt sich jedoch um Scripts, bei denen ein paar Regeln und Besonderheiten zu beachten sind, auf die im folgenden noch n�her eingegangen wird.
Zum Einbinden von Modulen stehen in Perl die Funktionen use und require zur Verf�gung. Im allgemeinen wird heute empfohlen, die Funktion use zu verwenden, weil sie konsequenter den Modul-Gedanken verfolgt. Bei Verwendung von use wird das Modul ganz zu Beginn des Hauptscripts eingebunden. Es steht also zur Verf�gung, bevor �berhaupt die erste Code-Zeile Ihres Scripts ausgef�hrt wird. Bei Verwendung von require wird die andere Datei dagegen erst an der Stelle eingebunden, an der die require-Anweisung steht. Vor dem entsprechenden Aufruf stehen also Funktionen oder Variablen des Moduls noch nicht zur Verf�gung, und falls der require-Aufruf beispielsweise in einem Zweig einer bedingten Anweisung steht, wird er nur dann ausgef�hrt, wenn das Script in den entsprechenden Zweig gelangt. Ein Beispiel soll dies verdeutlichen.
#!/usr/bin/perl -w print "Hier meldet sich das Modul \"Testmodul.pm\"\n"; 1;
#!/usr/bin/perl -w print "Hier meldet sich das Hauptscript\n"; require Testmodul;
#!/usr/bin/perl -w print "Hier meldet sich das Hauptscript\n"; use Testmodul;
Der erste Teil des Beispiels zeigt den Code der Datei Testmodul.pm. Die Beispielteile 2a und 2b zeigen jeweils ein Perl-Script, in dem diese Moduldatei eingebunden wird. Im Script test_require.pl (2a) wird das Modul mit require eingebunden, im Script test_use.pl (2b) dagegen mit use. Beide Scripts (2a und 2b) sind identisch bis auf den unterschiedlichen Funktionsaufruf. Das Ergebnis der Ausgabe ist jedoch verschieden. In 2a (also beim Einbinden des Moduls mit require lautet es:
Hier meldet sich das Hauptscript
Hier meldet sich das Modul "Testmodul.pm"
In 2b dagegen (Einbinden des Moduls mit use) lautet die Ausgabe dagegen:
Hier meldet sich das Modul "Testmodul.pm"
Hier meldet sich das Hauptscript
Der Grund ist, dass ein mit use eingebundenes Modul ausgef�hrt wird, bevor der Code des einbindenden Scripts ausgef�hrt wird. Bei require wird das eingebundene Script dagegen an der Stelle ausgef�hrt, an der es eingebunden wird.
Auf den ersten Blick spricht dieser Unterschied eher f�r die Verwendung von require und weniger f�r den von use. In der Praxis ist es jedoch so, dass Moduldateien meist keinen direkt auszuf�hrenden Code enthalten, sondern aus Funktionen (Subroutinen) bestehen, die dann im einbindenden Script aufgerufen werden k�nnen.
#!/usr/bin/perl -w
sub Modulprint {
print "Hier meldet sich das Modul \"Modul.pm\"\n";
}
1;
#!/usr/bin/perl -w print "Hier meldet sich das Hauptscript\n"; require Testmodul; Modulprint();
#!/usr/bin/perl -w print "Hier meldet sich das Hauptscript\n"; use Testmodul; Modulprint();
In diesem Beispiel-Ensemble erzeugen die Scripts aus 2a und 2b die gleiche Ausgabe, n�mlich:
Hier meldet sich das Hauptscript
Hier meldet sich das Modul "Testmodul.pm"
Der Grund ist, dass der Code des Moduls nun in einer Subroutine namens Modulprint steht. In den einbindenden Scripts test_require.pl und test_use.pl wird mit der Anweisung Modulprint(); die entsprechende Funktion im eingebundenen Modul aufgerufen.
Ein weiterer wichtiger Unterschied zwischen use und require ist, dass Sie bei use genau angeben k�nnen, welche Funktions- und Variablennamen Sie aus einem Modul importieren wollen, w�hrend require diese M�glichkeit nicht anbietet. Mehr dazu weiter unten im Abschnitt Erweiterte Verwendung von use.
Moduldateien k�nnen in einem der Verzeichnisse abgelegt werden, die in der vordefinierten Variablen @INC definiert sind, oder in einem Unterverzeichnis davon. Bei einer typischen Perl-Installation enth�lt die Liste @INC eine Reihe von Unterverzeichnissen des Perl-Installationsverzeichnisses sowie das jeweils aktuelle Verzeichnis, also meistens das Verzeichnis, in dem das die Moduldatei einbindende Hauptscript liegt.
Das Ablegen von Moduldateien im Verzeichnis bzw. einem Unterverzeichnis des Hauptscripts ist dann sinnvoll, wenn die Moduldateien von keinem anderen Script verwendet werden. Wenn die Moduldateien dagegen so allgemein geschriebenen Code enthalten, dass Sie sie f�r verschiedene Scripts verwenden k�nnen, dann ist es besser, Sie legen die Moduldateien in einem der anderen Verzeichnisse ab, die in @INC genannt werden.
Um zu entscheiden, wo Sie Moduldateien ablegen k�nnen, m�ssen Sie also erst einmal die Liste der erlaubten Verzeichnisse kennen. Das folgende einfache Perl-Script hilft dabei.
Anzeigebeispiel: So sieht's aus (Zum Aufruf des Scripts ist eine Internet-Verbindung erforderlich)
#!/usr/bin/perl -w
print "Content-type: text/html\n\n";
print '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">', "\n";
print "<html><head><title>Erlaubte Modulverzeichnisse</title>\n";
print "</head><body>\n";
print "<h1>Verzeichnisse zum Ablegen von Moduldateien:</h1>\n";
foreach (@INC) {
print "<tt>$_</tt><br>\n";
}
print "</body></html>\n";
Das Script gibt einfach den Inhalt der Liste @INC zeilenweise als HTML-Code aus. Wenn Sie den Code als pl-Datei im CGI-Verzeichnis abspeichern und die pl-Datei von einem Browser anfordern lassen, werden die verf�gbaren Verzeichnispfade angezeigt. In der �blichen Konfiguration ist der letzte Eintrag der Liste ein einzelner Punkt (.). Dies steht f�r "aktuelles Verzeichnis" und bewirkt, dass der Perl-Interpreter, nachdem er eine eingebundene Datei in den allgemeinen Verzeichnispfaden nicht gefunden hat, im aktuellen Verzeichnis sucht.
Falls Sie Ihre Moduldatei in keinem der Verzeichnisse ablegen wollen, die von @INC angeboten werden, k�nnen Sie sie auch woanders ablegen. Dann m�ssen Sie allerdings vor dem Einbinden einer solchen Moduldatei die Liste @INC um den Verzeichnispfad erweitern, in dem die Moduldatei liegt.
#!/usr/bin/perl -w
use lib "/httpd/docs/cgi-shared/speziell";
use lib "/httpd/docs/cgi-shared/module";
print "Content-type: text/html\n\n";
print '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">', "\n";
print "<html><head><title>Erlaubte Modulverzeichnisse</title>\n";
print "</head><body>\n";
print "<h1>Verzeichnisse zum Ablegen von Moduldateien:</h1>\n";
foreach (@INC) {
print "<tt>$_</tt><br>\n";
}
print "</body></html>\n";
Durch eine Anweisung vom Typ use lib mit anschlie�ender Angabe eines Verzeichnispfades wird dieser Pfad an den Anfang der Liste @INC �bernommen. Das Beispiel-Script ist das gleiche CGI-Script zur Ausgabe der Pfade von @INC wie zuvor. In diesem Fall zeigt es, dass die so definierten eigenen Pfade mit in die Liste aufgenommen wurden.
Module k�nnen in einem der Verzeichnisse von @INC oder einem Unterverzeichnis davon abgelegt werden. Daraus ergeben sich dann die m�glichen Formen der Adressierung eines Moduls beim Einbinden mit use oder require.
require "Statistik.pm"; require Statistik; use "Statistik.pm"; use Statistik;
Alle vier Beispiele zeigen das Einbinden eines Moduls, das in einer Datei namens Statistik.pm abgelegt ist. Die Datei befindet sich direkt in einem der Verzeichnisse, die in der Liste @INC als m�gliche Speicherorte f�r Module zur Verf�gung stehen. F�r require und use gelten die gleichen Regeln. Entweder notieren Sie den vollst�ndigen Dateinamen der Moduldatei in Anf�hrungszeichen (Moduldateien sollten die Endung .pm haben), oder Sie notieren den Dateinamen ohne die Endung .pm ohne Anf�hrungszeichen.
Wenn sich die Datei in einem Unterverzeichnis eines der Verzeichnisse von @INC befindet, ist die relative Pfadangabe erforderlich.
require "Berechnungsmodule/Statistik.pm"; require Berechnungsmodule::Statistik; use "Berechnungsmodule/Statistik.pm"; use Berechnungsmodule::Statistik;
Wieder zeigen alle vier Beispiele das Einbinden eines Moduls Statistik.pm. Die Datei befindet sich unterhalb eines der @INC-Verzeichnisse in einem Unterverzeichnis namens Berechnungsmodule. In diesem Fall ist allerdings die Syntax ohne Anf�hrungszeichen vorzuziehen. Denn wenn Sie mit Anf�hrungszeichen arbeiten, m�ssen Sie die einzubindende Datei mit "vollem" Namen ansprechen. Die Syntax ohne Anf�hrungszeichen kommt dagegen ohne die Dateiendung .pm aus. Es wird erwartet, dass die eingebundene Moduldatei diese Endung hat. Die Zeichenfolge, die die Verzeichnistrenner symbolisiert, also Hierarchien darstellt, besteht aus einem doppelten Doppelpunkt (::).
So einfach das Konzept der Module in Perl erst einmal klingt - es bringt doch ein paar Probleme mit sich. Angenommen, in Ihrem eigenen Perl-Script definieren Sie eine Subroutine namens get_data(). In dem gleichen Script binden Sie ein Modul ein, in dessen Code ebenfalls eine Subroutine namens get_data() definiert ist. Damit der Perl-Interpreter beim Aufruf von get_data() wei�, welche der beiden Funktionen gemeint ist, muss es eine M�glichkeit geben, ihm mitzuteilen, welche der Funktionen gemeint ist.
Zu diesem Zweck gibt es in Perl das Konzept der Namensr�ume. Jeder Namensraum stellt ein so genanntes Package (engl. f�r Paket) dar. Jedes Perl-Script, in dem Sie keine besondere Angabe machen, welchen Namensraum (welches Package) Sie meinen, benutzt ein Default-Package. Es hat den Namen main.
#!/usr/bin/perl -w $Ausgabetext = "Hallo alte Welt. "; print $Ausgabetext; package NeueWelt; $Ausgabetext = "Hallo neue Welt. "; print $Ausgabetext; package main; print $Ausgabetext;
Das Beispiel verdeutlicht den Default-Namensraum mit dem Namen main. Zun�chst wird ein Skalar namens $Ausgabetext definiert und mit einem Wert belegt. Dieser Wert wird gleich anschlie�end ausgegeben. Da bis zum Ausf�hrungszeitpunkt noch keine weitere Angabe zum Namensraum gemacht wurde, befindet sich das Script im Defaultnamensraum main. Im zweiten Schritt wird mit Hilfe der Funktion package ein neuer eigener Namensraum mit Namen NeueWelt definiert. Unterhalb davon wird wiederum ein Skalar namens $Ausgabetext definiert, diesmal mit anderem Wert. Dieser neue Wert wird wieder ausgegeben.
Zu diesem Ausf�hrungszeitpunkt existieren nun zwei Skalare namens $Ausgabetext - n�mlich der aus dem Package NeueWelt und der aus dem Default-Package main. Zur Kontrolle wird im Beispiel wieder auf das Package main "umgeschaltet". Dazu wird wieder die Funktion package aufgerufen, diesmal aber mit dem Defaultnamen main. Von den beiden existierenden Skalaren dieses Namens wird nun der im Script zuerst definierte ausgegeben, also derjenige, der zum Default-Namensraum main geh�rt. Der unterste print-Aufruf gibt also wieder Hallo alte Welt. aus.
Wie das Beispiel zeigt, l�sst sich der Namensraum innerhalb einer Scriptdatei also beliebig wechseln. Dadurch l�sst sich ein hohes Ma� an Flexibilit�t erreichen. Von dieser Flexibilit�t profitieren die Module in Perl. Ein Modul kann n�mlich durch Anwendung der Package-Technik beispielsweise mehrere (Objekt-)Klassen in einer Moduldatei unterbringen oder andere Module (die ja auch aus Packages bestehen) erweitern, auch wenn die Technik zugegebenerma�en etwas unsauber ist. Ein einfaches Beispiel soll diesen Zusammenhang verdeutlichen.
$Modultext = "Dies ist der Inhalt des Skalars \$Modultext\n"; package Testmodul; $Text = "Dies ist der Inhalt des Skalars \$Text\n"; 1;
#!/usr/bin/perl -w use Testmodul; print $Modultext; print $Testmodul::Text;
Der erste Teil des Beispiels ist das Modulscript, der zweite Teil das Hauptscript. Das Modulscript erh�lt im Beispiel den Namen Testmodul.pm und wird im Hauptscript mit der Anweisung use Testmodul; eingebunden.
Die Moduldatei beginnt mit der Definition eines Skalars namens $Modultext. Da zuvor kein anderes package aufgerufen wird, ist das Package aktiv, in das das Modul eingebunden wird. Alles, was innerhalb dieses Namensraums definiert wird, befindet sich somit im Namensraum main des einbindenden Scripts. Im Beispiel gibt das einbindende Script, also das Hauptscript, mit print $Modultext; in seinem Default-Namensraum main einfach die Variable aus, die im Namensraum main der Moduldatei definiert wurde. $Modultext wurde also direkt im Default-Namensraum des einbindenden Scripts definiert. Damit wurde das Package main durch das Modul erweitert.
Im Modulscript, also in der Modul.pm, wird im weiteren Verlauf jedoch mit package ein neuer Namensraum definiert. Er hat den gleichen Namen wie der Vorname der Moduldatei, n�mlich Testmodul. Im einbindenden Hauptscript kann auf Variablen und Funktionen, die im Modul unterhalb des Packages Testmodul definiert werden, nur durch Angabe des entsprechenden Namensraums zugegriffen werden. Die Anweisung print $Testmodul::Text; zeigt, wie auf das andere Package zugegriffen wird. Dem Namen einer Variablen oder einer Funktion wird der Name des Packages und ein doppelter Doppelpunkt (::) vorangestellt. Skalare, Listen und Hashes beginnen weiterhin mit ihren typischen Kennzeichen $, @ und %. Zwischen dem Kennzeichen und dem Variablennamen steht jedoch der Package-Name und der doppelte Doppelpunkt.
Das Ansprechen von Variablen oder Funktionen in anderen Packages oder Modulen mit Package-Name::Variablen/Funktionsname ist nicht m�glich, wenn die Variablen oder Funktionen mit my deklariert sind. Die Anwendung von my wird deshalb auch in der Praxis empfohlen, um eine saubere Kapselung von Variablen und Funktionen, die nur innerhalb eines Packages oder Moduls von Bedeutung sind, zu erreichen.
Da Module selbst wieder andere Module einbinden k�nnen und einzelne Module aber eigentlich Dateninseln darstellen sollen, st��t die Technik des Erweiterns von Packages irgendwann an ihre Grenzen. Um "�ffentliche" Schnittstellen von Modulen festlegen zu k�nnen, haben Sie die M�glichkeit, einzelne Symbole (also Variablennamen oder Funktionsnamen beispielsweise) in beiden Packages (also dem einbindenden und dem eingebundenen) sichtbar zu machen. Sie k�nnen die Symbole aus dem Modul exportieren bzw. in das einbindende Script oder Modul importieren.
Ein Modul kann deshalb erzwingen, dass Sie beim Einbinden genau angeben m�ssen, welche Variablen oder Funktionen Sie in den Namensraum des einbindenden Scripts importieren m�chten. Dazu gibt es das so genannte Exporter-Modul, ein Standardmodul von Perl. Dieses Modul erwartet im eingebundenen Package zwei Listen namens @EXPORT und @EXPORT_OK. Ein Modul kann das Exporter-Modul einbinden und diese beiden Listen mit denjenigen Variablen- und Funktionsnamen f�llen, die in ein einbindendes Modul �berhaupt exportiert werden k�nnen. Im einbindenden Script wiederum k�nnen Sie angeben, welche der exportierbaren Namen des Moduls Sie in den Namensraum Ihres Scripts importieren m�chten.
package Testmodul; require Exporter; @ISA = qw(Exporter); @EXPORT = qw(%FORMULARFELDER); @EXPORT_OK = qw($Zeitstempel @Logdaten Besteller_ermitteln); # hier folgt der Code des Moduls ... # in dem Code kommen unter anderem vor: # ein Hash namens %FORMULARFELDER # ein Skalar namens $Zeitstempel # eine Liste namens @Logdaten # eine Funktion namens Besteller_ermitteln 1;
#!/usr/bin/perl -w use Testmodul qw($Zeitstempel); # hier folgt der Code des Scripts ...
Die Moduldatei bindet im Beispiel mit require selbst ein Modul ein, n�mlich das Standardmodul Exporter. Die Anweisung @ISA = qw(Exporter) definiert die Klasse Exporter als Basisklasse der aktuellen Klasse, die durch das aktuelle Package (im Beispiel also Testmodul) repr�sentiert wird. Damit wird die Methode import, die im Modul bzw. der Klasse Exporter definiert ist, an die Klasse Testmodul vererbt. Diese etwas kompliziert klingenden Erl�uterungen sind durch den Sprachgebrauch der objektorientierten Programmierung bedingt.
Die Liste @EXPORT kann Namen der Module aufnehmen, die in den Namensraum eines einbindenden Scripts standardm��ig exportiert werden, wenn bei der Einbindung keine spezielle Importliste angegeben ist. Die Liste @EXPORT_OK nimmt dagegen die Namen auf, die ein einbindendes Script maximal in den eigenen Namensraum �bernehmen kann, aber nicht �bernehmen muss.
Im obigen Beispiel ist in der Moduldatei bei der @EXPORT-Liste nur ein Name notiert, n�mlich ein Hash namens %FORMULARFELDER. Diese Variable wird in den Namensraum eines einbindenden Scripts exportiert, wenn bei der use-Anweisung keine Importliste angegeben wird. Bei der Liste @EXPORT_OK sind im Beispiel drei Namen notiert: ein Skalar namens $Zeitstempel, eine Liste namens @Logdaten und eine Subroutine namens Besteller_ermitteln.
Zur Notation der Listen bietet sich besonders der Operator qw an, da er es erm�glicht, die Variablennamen ohne st�ndige Anf�hrungszeichen notieren zu k�nnen. qw($Zeitstempel @Logdaten Besteller_ermitteln) entspricht eigentlich der Notation ('$Zeitstempel', '@Logdaten', 'Besteller_ermitteln'), ist aber �bersichtlicher.
Innerhalb der Klammern von qw werden die gew�nschten Namen notiert und durch Leerraumzeichen getrennt. Variablennamen erhalten dabei die �blichen Kennzeichen f�r Skalare, Listen und Hashes.
Das einbindende Script bindet das Modul im Beispiel mit use Testmodul ein und muss in der nachfolgenden Liste angeben, welche der bei @EXPORT oder EXPORT_OK genannten Namen es in den eigenen Namensraum importieren m�chte. Im Beispiel wird nur der Skalar $Zeitstempel angegeben und als einziger Name importiert. Wenn Sie die Listenangabe weglassen (im Beispiel also nur use Testmodul; notieren w�rden), werden die in @EXPORT aufgef�hrten Namen importiert.
Module, die Sie nicht selbst geschrieben haben, aber in Ihre Scripts einbinden m�chten, m�ssen Sie nat�rlich so weit verstehen, dass Sie in der Lage sind, die darin enthaltenen Funktionen richtig aufzurufen, darin definierte Variablen zu kennen und zu benutzen usw. Deshalb sind zumindest alle wichtigen Standardmodule und Module aus dem CPAN-Verzeichnis dokumentiert. Da separate readme-Dateien aber leicht verloren gehen, stellt Perl die M�glichkeit bereit, die Dokumentation innerhalb der Datei mit dem Quellcode zu notieren. Zum Lieferumfang von Perl geh�rt das Programm perldoc, mit dem Sie den Dokumentationsteil am Bildschirm ausgeben k�nnen.
Das folgende Beispiel zeigt den vollst�ndigen Code eines kleinen Standardmoduls von Perl. Die Aufgabe des Moduls soll hier nicht weiter interessieren. Gezeigt werden soll, wie die Dokumentation in den Quellcode integriert ist.
package CPAN::Nox;
use strict;
use vars qw($VERSION @EXPORT);
BEGIN{
$CPAN::Suppress_readline=1 unless defined $CPAN::term;
}
use base 'Exporter';
use CPAN;
$VERSION = "1.03";
$CPAN::META->has_inst('Digest::MD5','no');
$CPAN::META->has_inst('LWP','no');
$CPAN::META->has_inst('Compress::Zlib','no');
@EXPORT = @CPAN::EXPORT;
*AUTOLOAD = \&CPAN::AUTOLOAD;
1;
__END__
=head1 NAME
CPAN::Nox - Wrapper around CPAN.pm without using any XS module
=head1 SYNOPSIS
Interactive mode:
perl -MCPAN::Nox -e shell;
=head1 DESCRIPTION
This package has the same functionality as CPAN.pm, but tries to
prevent the usage of compiled extensions during its own
execution. Its primary purpose is a rescue in case you upgraded perl
and broke binary compatibility somehow.
=head1 SEE ALSO
CPAN(3)
=cut
Das Beispiel zeigt den Code des CPAN-Moduls Nox.pm. Der obere Teil der Moduldatei enth�lt den eigentlich ausf�hrbaren Code des Moduls, und der untere Teil enth�lt die Dokumentation zum Modul. Die Dokumentation beginnt mit Anweisungen, die in einer neuen Zeile beginnen und als erstes Zeichen ein Gleichheitszeichen (=) haben. Mit =head1 NAME wird beispielsweise eine �berschrift mit dem Titel NAME erzeugt. Alles, was danach kommt, wird bis zur beendenden Anweisung =cut als Dokumentation interpretiert.
Um die Dokumentation separat lesen zu k�nnen, m�ssen Sie auf der Kommandozeile Ihres Betriebssystems eingeben:
perldoc [Pfad]Modulname
Unter Windows k�nnen Sie die DOS-Eingabeaufforderung benutzen oder ein Programm, das in der Lage ist, Standard-Out-Ergebnisse eines Programms aufzufangen (manche besseren Texteditoren k�nnen das beispielsweise). Auf Unix-Systemen benutzen Sie einfach eine geeignete Shell. Wenn Sie den Pfad zu einer Moduldatei mit angeben, k�nnen Sie die Verzeichnisse mit einem Schr�gstrich (/) trennen. Oder Sie wechseln in das Verzeichnis der Moduldatei. Dann k�nnen Sie die Pfadangabe weglassen.
Im obigen Beispiel der Moduldatei Nox.pm sind Aufrufe m�glich wie:
perldoc CPAN::Nox
perldoc Nox.pm
perldoc Nox
perldoc -m Nox (listet den Quellcode mit auf)
|
| |
 |
Standardmodule von Perl
|
 |
Funktionen f�r Module und Packages
|
 SELFHTML/Navigationshilfen Perl Perl-Module |
|
© 2007 Impressum