nicht angemeldet
guten Abend,
Ich habe mal ne Frage zu den CGI/Perl- Compiler.
ähm ... nein, hast du nicht. Es geht dir nämlich nicht um einen "Compiler", sondern um den "Interpreter" [1], weil PERL-Scripts eben nicht kompiliert, sondern ausgelesen und Zeile für Zeile abgearbeitet, also "interpretiert" werden. Wenn du dich auf CGI beziehst, so ist der Vorgang bei der "Scriptauswertung" in groben Zügen so: auf dem Server liegt ein Perl-Script - in der Regel in einem cgi-bin-Verzeichnis, das mehrere Befehle enthält und entweder die Dateinamensendung *.pl oder *.cgi trägt (es sind auch andere möglich). Dieses Script soll jetzt von einem beliebigen Besucher einer Webseite aufgerufen werden - was in der Webseite selbst zum Beispiel mit <form action="htttp://servername/cgi-bin/scriptname.pl"> geschehen kann. Daraufhin sagt der Server dem anhand der "shebang" [2] identifizierten Perl-Interpreter (der perl.exe zum Beispiel) "ey, da hat mir jetzt so nen Dödel gesagt, daß du ihm mal erklären sollst, was in folgendem Script steht" und schickt die Befehle des Scripts an den Interpreter. Der Interpreter wiederum antwortet dem Server sofort: "ey, Server, in dem Script steht, daß du niemanden als Dödel bezeichnen sollst", woraufhin der Server sich übers "Netz" an den Benutzer der Webseite wendet und dem mitteilt: "du bist kein Dödel".
Wie kann der CGI/Perl- Compiler mit Hilfe von Modulen wie z.B. LWP:Simple oder so, Dateien von einen fremden Server laden?
Der Server übergibt an den Stellen im Script, an denen Module angesprochen werden sollen, den entsprechenden Befehl, den er nicht selber versteht, eben an die Interpreter-Module, deren Pfad ihm vom Script mitgeteilt werden. Wenn nun zum Beispiel mit "use" ein benutzerdefinertes Modul angesprochen werden soll, kriegt der Interpreter den Hinweis, den zugehörigen Befehl mit Hilfe dieses Moduls auszuführen, das in der Regel irgendwo auf dem Server selbst liegt, entweder in den Unterverzeichnissen des Interpreters selbst oder in den Verzeichnissen, die der Benutzer angelegt hat.
Du kannst nun in ein Perl-Script mit dem Befehl "require" auch die Aufforderung einbauen, ein zweites Perl-Script, das dann auch auf einem anderen Server liegen kann, einzubinden und abzuarbeiten. Dann wird während der Abarbeitung des Scripts auf dem ersten Server dieser andere Server angerufen, bei dem wird die ganze Prozedur "Kumpel, reich mal rüber, was in deinem Script über Dödel steht" durchgeführt und als Antwort wird an den ersten Interpreter zurückgegeben: "das ist ein newbie, aber du darfst ihm das nicht sagen und jetzt verklicker ihm das" - also antwortet der Interpreter jetzt dem ersten Server : "die Frage kommt von einem newbie, aber du darfst ihn nicht Dödel nennen, alles klar, Kumpel?" und der erste Server antwortet dem Seitenbsucher: "hallo du da draußen, wenn ich dürfte, würde ich dich Dödel nennen, aber ich darf nicht, alles klar, Kumpel?"
Wenn ich mich nicht Täusche, dann sind ja die Module im Grunde nichts anderes als Scripte die, die selben Befehle benutzen, oder?
Module sind in der Regel nichts anderes als (teilweise sehr umfangreiche) Perl-Scripte, die bestimmte vorgefertigte Subroutinen zur Verfügung stellen. Damit brauchst du solche Subroutinen nicht nochmal selbst in dein Script zu schreiben.
Ein bekanntes Beispiel:
wenn du CGI-Funktionen benutzen möchtest, ist es nötig, den Datenstrom, der aus deinen Eingabefeldern an den Server übertragen wird, zu parsen. Das kannst du machen, indem du solche Abschnitte in dein Perl-Script stellst:
sub parse_form {
local($name,$value);
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ s/\0//g;
$value =~ s/<!--(.|\n)*-->//g;
$FORM{$name} = $value;
}
}
aber das ist ein bissel umständlich, und vielleicht unterläuft dir beim Schreiben der RegExpressions ein kleiner Fehler. Also schreibst du lieber gleich
use CGI qw/param/;
use CGI::Carp qw/fatalsToBrowser/;
womit dieser Krimskrams zuverlässig vom Modul erledigt wird, in dem diese Subroutinen auch drinstehen, nur wesentlich genauer.
Ist die Befehlsliste in SELFHtml für CGI/Perl die komplette Befehlesliste
nein, so weit ich das sehen kann. Es sind allerdings die "Standard"-Befehle sehr gut dargestellt - ein erheblicher Qualitätszugewinn gegenüber SELFHTML 7. Eine "komplette" Liste ist utopisch und nicht möglich, weil du dir jederzeit deine eigenen "Befehle" mit selbstgeschriebenen Modulen basteln kannst.
Einen ersten Eindruck über die Arbeit mit Modulen kann dir http://www.tekromancer.com/perl/12.html vermitteln.
=======================================
[1) Der Unterschied zwischen "Compiler" und "Interpreter" ist bisweilen schwer zu verstehen. Bei PERL (und ähnlich bei PHP) handelt es sich um eine Scriptsprache, die so funktioniert, daß ein "Interpreter" (auf Windows-Rechnern die perl.exe) das Script zur Laufzeit ausliest und Zeile für Zeile abarbeitet. Das Script selbst ist in einer Form abgefaßt und deponiert, die sowohl der Entwickler wie auch der Interpreter "lesen" können.
Bei Sprachen wie C/C++ oder JAVA wird ein anderer Mechanismus genutzt: Das Script kann zwar der Entwickler lesen und verstehen, aber keine Maschine. Es muß, ehe es ausgeführt werden kann, in "maschinenlesbare Form" umgewandelt, eben "kompiliert" werden, das heißt, es kommt ein Entwicklungsschritt während des Erstellens hinzu. Das Ergebnis ist für den Entwickler (den Menschen) in der Regel nicht mehr lesbar, aber der Rechner kann was damit anfangen.
[2]
über die Rolle der "shebang" haben wir hier im Forum gelegentlich diskutiert ... Das ist die allererste Zeiel in einem Script, die dem Server sagt, an wen er jetzt das, was kommt, weiterreichen soll:
#!usr/local/perl
zum Beispiel kann der entsprechende Pfad auf einem UNIX/LINUX-Rechner sein
#!C:/Perl/bin/perl.exe
kann der Pfad auf einem Windows-Rechner sein.
Die "shebang" kommt aus der Welt der Shell-Script-Programmierung. Auf einem UNIX-System wird eine Shellscript zum Beispiel oft mit
#!/bin/sh
angewiesen, das Programm "sh" im Verzeichnis /bin zu benutzen
Grüße aus Berlin
Christoph S.