|
|
 |
 |
 |
 |
 |
1 Einleitung
Dies ist die 3. Auflage eines Buches, das seit 1993 über eine halbe Million Leser fand. Wir hoffen zumindest, es hat ihnen gefallen. Uns hat es jedenfalls Spaß gemacht, dieses Buch zu schreiben.1
Fragen und Antworten
Wahrscheinlich haben Sie einige Fragen zu Perl, besonders, wenn Sie schon ein wenig herumgeblättert haben, um zu sehen, was dieses Buch so alles bietet. Wir werden daher dieses Kapitel dazu benutzen, Ihre Fragen zu beantworten.
Ist dies das richtige Buch für Sie?
Wenn Sie und wir uns auch nur ein wenig ähnlich sind, dann stehen Sie vermutlich jetzt in einem Buchladen2 und fragen sich, ob Sie dieses Lama-Buch kaufen sollen oder das Buch da drüben, um eine Sprache zu lernen, die nach einer Schlange3 benannt ist, nach einem Getränk oder einem Buchstaben des Alphabets. Sie haben genau zwei Minuten Zeit, bevor der Verkäufer herüberkommt, um Ihnen zu sagen, daß hier keine Bibliothek sei,4 und Sie auffordert, entweder etwas zu kaufen oder den Laden zu verlassen. Vielleicht wollen Sie die zwei Minuten nutzen, um ein kurzes Perl-Programm zu sehen, anhand dessen Sie erkennen können, was Perl so alles kann. In diesem Fall sollten Sie die Perl-Blitztour weiter hinten in diesem Kapitel mitmachen.
Warum gibt es so viele Fußnoten?
Danke, daß Sie das bemerkt haben. Es gibt eine Menge Fußnoten in diesem Buch. Ignorieren Sie sie. Die Fußnoten werden gebraucht, weil Perl eine ganze Reihe von Ausnahmen zu seinen Regeln hat.
Das hat zur Folge, daß wir nicht ohne zu lügen sagen können: »Der fitzbin-Operator frobniziert die husistatische Variable.«, ohne die Ausnahmen5 in einer Fußnote zu erläutern. Da wir ziemlich ehrliche Leute sind, müssen wir also eine Menge Fußnoten schreiben. Sie können dagegen ehrlich sein, ohne die Fußnoten lesen zu müssen (faszinierend, wie das überhaupt funktioniert).
Viele der Ausnahmen haben mit der Portierbarkeit des Codes zu tun. Die Geschichte von Perl begann auf Unix-Systemen und ist dort auch heute noch ziemlich tief verwurzelt. Wo immer es möglich war, haben wir versucht, auf unerwartetes Verhalten hinzuweisen, egal ob das daher rührt, daß ein Programm auf einem Nicht-Unix-System laufen soll, oder auf einem anderen Grund beruht. Wir hoffen, daß dieses Buch auch für unsere Leser, die nichts über Unix wissen, eine gute Einführung in Perl darstellt. (Und daß Sie nebenbei noch etwas über Unix lernen - ohne draufzuzahlen, versteht sich.)
Außerdem folgen die meisten Ausnahmen der alten »80/20«-Regel, die besagt, daß 80% des Verhaltens von Perl in 20% der Dokumentation beschrieben werden kann. Die übrigen 20% des Verhaltens nehmen dafür die verbleibenden 80% der Dokumentation ein. Um dieses Buch also übersichtlich zu halten, besprechen wir im Haupttext die gängigsten und leicht zu benutzenden Anwendungsformen. In den Fußnoten (die außerdem eine kleinere Schrift verwenden, so daß wir bei gleichem Platzverbrauch mehr sagen können)6 gehen wir dann auf die anderen Dinge ein.
Wenn Sie das Buch zum ersten Mal durchgelesen haben, ohne dabei die Fußnoten mitzulesen, werden Sie sich vermutlich einige Abschnitte zur Vertiefung noch einmal ansehen wollen. Wenn Sie an diesem Punkt angekommen sind oder die Neugier beim Lesen einfach zu groß wird, können Sie die Fußnoten lesen. Ein Großteil sind sowieso nur Computerwitze.
Was ist mit den Übungen und ihren Antworten?
Die Übungen finden Sie jeweils am Ende jedes Kapitels. Sie basieren auf den Erfahrungen, die wir mit diesem Kursmaterial bereits vor Tausenden von Kursteilnehmern7 gemacht haben. Wir haben diese Übungen sorgfältig zusammengestellt, um Ihnen die Gelegenheit zu geben, auch einmal Fehler zu machen.
Nicht, daß wir wollen, daß Sie Fehler machen, aber Sie brauchen die Chance dazu. Die meisten dieser Fehler werden Ihnen während Ihrer Perl-Karriere begegnen, warum also nicht gleich jetzt? Jeden Fehler, den Sie beim Lesen dieses Buches begehen, machen Sie nicht noch einmal, wenn Sie unter Zeitdruck ein Programm schreiben müssen. Außerdem sind wir, falls einmal etwas schiefgehen sollte, die ganze Zeit bei Ihnen, und zwar in der Form von Anhang A, Lösungen zu den Übungen.
Versuchen Sie beim Lösen der Übungen nicht zu schummeln, bevor Sie nicht zumindest den ehrlichen Versuch unternommen haben, selbst auf die Lösung zu kommen. Ihr Lernerfolg wird besser sein, wenn Sie die Lösung von sich aus finden, anstatt sie einfach nachzulesen.
Selbst, wenn Sie überhaupt keine Fehler machen, sollten Sie sich die Antworten ansehen, wenn Sie mit der Übung fertig sind. Der Begleittext zeigt einige Details der Übungsprogramme auf, die auf den ersten Blick vielleicht nicht ganz so offensichtlich sind.
Was bedeuten die Zahlen am Anfang einer Übung?
Jeder Übung ist vor dem Text eine Zahl in eckigen Klammern vorangestellt, wie hier:
Diese Zahl ist unsere (sehr grobe) Schätzung, wie viele Minuten Sie in etwa für das Absolvieren einer Übung brauchen werden. Seien Sie bitte nicht überrascht, wenn Sie (inklusive des Schreibens, Testens und Debuggens) nur die halbe Zeit benötigen oder auch nach mehr als der doppelten Zeit noch nicht fertig sind. Wenn Sie allerdings wirklich nicht weiterkommen, werden wir natürlich nicht weitersagen, daß Sie in Anhang A nachgesehen haben, wie die Antwort lautet.
Wie soll ich als Perl-Dozent vorgehen?
Wenn Sie Perl-Kurse leiten und sich entschieden haben, dieses Buch im Kurs einzusetzen (wie es bereits schon viele andere getan haben), sollten Sie wissen, daß wir jeden Übungsblock so konzipiert haben, daß die meisten Schüler in 45 Minuten bis zu einer Stunde damit fertig sind und noch etwas Zeit für eine Pause bleibt. Die Übungen einiger Kapitel brauchen weniger Zeit, andere dauern etwas länger. Nachdem dem wir den Übungen diese kleinen Zahlen in den eckigen Klammern vorangestellt hatten, wußten wir plötzlich einfach nicht mehr, wie wir sie zusammenzählen sollten.
Was bedeutet »Perl«?
Perl ist die Abkürzung für »Practical Extraction and Report Language«, auch wenn es schon mal als »Pathologically Eclectic Rubbish Lister« (krankhaft zusammengeschustertes Auflistungsprogramm für wirres Zeug) bezeichnet wird.8 Es besteht kein Anlaß, darüber zu diskutieren, welche Interpretation die richtige ist - beide Versionen werden von Larry Wall unterstützt. Larry ist der Erfinder, Hauptentwickler, Implementierer und Hauptverantwortliche für die Weiterentwicklung von Perl. Als Larry Mitte der achtziger Jahre versuchte, ein Fehlersuchprogramm zu erstellen, das mit einer Usenet-News-artigen Dateistruktur arbeitete, ging awk bei der Aufgabe die Luft aus. Faul, wie er war,9 versuchte Larry das Problem mit einem Mehrzweck-Werkzeug zu erschlagen, das er noch für mindestens einen anderen Zweck benutzen konnte. Das Ergebnis war Perl Version Null.
Warum hat Larry nicht einfach eine andere Sprache benutzt?
Es gibt doch schon genug Computersprachen, oder? Als Larry Perl erfand, konnte er jedoch nichts finden, das genau seinen Bedürfnissen entsprach. Wäre eine der heutigen Sprachen damals verfügbar gewesen, hätte er vermutlich eine davon benutzt. Er benötigte eine Sprache, in der er, wie auf der Shell oder in awk, schnell mal etwas zusammentippen konnte. Dabei sollte es allerdings die Mächtigkeit von höherentwickelten Werkzeugen, wie etwa grep, cut, sort und sed,10 haben, ohne dabei auf eine Sprache wie C zurückgreifen zu müssen.
Perl versucht also, die Lücke zwischen Low-Level-Programmierung (wie z. B. in C, C++ oder Assembler) und High-Level-Programmierung (z. B. Shell-Programmierung) zu schließen. Low-Level-Programme sind in der Regel schwer zu schreiben und häßlich, dafür aber schnell und unbegrenzt einsetzbar. Gut geschriebene Low-Level-Programme sind auf der richtigen Maschine schwer zu schlagen - das ist nun einmal so. Das andere Extrem, die High-Level-Programme, tendieren dazu, langsam, schwer, häßlich und begrenzt zu sein. Viele Dinge lassen sich mit der Shell nur erledigen, wenn es auf Ihrem System auch ein Kommando gibt, das diese Funktionalität bereitstellt. Perl ist einfach, fast unbegrenzt, meistens schnell und ein bißchen häßlich.
Lassen Sie uns diese vier Behauptungen noch einmal einzeln betrachten:
Perl ist einfach. Wie Sie sehen werden, bedeutet das, daß Perl einfach zu benutzen ist, wodurch es aber nicht unbedingt einfach zu lernen ist. Bevor Sie ein Auto fahren können, verbringen Sie viele Wochen oder Monate damit, es zu lernen. Jetzt fällt es Ihnen jedoch leicht. Wenn Sie die gleiche Zeit, die Sie gebraucht haben, um fahren zu lernen, damit verbracht haben, Perl zu lernen, wird auch Perl Ihnen leichtfallen.11
Perl ist fast unbegrenzt. Es gibt ein paar Dinge, die Sie nicht mit Perl machen können. Perl ist nicht gerade die Sprache, um einen interrupt-gesteuerten Gerätetreiber auf Basis eines Mikrokernels zu schreiben (auch wenn das schon gemacht wurde). Die meisten Durchschnittsanwendungen bewältigt Perl ohne Probleme, von schnell zusammengetippten Einmalprogrammen, bis hin zu Anwendungen von industriellem Ausmaß.
Perl ist meistens schnell. Das liegt daran, daß niemand Perl weiterentwickelt, ohne es auch selbst zu benutzen - also wollen wir alle, daß es schnell ist. Bringt jemand ein neues Feature ein, das zwar sehr cool wäre, andere Programme aber verlangsamen könnte, ist es ziemlich sicher, daß Larry es zurückweist, bis wir einen Weg gefunden haben, es schnell genug zu machen.
Perl ist ein bißchen häßlich. Das stimmt. Das Symbol von Perl ist das Kamel und stammt vom Buchumschlag des hochgeschätzten Kamel-Buchs (auch bekannt als Programming Perl bzw. Programmieren mit Perl), der Schwester dieses Buches. Kamele sind auch ein bißchen häßlich, aber sie arbeiten hart, selbst unter schwierigen Bedingungen. Kamele sind dafür da, die Arbeit trotz aller Schwierigkeiten zu erledigen, selbst wenn sie schlecht aussehen, noch schlechter riechen und einen manchmal anspucken. Perl ist so ähnlich.
Ist Perl nun schwer oder leicht?
Perl ist einfach zu benutzen, manchmal aber schwer zu lernen. Dies ist selbstverständlich eine Verallgemeinerung. Als Larry Perl entwickelte, mußte er eine Menge Kompromisse eingehen. Wo immer es möglich war, dem Programmierer etwas zu erleichtern, auch wenn es dadurch für den Schüler schwerer würde, hat Larry sich fast immer zugunsten des Programmierers entschieden. Der Grund besteht darin, daß Sie Perl nur einmal lernen, aber immer wieder benutzen.12
Perl besitzt eine Reihe von Annehmlichkeiten, die dem Programmierer viel Zeit sparen helfen. So haben die meisten Funktionen ein Standardverhalten. Der Standard ist die Art, auf die Sie diese Funktion die meiste Zeit verwenden. Betrachten Sie einmal diese Zeilen Perl-Code:
Komplett ausgeschrieben, ohne das Standardverhalten und die Abkürzungen von Perl zu benutzen, wäre dieser Code-Schnipsel etwa zehn- bis zwölfmal länger. Sie würden also auch wesentlich länger brauchen, um ihn zu lesen und zu schreiben. Es wäre außerdem schwieriger, den Code zu debuggen und es müßten mehr Variablen verwendet werden. Wenn Sie bereits etwas Perl kennen und feststellen, daß keine Variablen im Code vorkommen, so ist das ein Teil dessen, was wir Ihnen hier klarzumachen versuchen. Sie werden durch das Standardverhalten definiert. Den Preis für diese Erleichterung beim Programmieren zahlen Sie beim Lernen, weil Sie das Standardverhalten und die Abkürzungen ebenfalls lernen müssen.
Sobald Sie einmal mit Perl vertraut sind, werden Sie weniger Zeit benötigen, das Shell-Quoting (oder C-Deklarationen) richtig hinzubekommen, und mehr Zeit haben, um im Internet zu surfen. Die klaren Konstrukte von Perl erlauben Ihnen (mit minimalem Aufwand), einige sehr coole Einmallösungen oder auch allgemein verwendbare Werkzeuge zu erstellen. Zudem können Sie diese Werkzeuge zu Ihrer nächsten Arbeitsstätte mitnehmen, da Perl hochportabel ist und dort oft bereits installiert ist, so daß Sie sogar noch mehr Zeit haben, im Web zu surfen.
Perl besitzt ein sehr hohes Sprachniveau. Das bedeutet, daß der Code eine sehr hohe »Dichte« aufweist. Ein Perl-Programm ist etwa 30 bis 70% so lang wie ein entsprechendes C-Programm. Dadurch ist Perl schneller zu schreiben, schneller zu lesen, schneller zu debuggen und leichter zu pflegen. Sie brauchen nicht viel Programmiererfahrung, um zu sehen, daß die gesamte Subroutine klein genug ist, um vollständig auf den Bildschirm zu passen. Sie müssen also nicht ständig hin- und herscrollen, um zu sehen, was gerade passiert. Außerdem verhält sich die Anzahl der Bugs in einem Programm ungefähr proportional zur Länge des Quellcodes (nicht proportional zur Funktionalität).14 Der kürzere Quellcode bei Perl bedeutet also im Schnitt auch weniger Bugs.
Wie in jeder Sprache, ist es auch in Perl möglich, so zu programmieren, daß das Programm hinterher nicht mehr lesbar ist. Wenn Sie allerdings sorgfältig vorgehen, können Sie diesen oft gehörten Vorwurf jedoch vermeiden. Für Außenstehende sieht Perl aus wie ein »Rauschen in der Leitung«, für Eingeweihte jedoch sieht es aus wie ein Rauschen in der Leitung mit einer Prüfsumme und einer Lebensaufgabe. Wenn Sie sich an die Richtlinien in diesem Buch halten, sollten Ihre Programme leicht zu lesen und ebenso leicht zu pflegen sein. Dafür werden Sie aber vermutlich den »Obfuscated Perl Contest«15 leider nicht gewinnen.
Warum ist Perl so beliebt?
Nachdem Larry ein bißchen mit Perl herumgespielt und es um ein paar Dinge ergänzt hatte, veröffentlichte er es in der Gemeinschaft der Usenet-Leserschaft. Die Benutzer dieses zusammengewürfelten Haufens von Systemen auf der ganzen Welt (schon damals mehrere Zehntausend) gaben ihm Rückmeldungen und fragten nach Möglichkeiten, dieses oder jenes zu erledigen, wovon Larry eigentlich nie gedacht hatte, daß sein kleines Perl damit umgehen sollte.
Das Resultat war, daß Perl wuchs und wuchs und wuchs. Es wuchs in seinen Möglichkeiten. Es wuchs in seiner Portabilität. Was früher einmal eine kleine Sprache war, die nur auf ein paar Unix-Systemen verfügbar war, ist heute zu einer Größe herangewachsen, die Tausende von Seiten frei erhältlicher Dokumentation beinhaltet, Dutzende von Büchern hervorgebracht hat und in einer großen Anzahl von Mainstream-Usenet-Newsgruppen (und einem Dutzend Newsgruppen und Mailing-Listen, die nicht so »Mainstream« sind) diskutiert wird, die eine unschätzbare Anzahl von Lesern haben. Mittlerweile ist Perl auf fast jedem Betriebssystem, das heute benutzt wird, zu Hause - und vergessen Sie darüber nicht das Lama-Buch.
Was geschieht in Zukunft mit Perl?
Larry ist weiterhin für Perl zuständig, auch wenn das Perl-Entwicklungsteam im Kern ungefähr dreißig Leute und einige Hundert Helfer auf der ganzen Welt umfaßt. Und Perl wächst immer noch weiter.
Im Moment kann Perl von Ihnen kostenlos benutzt werden. Tatsächlich hat Larry versprochen, daß Perl immer frei sein wird. (Er ist ein echt netter Kerl, Sie würden ihn mögen.) Sie können Ihre Programme also heute in Perl schreiben, ohne sich darüber Sorgen machen zu müssen, ob Sie morgen für Ihr Programm Lizenzgebühren bezahlen müssen.
Aber wer bezahlt Larry und die anderen Entwickler, wenn Perl frei erhältlich ist? Nun, die meisten von uns leisten unsere Beiträge zu Perl ehrenamtlich. Je mehr wir Perl helfen, desto mehr hilft Perl uns. (Sollten Sie jemals eine Möglichkeit sehen, Perl zu verbessern, möchten wir Sie dazu ermuntern, Ihre Beiträge ebenfalls einzuschicken.) In einigen Fällen hat eine Person oder eine Firma jemanden bezahlt, um Entwicklungsarbeit zu leisten. Dies könnte daran liegen, daß diese Leute bestimmte Funktionalitäten so dringend gebraucht haben, daß sie bereit waren, dafür zu bezahlen, oder weil sie einfach die Welt verbessern wollten.
Heutzutage schreibt Larry nicht mehr den gesamten Code allein, aber er leitet auch weiterhin die Entwicklung und trifft die großen Entscheidungen. Eine der wichtigsten Regeln, die er uns gegeben hat, lautet: »Alltägliche Dinge sollten leicht zu erledigen sein; schwere Dinge zumindest möglich.«
Aufgrund dieser Regel können Sie sicher sein, daß für alles, was Sie regelmäßig zu erledigen haben, in Perl eine Abkürzung existiert. Wenn Sie am Ende des Buches angekommen sind, werden Sie in einem typischen Zehn-Zeilen-Programm vermutlich mindestens zehn Abkürzungen benutzen. Dinge dieser Art erleichtern die Arbeit mit Perl auf Kosten der Erlernbarkeit.
Wofür ist Perl wirklich gut geeignet?
Perl ist gut für schnell zusammengeschusterte Programme, die Sie kurz mal in drei Minuten herunterhacken. Perl ist aber auch für lange und ausgedehnte Programme gut, für die ein Team von einem Dutzend Programmierern drei Jahre braucht, bis es fertig ist. Sie werden allerdings eine Menge Programme schreiben, für die Sie von der Konzeption bis zum vollständig getesteten Code keine Stunde brauchen werden.
Perl ist für Probleme optimiert, die zu ungefähr 90% mit Text und ungefähr 10% mit anderen Dingen zu tun haben. Diese Beschreibung scheint auf die meisten Programmieraufgaben zu passen, die sich heutzutage stellen. In einer perfekten Welt könnte ein Programmierer jede Sprache kennen und dadurch in der Lage sein, immer die beste Sprache für ein bestimmtes Projekt zu wählen. Meistens würde er sich wohl für Perl entscheiden.16
Obwohl das World Wide Web noch nicht einmal ein Glitzern in Tim Berners-Lees Augen war, als Larry Perl erdachte, war es doch eine Heirat im (Use-)Net. Manche Leute sagen, weil Perl Anfang der neunziger Jahre zur Verfügung stand, war es möglich, eine große Menge an Inhalten sehr schnell in das HTML-Format umzuwandeln. Das war wichtig, da das Web ohne Inhalt nicht existieren konnte. Selbstverständlich war Perl auch die Sprache der Wahl für kleine CGI-Skripten (Programme, die von einem Webserver ausgeführt werden). Dies ging sogar so weit, daß schlecht informierte Leute immer wieder fragten »Ist Perl nicht sowieso nur CGI?« oder »Warum sollte man Perl überhaupt für etwas anderes als CGI einsetzen?«. Wir finden solche Fragen sehr amüsant.
Wofür ist Perl nicht gut geeignet?
Wofür ist Perl denn nicht gut, wo es doch für so viele Dinge gut geeignet ist? Nun, Sie sollten Perl nicht benutzen, wenn Sie versuchen, opaken Binärcode zu erzeugen. Das ist ein Programm, das Sie an Leute weitergeben oder verkaufen, ohne daß diese Ihre geheimen Algorithmen im Quellcode sehen können. Sie können Ihnen also auch nicht helfen, Ihren Code zu debuggen oder zu pflegen. Wenn Sie jemandem Ihr Perl-Programm weitergeben, geben Sie in der Regel den Quellcode weiter und keinen opaken Binärcode.
Wenn Sie opaken Binärcode haben wollen, müssen wir Ihnen leider sagen, daß es so etwas nicht gibt. Wenn jemand Ihr Programm installieren und ausführen kann, kann das Programm auch wieder in Quellcode zurückverwandelt werden. Dies ist nicht unbedingt derselbe Quellcode, mit dem Sie angefangen haben, aber es ist auf jeden Fall Quellcode. Der korrekte Weg, Ihre geheimen Algorithmen weiterhin geheimzuhalten, besteht also vielmehr darin, eine angemessene Anzahl Rechtsanwälte zu beschäftigen. Diese können dann eine Lizenz aufsetzen, in der steht: »Sie können dieses mit dem Code machen, jenes aber nicht. Sollten Sie entgegen unseren Regeln jenes trotzdem tun, verfügen wir über eine angemessene Anzahl Rechtsanwälte, um Ihnen versichern zu können, daß Sie es bereuen werden.«
Wenn Sie Perl-Code trotzdem in Binärcode kompilieren wollen, sehen Sie sich bitte den Abschnitt »Wie kompiliere ich Perl?« weiter hinten in diesem Kapitel an.
Wo kann ich Perl bekommen?
Vermutlich haben Sie es bereits. Zumindest da, wo wir hingehen, ist Perl immer zu finden. Es wird mit vielen Betriebssystemen bereits ausgeliefert und Systemadministratoren installieren es oft auf jeder Maschine ihrer Site.17 Wenn sich Perl jedoch nicht schon auf Ihrem System befindet, ist es kostenlos erhältlich.
Perl wird unter zwei verschiedenen Lizenzvereinbarungen verteilt. Da Sie Perl in der Regel nur benutzen, ist für Sie eine Lizenz so gut wie die andere. Wenn Sie Perl selbst verändern wollen, sollten Sie die Lizenzen jedoch etwas genauer lesen, da es einige Beschränkungen gibt, was die Verteilung von modifiziertem Code angeht. Für Leute, die Perl nicht modifizieren wollen, besagen beide Lizenzen im Prinzip: »Perl ist freie Software - haben Sie viel Spaß damit.«
Tatsächlich ist Perl nicht nur frei erhältlich, sondern läuft auch noch auf so ziemlich allem, was sich Unix nennt und einen C-Compiler besitzt. Sie müssen es nur herunterladen, ein oder zwei Kommandos eingeben und schon beginnt es, sich selbst zu konfigurieren und zu kompilieren. Oder noch besser: Bringen Sie Ihren Systemadministrator dazu, es für Sie zu installieren.18
Abgesehen von Benutzern von Unix und Unix-artigen Systemen gab es sogar Leute, die süchtig genug nach Perl waren, um es auch für andere Systeme zu portieren, wie MacOS19, VMS, OS/2 und selbst für MS/DOS und jede Spezies von Windows. Und während Sie dies hier lesen20, sind vermutlich schon wieder einige dazugekommen. Viele dieser Portierungen von Perl werden mit einem Installationsprogramm verteilt, was die Installation von Perl auf diesen Systemen sogar noch leichter macht als unter Unix. Sehen Sie sich die Links in der »ports«-Sektion des CPAN an.
Was ist das CPAN?
Das CPAN ist das Comprehensive Perl Archive Network, Ihre erste Anlaufstelle, wenn es um Perl geht. Hier bekommen Sie den Quellcode von Perl selbst, Portierungen für alle möglichen Nicht-Unix-Systeme, die Sie nur noch zu installieren brauchen,21 Beispiele, Dokumentation und Erweiterungen zu Perl sowie Nachrichtenarchive, die sich mit Perl beschäftigen. Kurz gesagt, das CPAN ist »comprehensive« (dt. »umfassend«).
Das CPAN wird auf Hunderten von Rechnern weltweit gespiegelt; beginnen Sie einfach bei http://www.cpan.org/, um eine Mirror-Site in Ihrer Nähe zu finden. Meistens können Sie einfach http://LÄNDERCODES.cpan.org/ eingeben, wobei LÄNDERCODES die offizielle, aus zwei Buchstaben bestehende Abkürzung für Ihr Land ist (wie es am Ende Ihrer nationalen Domainnamen zu finden ist, z. B. de, at, ch usw.). Falls Sie keinen Internet-Zugang haben, hat Ihr EDV-Buchladen vielleicht eine CD- oder DVD-ROM vorrätig, auf der die nützlichen Teile des CPAN zu finden sind. Achten Sie jedoch darauf, daß es sich um eine aktuelle Kopie des Archivs handelt, da das CPAN täglich aktualisiert wird. Ein zwei Jahre altes Archiv gilt als Antiquität. (Besser wäre es, wenn Sie jemanden mit einer schnellen Netzanbindung finden, der Ihnen das aktuelle CPAN auf eine CD brennt.)
Das CPAN ist recht gut organisiert; meistens sollten Sie mit ein paar Mausklicks finden, was Sie suchen. Zusätzlich gibt es noch eine Reihe von netten Suchmaschinen im Web, zu finden unter http://search.cpan.org/ und http://kobesearch.cpan.org/, welche besonders hilfreich sind, wenn Sie nach einer Erweiterung für Perl suchen.
Wo bekomme ich Support für Perl?
Tja, Sie haben doch den kompletten Quellcode - also können Sie die Bugs auch selbst entfernen!
Klingt nicht so gut, oder? Ist es aber. Da es bei Perl keine »Quellcode-Hinterlegung« (»Source Code Escrow») gibt, kann im Prinzip jeder den Fehler beheben. Wenn Sie einen Fehler gefunden und verifiziert haben, hat ihn jemand anderes vielleicht schon behoben. Tausende von Leuten weltweit helfen mit, Perl zu pflegen.
Damit wollen wir jetzt nicht sagen, Perl sei voller Bugs. Aber es handelt sich um ein Programm und jedes Programm hat mindestens einen Bug.22
Um zu erkennen, warum es so nützlich ist, den Quellcode von Perl zu besitzen, stellen Sie sich einmal vor, Sie hätten es statt dessen mit einem gigantischen, mächtigen Konzern zu tun, dessen Besitzer ein Zillionär mit einem schlechten Haarschnitt ist. Von diesem hätten Sie nun eine Lizenz für eine Programmiersprache namens Forehead erworben. (Das ist natürlich alles hypothetisch. Jeder weiß, daß es keine Sprache mit dem Namen Forehead gibt.) Jetzt überlegen Sie einmal, was Sie tun können, wenn Sie einen Fehler in Forehead entdecken. Zuerst einmal können Sie diesen Fehler melden; danach können Sie hoffen - hoffen, daß der Fehler behoben wird, hoffen, daß der Fehler bald behoben wird, und hoffen, daß der Konzern für die neue Version keinen zu hohen Preis verlangt. Sie können nur hoffen, daß in der neuen Version keine neuen Features vorkommen, die neue Fehler enthalten, und Sie können hoffen, daß der gigantische Konzern nicht durch ein Gerichtsverfahren wegen Ausnutzung der Monopolstellung in viele kleine Teile zerschlagen wird.
Perl wird hingegen zusammen mit seinem Quellcode verteilt. Tritt der seltene Fall auf, daß sich der Fehler nicht auf eine andere Art beseitigen läßt, können Sie notfalls einen oder zehn Programmierer engagieren und an die Arbeit gehen. Falls Sie in diesem Fall einen neuen Rechner kaufen, auf dem Perl noch nicht unterstützt wird, können Sie Ihre eigene Portierung schreiben. Und wenn Sie ein Feature brauchen, das es noch nicht gibt, wissen Sie ja nun, was zu tun ist.
Gibt es auch noch andere Arten von Support?
Einer unserer Favoriten sind die »Perl Mongers«. Dies ist ein weltweiter Zusammenschluß von Perl-Benutzergruppen. Weitere Informationen dazu finden Sie unter http://www.pm.org/. Höchstwahrscheinlich gibt es auch bei Ihnen in der Nähe eine Gruppe mit einem Experten oder jemandem, der einen Experten kennt. Falls es noch keine Gruppe gibt, können Sie einfach eine ins Leben rufen.
Selbstverständlich sollten Sie als erste Quelle für Support die Dokumentation nicht unbeachtet lassen. Neben den eigentlichen Manpages23 enthält die Dokumentation von Perl eine umfangreiche Sammlung von FAQs (Frequently Asked Questions, häufig gestellte Fragen) und eine Reihe von Anleitungen.
Eine weitere erstklassige Informationsquelle ist das Buch Programmieren mit Perl, auch bekannt als das »Kamel-Buch« (so wie dieses Buch als das »Lama-Buch« bekannt ist). Das Kamel-Buch enthält eine vollständige Referenz zu Perl, einige Anleitungen und eine Reihe von verschiedenen anderen Informationen zu Perl. Außerdem gibt es noch die Kurzreferenz (von Johan Vromans), die sich gut macht, wenn sie zur Hand ist.
Wenn Sie jemanden etwas fragen müssen, gibt es hierfür die Perl-Newsgruppen sowie eine Reihe von Mailing-Listen.24 Unabhängig von der Tageszeit bei Ihnen ist in irgendeiner Zeitzone dieser Welt immer ein Perl-Experte gerade wach und beantwortet Fragen zu Perl im Usenet - im Reich von Perl geht die Sonne nie unter. Das bedeutet: Wenn Sie eine Frage stellen, kann es sein, daß Sie innerhalb von Minuten eine Antwort erhalten. Wenn Sie vorher jedoch nicht die Dokumentation und die FAQs konsultiert haben, werden Sie innerhalb von Minuten eine Menge »Flames« erhalten.
Normalerweise empfehlen wir die Newsgruppe comp.lang.perl.moderated, bei der (wie der Name verrät) ein Moderator sich Ihre Frage zuerst ansieht, bevor sie gepostet wird. Wenn mit Ihrer Frage etwas nicht stimmt, können Sie selbstverständlich trotzdem mit »Flames« rechnen, allerdings eher im Kleinen per E-Mail als in der Öffentlichkeit der Newsgruppe.25 Für die meisten Fragen können Sie innerhalb einer Stunde mit einer Antwort rechnen. Versuchen Sie einmal dieses Niveau an Unterstützung kostenlos von Ihrem Software-Händler zu bekommen!
Die offiziellen Perl-Newsgruppen befinden sich in der comp.lang.perl.*-Hierarchie. Während wir dieses Buch schreiben, gibt es fünf verschiedene Gruppen, aber das ändert sich von Zeit zu Zeit. Die zwei deutschsprachigen Newsgruppen finden Sie unter der de.comp.lang.perl.*-Hierarchie. Sie (oder wer sonst in Ihrer Firma für Perl zuständig ist) sollten in jedem Fall die Newsgruppe comp.lang.perl.announce abonnieren. Hierbei handelt es sich um eine Gruppe mit relativ wenigen Nachrichten, die nur für wichtige Ankündigungen zum Thema Perl, insbesondere für sicherheitsbezogene Themen, da ist. Fragen Sie Ihren örtlichen Spezialisten, falls Sie Hilfe mit dem Usenet brauchen.
Es gibt außerdem eine Reihe von Gruppen im Web, die sich rund um die Diskussionen um Perl gebildet haben. Eine recht populäre Gruppe ist unter dem Namen »The Perl Monastery« (»Perl-Mönche«, zu finden unter: http://www.perlmonks.org) bekannt. Hier finden sich viele der Perl-Buchautoren und Artikelschreiber, unter anderem auch mindestens einer der Autoren dieses Buches.
Für den Fall, daß Sie einen Support-Vertrag für Perl abschließen wollen, gibt es eine Reihe von Firmen, die gern bereit sind, Ihnen so viel Geld abzunehmen, wie Sie wollen. Die meisten anderen Support-Formen sind jedoch kostenlos.
Was soll ich tun, wenn ich einen Bug in Perl entdecke?
Zuallererst sollten Sie noch einmal26 in der Dokumentation27 nachlesen. Perl hat ein paar Besonderheiten und Regelausnahmen, und es kann gut sein, daß das, was Sie als Fehler auffassen, eigentlich ein Feature ist. Des weiteren sollten Sie überprüfen, ob Sie eventuell eine veraltete Version von Perl haben; vielleicht sind Sie auf etwas gestoßen, was in einer neueren Version bereits behoben wurde.
Erst wenn Sie sich zu 99% sicher sind, daß es sich um einen Fehler handelt, sollten Sie nachfragen. Fragen Sie bei einem Arbeitskollegen, einer örtlichen Perl-Mongers-Gruppe oder in einer Perl-Konferenz nach. Die Chancen stehen gut, daß es sich trotzdem um ein Feature handelt und nicht um einen Fehler.
Erst wenn Sie sich zu 100% sicher sind, einen Fehler gefunden zu haben, denken Sie sich ein Test-Szenario aus (sofern Sie das nicht schon getan haben). Der ideale Testfall besteht aus einem kleinen Programm, das ein beliebiger Benutzer laufen lassen kann, um das (Fehl-)Verhalten nachzuvollziehen, das Sie entdeckt haben. Erst wenn Sie einen Testfall haben, der deutlich zeigt, daß es sich um einen Fehler handelt, verwenden Sie das perlbug-Hilfsprogramm, das zusammen mit Perl verteilt wird, um den Fehler zu melden. Hiermit wird in der Regel eine E-Mail an die Perl-Entwickler verschickt; benutzen Sie perlbug also nicht, ohne ein Test-Szenario zur Hand zu haben.
Sobald Sie Ihren Fehlerbericht abgeschickt und dabei alles richtig gemacht haben, ist es nicht ungewöhnlich, wenn Sie innerhalb von Minuten eine Antwort bekommen. Normalerweise können Sie einen kleinen Patch anwenden und gleich weiterarbeiten. Unter Umständen (oder: schlimmstenfalls) bekommen Sie auch gar keine Antwort. Keiner der Perl-Entwickler wird dazu gezwungen, Ihre Fehlerberichte zu lesen. Dennoch lieben wir alle Perl viel zu sehr, als daß wir einen Fehler unbeachtet lassen wollten.
Wie schreibe ich ein Perl-Programm?
Das wurde aber auch Zeit, daß Sie fragen (auch wenn Sie's nicht getan haben). Perl-Programme sind Textdateien. Daher reicht zum Programmieren auch ein einfacher Texteditor aus. (Sie brauchen keine spezielle Entwicklungsumgebung, auch wenn es davon einige zu kaufen gibt. Wir können Ihnen hier aber keine empfehlen, da wir selbst nicht oft damit arbeiten.)
Ein Texteditor ist für Programmierer sinnvoller als ein normales Textverarbeitungsprogramm. Der Unterschied besteht darin, daß ein Texteditor für Programmierer oft eine Reihe hilfreicher Funktionen hat, wie etwa das automatische Einrücken von Code-Blöcken oder das Finden einer schließenden geschweiften Klammer. Die zwei beliebtesten Editoren für Programmierer unter Unix heißen emacs und vi (sowie deren Variationen und Klone). Beide sind inzwischen auf eine Reihe von Nicht-Unix-Systemen portiert worden. Auf vielen Systemen gibt es mittlerweile auch grafisch orientierte Editorprogramme (bei denen anstelle der Tastatur z. B. eine Maus benutzt wird). Es gibt inzwischen sogar Versionen von vi und emacs, die eine grafische Benutzeroberfläche bieten. Auch hier können Sie wieder Ihren lokalen Experten fragen, welcher Texteditor für Ihr System der richtige zum Programmieren ist.
Die einfachen Programme, die Sie während der Übungen dieses Buches schreiben, haben kaum mehr als zwanzig bis dreißig Zeilen Code, wofür jeder Texteditor28 vollkommen ausreichend ist.
Anfänger versuchen immer wieder gern, ein Textverarbeitungsprogramm (z. B. Word oder Works) statt eines Texteditors zum Programmieren zu verwenden. Wir raten jedoch davon ab - die Verwendung dieser Programme für diesen Zweck ist unbequem oder schlimmstenfalls sogar unmöglich. Wir wollen Ihnen hier jedoch nichts vorschreiben. Stellen Sie aber auf jeden Fall sicher, daß Ihre Dateien im »Nur Text«-Format gespeichert werden. Das Standardformat des Textverarbeitungsprogramms ist in den meisten Fällen unbrauchbar.
In manchen Fällen müssen Sie ein Programm vor seiner Ausführung auf einen anderen Rechner übertragen. Stellen Sie hierbei sicher, daß für die Übertragung der »Text«- oder »ASCII«-Modus anstelle des »Binär«-Modus verwendet wird. Dies ist wichtig, da reiner Text auf verschiedenen Maschinen unterschiedlich gespeichert wird. Wenn Sie das nicht tun, kann es passieren, daß Ihr Programm nicht richtig ausgeführt wird - einige Perl-Versionen brechen das Programm einfach ab, wenn sie die Zeilenenden nicht richtig erkennen.
Ein einfaches Programm
Eine alte Regel besagt, daß jedes Buch über eine Computersprache, die Unix-artige Wurzeln hat, mit dem »Hallo Welt!«-Programm beginnen muß. Hier also die Version in Perl:
Wir stellen uns einmal vor, Sie hätten das Obenstehende in Ihren Texteditor eingegeben. (Machen Sie sich keine Gedanken darüber, was die einzelnen Teile bedeuten und wie sie funktionieren. Wir werden uns das alles gleich ansehen.) Sie können das Programm in der Regel unter jedem beliebigen Namen abspeichern. Perl erwartet normalerweise kein bestimmtes Format für Dateinamen oder -endungen; es ist sowieso am besten, überhaupt keine Endung zu benutzen.29 Auf manchen Nicht-Unix-Systemen ist es dennoch nötig, Dateien mit einer Endung wie etwa .plx zu versehen (was soviel wie PerL eXecutable oder ausführbare Perl-Datei heißt). Die Dokumentation für Ihre Version von Perl gibt Ihnen darüber Aufschluß.
Außerdem müssen Sie Ihrem System irgendwie mitteilen, daß Ihre Datei nun ein ausführbares Programm (soll heißen: ein Kommando) ist. Was genau zu tun ist, hängt von Ihrem jeweiligen Betriebssystem ab; vielleicht brauchen Sie auch gar nichts zu tun, außer das Programm an einem bestimmten Ort abzulegen. Auf Unix-Systemen müssen Sie das Programm als ausführbar kennzeichnen, indem Sie das chmod-Kommando benutzen. Etwa so:
Das Dollarzeichen (und das folgende Leerzeichen) am Beginn der Zeile bezeichnen eine Eingabeaufforderung auf der Shell. Selbstverständlich können Sie chmod statt des symbolischen Parameters a+x auch einen numerischen Wert übergeben, wie zum Beispiel 755. Beides teilt dem System mit, daß diese Datei nun ein ausführbares Programm ist.
Und jetzt können sie es laufen lassen:
Der Punkt und der Schrägstrich (oder Slash) teilen dem System mit, daß sich das Programm im gegenwärtigen Verzeichnis befindet. Diese Angabe wird nicht immer benötigt, aber Sie sollten sie zu Beginn jedes Kommandoaufrufs verwenden, bis Sie vollständig verstanden haben, was hier passiert.30
Es ist ziemlich unwahrscheinlich, daß alles gleich klappt. Öfter werden Sie feststellen, daß Ihr Programm noch irgendwo einen Fehler hat. Ändern Sie es ab, und probieren Sie es noch einmal. Hierfür müssen Sie chmod nicht noch einmal aufrufen, da diese Mitteilung mit Ihrer Datei »verbunden« sein sollte. (Besteht der Fehler natürlich darin, daß Sie chmod nicht korrekt verwendet haben, bekommen Sie vermutlich von der Shell die Nachricht »permission denied« - keine Berechtigung, das Programm auszuführen.)
Was passiert im Inneren des Programms?
Wie auch bei anderen Sprachen, in denen Sie »frei formulieren« dürfen, können Sie in Perl beliebig Whitespace-Zeichen (wie Leerzeichen, Tabulatoren und Newline-Zeichen) verwenden, um Ihr Programm lesbarer zu machen. Die meisten Perl-Programme, wie auch die meisten unserer Beispiele, verwenden ein recht standardisiertes Format. Wir möchten Sie dringend dazu ermutigen, Ihre Programme korrekt einzurücken, weil Ihr Programm dadurch leichter zu lesen ist; ein guter Texteditor sollte die meiste Arbeit für Sie erledigen. Gute Kommentare erleichtern ebenfalls die Lesbarkeit. In Perl beginnen Kommentare mit einem Doppelkreuz (#) und enden am Zeilenende. (In Perl gibt es keine »Kommentar-Blöcke«.31) In den Programmen dieses Buches benutzen wir selten Kommentare, da der umgebende Text Erklärung genug ist. Ihre eigenen Programme sollten Sie jedoch ausreichend kommentieren.
Eine andere (allerdings sehr seltsame) Art, das gleiche »Hallo Welt!«-Programm zu schreiben, könnte etwa so aussehen:
Die erste Zeile ist hierbei ein sehr spezieller Kommentar. Lauten auf einem Unix-System32 die ersten zwei Zeichen einer Textdatei »#!«, so bezeichnet der Rest der Zeile den Namen des Programms, das die Datei ausführt. In diesem Fall ist das Programm unter dem Pfad /usr/bin/perl zu finden.
Tatsächlich ist die #!-Zeile diejenige, die am wenigsten portabel ist, da es für jedes System unterschiedlich sein kann, was hier zu stehen hat. Glücklicherweise ist das so gut wie immer /usr/bin/perl oder /usr/local/bin/perl. Ist das einmal nicht der Fall, können Sie einfach den folgenden Zauberspruch auf Ihren Systemadministrator anwenden. Sagen Sie ihm einfach: «Weißt Du, ich habe in diesem Buch gelesen, daß /usr/bin/perl und /usr/local/bin/perl eigentlich symbolische Links zum Perl-Interpreter sein sollten.« Und unter dem Einfluß Ihres Zauberspruches wird der Admin alles so richten, wie Sie es brauchen. Alle Beispielprogramme, die Sie im Netz oder anderswo finden, beginnen mit einer dieser zwei Formen.
Auf allen anderen Nicht-Unix-Systemen wird hier traditionsgemäß die Zeile #!perl verwendet. Auch wenn es eigentlich nicht nötig ist, wird diese Zeile konventionsgemäß beibehalten. Sollte jemand später einmal Ihr Programm an ein anderes Betriebssystem anpassen müssen, so ist auf jeden Fall klar, daß es sich um Perl-Code handelt.
Stehen in der #!-Zeile die falschen Informationen, wird Ihnen die Shell eine Fehlermeldung anzeigen. Dies könnte etwas Unerwartetes sein, wie etwa »file not found«. Ihr Programm wurde hierbei zwar gefunden, aber /usr/bin/perl befand sich offenbar nicht an der richtigen Stelle. Um es etwas klarer zu machen: Die Fehlermeldung kommt nicht von Perl selbst, sondern es ist die Shell, die sich hier beklagt. (Übrigens: Es heißt nicht user, sondern usr - die Erfinder von Unix waren ziemlich faul, was das Tippen angeht, also haben sie eine Menge Buchstaben einfach weggelassen.)
Ein anderes Problem kann auftreten, wenn Ihr System die #!-Notation überhaupt nicht erkennt. In diesem Fall wird die Shell (oder was auch immer Ihr System benutzt) vermutlich versuchen, das Programm an sich auszuführen. Die Qualität der Ergebnisse reicht von enttäuschend bis erstaunlich. Die Dokumentation zu Ihrem System oder die Manpage perldiag sollten Ihnen in diesem Falle Aufschluß darüber geben, um welche Art von Fehler es sich hier handelt.
Das Haupt- oder »main«-Programm besteht aus allen allgemeinen Perl-Anweisungen (ohne die Subroutinen, wie wir bald sehen werden). Im Gegensatz zu Sprachen wie C oder Java gibt es in Perl keine eigentliche »main«-Routine. Tatsächlich haben viele Programme gar keine Routinen (in Form von Subroutinen).
Im Unterschied zu anderen Sprachen ist es auch nicht unbedingt nötig, Variablen vorzudeklarieren. Dies mag Sie anfangs etwas überraschen oder auch beunruhigen, es versetzt Sie jedoch in die Lage, »schnell mal« ein Perl-Programm zu schreiben. Ist Ihr Programm sowieso nur zwei Zeilen lang, wollen Sie sicher keine dieser Zeilen dafür verwenden, erst Ihre Variablen zu deklarieren. Wenn Sie das trotzdem tun wollen, ist das eine gute Sache. Wie das geht, zeigen wir in Kapitel 4, Subroutinen.
Die meisten Anweisungen bestehen aus einem Ausdruck, gefolgt von einem Semikolon. Hier ist eine Anweisung, die wir bereits kennen:
Wie Sie sich vielleicht schon gedacht haben, geben diese Zeilen die Nachricht Hallo Welt! aus. Das Kürzel \n kennen Sie vielleicht schon aus anderen Sprachen, wie C, C++ oder Java; es handelt sich hierbei um das Newline-Zeichen. Dieses Zeichen sorgt dafür, daß die Ausgabeposition zum Beginn der folgenden Zeile weiterwandert. Statt direkt hinter der ausgegebenen Zeile zu stehen, wird die neue Eingabeaufforderung auf einer eigenen Zeile angezeigt. In der Regel wird jede ausgegebene Zeile mit einem Newline-Zeichen abgeschlossen. Im nächsten Kapitel werden Sie neben dem Newline-Zeichen noch weitere sogenannte »Backslash-Escapes« kennenlernen.
Aber wie kann ich mein Perl-Programm denn jetzt kompilieren?
Es überrascht Sie vielleicht, aber ein Perl-Programm zu kompilieren bedeutet, es auszuführen. Beim Ausführen eines Programms wandelt der Perl-Compiler Ihren Quellcode zuerst in internen Bytecode um (eine interne Datenstruktur, die das Programm darstellt); danach wird dieser von Perls Bytecode-Maschine ausgeführt.33
Gibt es also einen Syntax-Fehler in Zeile 200, bekommen Sie die Fehlermeldung, bevor Zeile 2 ausgeführt wird.34 Haben Sie in Ihrem Programm eine Schleife, die fünftausendmal durchlaufen wird, so wird diese trotzdem nur einmal kompiliert, wodurch die eigentliche Schleife mit Hochgeschwindigkeit laufen kann. Auch kommt es zu keinen Geschwindigkeitseinbußen während der Laufzeit Ihres Programms, wenn Sie viele Kommentare benutzt haben, um Ihr Programm leichter verständlich zu machen. Sie können Berechnungen anstellen, die ausschließlich Konstanten verwenden, und das Ergebnis ist eine Konstante, die nur einmal zu Beginn des Programms errechnet wird und nicht für jeden Schleifendurchlauf erneut.
Sicher, die Kompilierung braucht ihre Zeit. Es ist nicht effizient, ein umfangreiches Perl-Programm für eine kleine Aufgabe (von vielen möglichen) zu benutzen, das dann gleich wieder beendet wird. Das liegt daran, daß die Laufzeit des Programms viel kleiner ist als die Zeit, die für das Kompilieren gebraucht wird. Jedoch ist der Compiler sehr schnell und benötigt für die Kompilierung meist nur einen Bruchteil der Laufzeit.
Eine Ausnahme könnte es darstellen, wenn Sie Ihr Programm über das Web ausführen, wo es mehrere hundert- oder tausendmal pro Minute aufgerufen wird. (Dies ist eine sehr große Anzahl von Aufrufen. Die meisten Programme im Web werden normalerweise nicht öfter als hundert- oder tausendmal pro Tag ausgeführt. In diesem Falle brauchen Sie sich keine allzu großen Sorgen um die Performance machen.) Viele dieser Programme haben recht kurze Laufzeiten, wodurch die ständige Rekompilierung zu einem wichtigen Faktor wird. Ist dies für Sie ein Thema, werden Sie vermutlich nach einem Weg suchen, Ihr Programm auch zwischen seinen Aufrufen im Arbeitsspeicher zu halten (ob es sich nun um ein Perl-Programm handelt oder nicht). Lesen Sie in diesem Fall die Dokumentation, und bitten Sie Ihren örtlichen Experten um Hilfe.35
Eine Möglichkeit, den kompilierten Bytecode zu speichern und dadurch den Overhead der Kompilierung zu vermeiden, wäre nicht schlecht. Noch besser wäre es, wenn Sie den Bytecode in eine andere Sprache wie C umwandeln könnten, um diese dann zu kompilieren. Beides ist tatsächlich möglich (das ist jedoch nicht Thema dieses Buches). Die meisten Programme werden dadurch jedoch nicht leichter zu benutzen, zu debuggen oder zu installieren; es kann sogar sein, daß Ihr Programm dadurch eher langsamer läuft.36 Wir kennen jedenfalls niemanden, der jemals ein Perl-Programm kompilieren mußte (außer für experimentelle Zwecke). Wir bezweifeln auch, daß wir jemals jemandem begegnen werden.
Eine Perl-Blitztour
Sie wollen endlich ein Perl-Programm sehen, an dem ein bißchen mehr Fleisch dran ist? (Wenn nicht, machen Sie bitte einfach für den Moment mit - Danke!) Also dann:
Wenn Sie zum ersten Mal Perl-Code wie diesen sehen, kann das erst einmal recht seltsam aussehen. (Um ehrlich zu sein: Perl-Code wie dieser sieht eigentlich immer seltsam aus.) Aber lassen Sie uns Zeile für Zeile vorgehen und sehen, was dieses Beispiel tut. (Diese Erklärungen werden recht kurz sein; schließlich handelt es sich ja auch um eine Blitztour. Im weiteren Verlauf dieses Buches werden wir alle Merkmale eingehend betrachten. Wir erwarten hier nicht, daß Sie jedes Detail jetzt schon verstehen.)
Die erste Zeile ist die #!-Zeile, die Sie ja bereits kennen. Wie gesagt kann es sein, daß Sie diese Zeile für Ihr System anpassen müssen.
Die zweite Zeile führt ein externes Kommando aus, das in Backticks (` `) steht. (Das Backtick-Zeichen finden Sie auf der deutschen Standardtastatur rechts neben dem ß. Verwechseln Sie dieses Zeichen bitte nicht mit dem einfachen Anführungszeichen.) Das Kommando für unser Beispiel lautet perldoc -u -f atan2. Versuchen Sie einmal, es auf der Kommandozeile einzugeben, und beobachten Sie die Ausgabe. Diese Anweisung wird auf den meisten Betriebssystemen verwendet, um die Dokumentation zu Perl sowie den dazugehörigen Erweiterungen und Hilfsprogrammen anzuzeigen, sollte also meistens verfügbar sein.37 Dieses Kommando sagt Ihnen weiterhin etwas über die trigonometrische Funktion atan2. Wir verwenden diese Funktion hier nur als Beispiel für ein externes Kommando, dessen Ausgabe wir verarbeiten wollen.
Die Ausgabe des Kommandos in den Backticks wird in einer Arrayvariablen mit dem Namen @zeilen gespeichert. Die folgende Zeile startet eine Schleife, die jede dieser Zeilen nacheinander abarbeitet. Innerhalb der Schleife sind die Anweisungen eingerückt. Gute Programmierer tun dies, auch wenn es nicht explizit von Perl gefordert ist.
Die erste Zeile innerhalb der Schleife ist am furchteinflößendsten: s/\w<([^>]+)>/\U$1/g;. Hiermit wird jede Zeile verändert, die eine spezielle Markierung (spitze Klammern) enthält. Die Ausgabe des perldoc-Kommandos sollte hiervon mindestens eine enthalten.
Die nächste Zeile gibt überraschenderweise jede (möglicherweise modifizierte) Zeile aus. Das Ergebnis sollte so ähnlich aussehen wie das, was perldoc -u -f atan2 tut, wenn es direkt von der Kommandozeile aus aufgerufen wird. Unterschiede treten auf, wenn Markierungen gefunden werden.
Mit wenigen Zeilen haben wir ein externes Programm aufgerufen, die Ausgabe in den Arbeitsspeicher geladen, die gespeicherten Teile verändert und sie schließlich ausgegeben. Für Aufgaben wie diese wird Perl recht häufig eingesetzt.
Übungen
Normalerweise endet jedes Kapitel mit einer Reihe von Übungen, deren Antworten Sie in Anhang A nachlesen können. Für dieses Kapitel haben wir die Antworten jedoch schon gegeben.
Wenn Sie diese Übungen auf Ihrem Rechner nicht zum Laufen bringen können, überprüfen Sie Ihre Arbeit nochmals, und fragen Sie dann Ihren örtlichen Perl-Experten. Sie müssen Ihr Programm vermutlich, wie im Text beschrieben, ein wenig anpassen.
- [7] Geben Sie das »Hallo Welt!«-Programm ein, und bringen Sie es zum Laufen. Sie können es nennen, wie Sie wollen, ein guter Name wäre zum Beispiel ueb1-1, da es sich hier um die erste Übung in Kapitel 1 handelt.
- [5] Geben Sie auf der Kommandozeile die Anweisung perldoc -u -f atan2 ein, und beobachten Sie die Ausgabe. Wenn das nicht funktioniert, müssen Sie mit Hilfe Ihres Systemadministrators oder der Dokumentation für Ihre Perl-Version herausfinden, wie sich das perldoc-Kommando oder dessen Entsprechung aufrufen läßt. (Für die folgende Übung brauchen Sie das sowieso.)
- [6] Geben Sie das zweite Beispielprogramm (aus dem vorangegangenen Abschnitt) ein, und beobachten Sie dessen Ausgabe. (Hinweis: Geben Sie sämtliche Zeichen exakt so ein, wie es im Text angegeben ist!) Haben Sie bemerkt, wie sich die Ausgabe des Kommandos verändert?
Fußnoten
Um sicherzugehen: Die 1. Auflage wurde von Randal L. Schwartz geschrieben, die 2. von Randal L. Schwartz und Tom Christiansen und diese Auflage von Randal L. Schwartz und Tom Phoenix. Wenn wir also »wir« sagen, meinen wir die letzten zwei. Wenn Sie sich nun fragen, warum es uns Spaß gemacht hat (in der Vergangenheitsform), dieses Buch zu schreiben, obwohl wir uns noch auf der ersten Seite befinden, ist die Antwort leicht: Wir haben hinten angefangen und uns dann rückwärts nach vorne vorgearbeitet. Das mag jetzt zwar etwas seltsam klingen, aber, um ehrlich zu sein, nachdem der Index einmal fertig war, war der Rest kaum noch ein Problem.
Wenn Sie und wir uns tatsächlich ähnlich sind, stehen Sie jetzt eher in einer Bücherei und nicht in einem Buchladen. Aber wir wollen ja nicht kleinlich sein.
Bevor Sie uns jetzt schreiben, um uns mitzuteilen, daß es sich eigentlich um eine Comedy-Truppe handelt, sollten wir Ihnen vielleicht erklären, daß wir - mit einem Buchstabendreher - eigentlich CORBA meinen.
Es sei denn, es ist wirklich eine.
Außer dienstags während eines Stromausfalls, wobei Sie gleichzeitig Ihren Ellenbogen verdrehen und gerade Tag-und-Nacht-Gleiche ist, oder wenn bei einer Perl-Version vor 5.6 use integer innerhalb eines von einer Prototyp-Subroutine aufgerufenen Schleifenblocks benutzt wird.
Wir haben uns sogar überlegt, das ganze Buch als Fußnote zu konzipieren, um die Seitenzahl kleinzuhalten. Wir haben diese Idee jedoch wieder verworfen, weil uns Fußnoten mit Fußnoten dann doch ein bißchen zu verrückt vorkamen.
Hierbei handelt es sich eigentlich um ein Retronym und nicht um ein Akronym. Soll heißen, Larry hatte zuerst den Namen und die Interpretation der Buchstaben erst später. Deshalb schreibt man »Perl« nicht komplett in Großbuchstaben.
Es ist keine Beleidigung für Larry, wenn wir sagen, er sei faul - Faulheit ist eine Tugend. Die Schubkarre wurde von jemandem erfunden, der zu faul war, Dinge zu tragen; das Schreiben wurde von jemandem erfunden, der zu faul war, sich alles zu merken; Perl wurde von jemandem erfunden, der zu faul war, für seine Arbeit eine komplett neue Computersprache zu erfinden.
Machen Sie sich keine Sorgen, wenn Sie nicht wissen, worum es sich hierbei handelt. Wichtig ist nur, daß es Programme sind, die Larry in seiner Unix-Werkzeugkiste hatte, die aber für die anfallenden Arbeiten nicht ausreichten.
Wir hoffen allerdings, daß Ihr Auto nicht so oft abstürzt, wie es so manche Programme tun.
Sofern Sie eine Programmiersprache nur ein paar Minuten in der Woche oder im Monat benutzen, werden Sie vermutlich eine Sprache vorziehen, die sich leichter lernen läßt, da Sie das meiste, was Sie gelernt haben, zwischenzeitlich schon wieder vergessen haben. Perl ist für Leute gedacht, die mindestens zwanzig Minuten täglich programmieren.
Wir werden das Programm hier jetzt nicht komplett erklären, aber dieses Beispiel liest Daten aus einer Eingabedatei mit einem bestimmten Format und gibt Teile davon in einem anderen Format wieder aus. Sämtliche hier verwendeten Merkmale werden im Buch behandelt.
Mit einem großen Sprung, sobald ein Programmteil nicht mehr auf den Bildschirm paßt.
Der »Wettbewerb für verworrenes Perl« ist eine jährliche Veranstaltung, die vom Perl Journal (siehe http:// www.tpj.com/ ) ausgerichtet wird.
Nehmen Sie uns das nicht einfach so ab. Wenn Sie wissen wollen, ob Perl besser ist als die Sprache X, lernen Sie beide Sprachen, probieren Sie beide aus, und finden Sie heraus, welche von beiden Sie öfter benutzen. Das ist dann die Sprache, die für Sie am besten ist. Letztendlich werden Sie Perl besser verstehen, weil Sie die Sprache X erforscht haben und umgekehrt. Sie haben die Zeit also sinnvoll genutzt.
Na ja, zumindest auf jedem Rechner, der zum Programmieren gedacht ist.
Wofür sind Systemadministratoren gut, wenn sie keine Software installieren können? Wenn Sie Schwierigkeiten haben, Ihren Admin davon zu überzeugen, Perl zu installieren, laden Sie ihn auf eine Pizza ein. Wir haben noch nie einen Systemadministrator getroffen, der nein zu einer Pizza sagen konnte, oder zumindest zu etwas ähnlichem, das genauso leicht zu beschaffen war.
MacPerl läuft unter dem »klassischen« Mac OS (Versionen kleiner als 10/X). Wenn Sie Mac OS X installiert haben, das ein Unix-System ist, so ist das reguläre Perl bereits vorinstalliert.
Und, nein, es paßt (noch) nicht auf Ihren Palm - es ist einfach zu groß, selbst wenn es auf das Wesentliche beschränkt ist.
Auf Unix-Systemen ist es fast immer besser, Perl vom Quellcode selbst zu kompilieren. Auf anderen Systemen stehen eventuell kein C-Compiler und andere für die Kompilierung benötigte Werkzeuge zur Verfügung. Für diese Systeme finden Sie die bereits kompilierten Binärdateien im CPAN.
Programmierer wissen außerdem, daß jedes Programm mindestens eine Zeile unnötigen Code enthält. Wenn Sie nun diese beiden Regeln zusammennehmen und die logische Schlußfolgerung ziehen, ist es ganz einfach zu beweisen, daß jedes Programm sich auf eine einzige Zeile fehlerhaften Code reduzieren läßt.
Das Wort Manpage (Manual page, Handbuchseite) kommt aus der Unix-Welt und bedeutet »Dokumentation«. Wenn Sie nicht mit Unix arbeiten, sollten die Manpages für Perl über das auf Ihrem Rechner installierte Hilfesystem zugänglich sein. Wenn Sie die Dokumentation nirgendwo finden, sind die Manpages auch direkt im CPAN zugänglich.
Viele Mailing-Listen sind unter der Adresse http://lists.perl.org zu finden.
Natürlich machen wir nur Witze. Vorausgesetzt, Sie fragen nicht wirklich etwas vollkommen Hirnverbranntes, sind die Moderatoren sehr nette, höfliche, hilfsbereite Zeitgenossen, die Ihnen freundlich sagen, wo Sie die gesuchte Information finden. Es gibt nur so viele »Flames« wie nötig, um Sie daran zu erinnern, das nächste Mal etwas vorsichtiger zu sein. Haben Sie also keine Angst zu fragen.
Vielleicht sogar eher zwei- bis dreimal. Oft haben wir in der Dokumentation nachgeschlagen, um ein bestimmtes unerwartetes Verhalten zu erklären, und haben dabei eine neue kleine Schattierung entdeckt, die sich dann auf einem Schaubild oder einem Zeitungsartikel wiederfand.
Selbst Larry gibt zu, gelegentlich einmal die Dokumentation zu konsultieren.
In der FAQ für die deutschsprachige Perl-CGI-Newsgruppe von Volker Rattel finden Sie eine Liste mit Texteditoren, die zum Programmieren mit Perl geeignet sind. Sie finden diese Liste entweder als regelmäßiges Posting in der Newsgruppe de.comp.lang.perl.cgi oder im Web unter der Adresse http://www.worldmusic.de/perl/dclpc-faq.html.
Warum soll es besser sein, keine Dateiendung zu benutzen? Stellen Sie sich vor, Sie haben ein Programm geschrieben, das Ihnen die Spielstände Ihres Fußballteams ausgibt. Sie haben allen Ihren Freunden erzählt, das Programm heiße fussball.plx. Eines Tages entscheiden Sie sich, das Programm in C neu zu schreiben. Soll es nun immer noch den gleichen Namen tragen, der darauf hinweist, daß das Programm immer noch in Perl ist? Oder sagen Sie jedem, daß das Programm jetzt einen neuen Namen trägt? (Aber bitte nicht fussball.c!) Die Antwort lautet, es geht Ihre Freunde einfach nichts an, in welcher Sprache es geschrieben ist, wenn sie das Programm nur benutzen. Daher sollten Sie es von Anfang an einfach fussball nennen.
Kurz gesagt: Es verhindert, daß Ihre Shell ein anderes Programm (oder ein Shell-Kommando) mit dem gleichen Namen ausführt. Ein häufiger Anfängerfehler besteht darin, das erste Programm »test« zu nennen. Auf vielen Systemen gibt es nämlich schon ein Programm mit dem Namen »test«, das die Anfänger dann statt ihres Programms ausführen würden.
Es gibt jedoch eine Reihe von Möglichkeiten, diese zu imitieren. Hinweise hierzu finden Sie in der FAQ. Auf diese können Sie auf den meisten Systemen mit dem Kommando perldoc perlfaq zugreifen.
Jedenfalls die meisten modernen. Der »sh-bang«-Mechanismus wurde irgendwann Mitte der achtziger Jahre eingeführt, und das ist selbst auf der sehr langen Unix-Zeitleiste schon ziemlich alt.
Wie üblich ist an der Sache etwas mehr dran, als wir hier sagen. Es sollte aber für alle, außer für die technisch fortgeschrittenen Leute, völlig ausreichen; und die wissen sowieso darüber Bescheid.
Es sei denn, Zeile zwei enthält Anweisungen, die bereits zur Kompilierungszeit ausgeführt werden, wie z.B. einen BEGIN-Block oder einen Aufruf von use.
Verweisen Sie Ihren örtlichen Spezialisten für eine mögliche Lösung auf http://perl.apache.org.
Auf vielen (vermutlich den meisten) Systemen, auf denen Sie ein Perl-Programm kompilieren wollen, wird die Perl-Binärdatei (das Programm, das Ihre Perl-Programme ausführt) ständig von irgendeinem Prozeß benutzt. Das bedeutet, sie befindet sich immer im Arbeitsspeicher. Ein »kompiliertes Perl«-Programm braucht seine Zeit, um in den Arbeitsspeicher geladen zu werden. Handelt es sich um ein kleines Programm, wird beim Kompilieren direkt vor der Ausführung in etwa die gleiche Zeit benötigt, die auch eine vorkompilierte ausführbare Datei zum Laden bräuchte. Handelt es sich um ein großes Programm, nimmt die Kompilierung vermutlich ohnehin nur einen kleinen Teil der Laufzeit ein.
Ist perldoc auf Ihrem System nicht verfügbar, heißt das wahrscheinlich, daß Ihr System nicht über eine Kommandozeile verfügt. Dadurch kann Perl Kommandos (wie perldoc), die in Backticks oder eine Pipe geöffnet werden (mehr dazu in Kapitel 14, Prozeßverwaltung), nicht ausführen. In diesem Falle sollten Sie die Übungen, die perldoc benutzen, einfach überspringen.
| |
|
|
|
|