----------------------------------------------------------------------
Worum geht es in de.comp.lang.perl.cgi?
---------------------------------------------------------------------- ^
In de.comp.lang.perl.cgi geht es um den Einsatz der
Programmiersprache Perl in CGI-Scripten.
Aus der Charta:
Diese Gruppe dient als Forum für die Erstellung, Installation
und Anpassung vorhandener CGI-Programme, die in der
Programmiersprache Perl realisiert sind. Komplette Listings
sind im Gegensatz zu Programmauszügen (weniger als 75 Zeilen)
unerwünscht. Ausdrücklich sei betont, daß sich die Gruppe
nicht nur an Unix-Administratoren richtet, auch Benutzer
anderer Systeme sind willkommen.
Für allgemeine Fragen zu Perl gibt es die Newsgroup
----------------------------------------------------------------------
Was sollte man _vor_ dem Posten in de.comp.lang.perl.cgi beachten?
---------------------------------------------------------------------- ^
Bevor man postet sollte man wenigstens ein paar
Dokumentationen und FAQs gelesen haben.
----------------------------------------------------------------------
Woher bekommt man die aktuelle Perl-Version?
---------------------------------------------------------------------- ^
Die aktuelle Perl-Version lautet 5.8.7. Im Einsatz auf
Produktions-Plattformen ist dies auch die stabile und getestete
Version.
Perl-Versionen für alle Betriebssysteme findet man unter
CGI.pm übernimmt viele Funktionen für das Erstellen und Senden von
CGI-Formularen und erleichtert den Umgang mit Standard-Routinen.
Für den Bereich der Client-Programmierung und der Erstellung von
Web-Applikationen bietet das Modul libwww-perl (auch LWP genannt)
eine Fülle von Optionen. Das Modul kann man unter
----------------------------------------------------------------------
Wo gibt es Dokumentation über Perl und CGI?
---------------------------------------------------------------------- ^
Viele Fragen lassen sich bereits durch das Lesen der
hervorragenden Dokumentation lösen, die bei der Distribution von
Perl dabei ist.
Um auf die Dokumentation zuzugreifen, gibt man in der
Kommandozeile seines jeweiligen Betriebssystems folgendes ein:
perldoc perltoc
Dieser Befehl zeigt einem das Inhaltsverzeichnis der
Dokumentation.
Mit 'perldoc perlfaq' erhält man das Inhaltsverzeichnis des FAQs.
Schließlich läßt sich mit perldoc CGI.pm ein FAQ zum Modul CGI.pm
anzeigen.
Hilfe zum Programm perldoc kann man mit 'perldoc perldoc'
aufrufen. Bei einigen Distributionen findet sich die Hilfe auch im
HTML-Format.
Für Dokumentation zu CGI-Modulen bieten folgende Quellen die
Möglichkeit zur Nachforschung:
----------------------------------------------------------------------
Wo findet man weiterführende Literatur?
---------------------------------------------------------------------- ^
Es gibt zahllose Bücher zum Thema Perl. Einen Überblick über
deutschsprachige Bücher kann man sich in dem Dokument von Jörgen
W. Lang verschaffen:
----------------------------------------------------------------------
Wo findet man Perl-Scripte und Module?
---------------------------------------------------------------------- ^
----------------------------------------------------------------------
Was für einen Editor gibt es für Perl?
---------------------------------------------------------------------- ^
Immer wieder taucht die Frage auf, mit welchem Editor man
Perl-Scripte schreiben kann. Prinzipiell kann man seine Scripte
mit jedem Texteditor schreiben; wer allerdings Syntax-Highlighting
und andere Features wünscht, sollte sich mal die folgenden
Editoren anschauen.
Die Liste erhebt keinen Anspruch auf Vollständigkeit:
######################################################################
FEHLERBEHANDLUNG UND -VERMEIDUNG
######################################################################
----------------------------------------------------------------------
Bei der Ausführung meines Scriptes tauchen Fehler auf.
---------------------------------------------------------------------- ^
Perl bietet bereits eine Reihe von Möglichkeiten, die das
Fehleraufspüren erheblich erleichtern.
Jedes Programm sollte folgendermaßen beginnen:
#!/usr/bin/perl
use warnings;
use diagnostics;
use strict;
'use warnings' schaltet die Fehlermeldungen des Interpreters ein.
Durch 'use diagnostics' werden diese Meldungen zudem detailierter.
Das 'use strict' sorgt penibel dafür, daß z. B. Variablen korrekt
initialisiert werden. Manchmal ist das strict allerdings so
ungnädig und bricht das Programm ab, daß man sich unbedingt die
zugehörige Dokumentation mit 'perldoc strict' ansehen sollte, um
nicht zu verzweifeln.
Kann man die Ausführung seines Scripts lediglich via Web
beobachten, so sorgt ein
use CGI::Carp qw(fatalsToBrowser);
dafür, daß alle Fehlermeldungen an den Browser übertragen werden.
Mit dem Aufruf 'perl -d mein_prog.pl' schaltet man den internen
Debugger ein, der sehr nützliche Fehler-Informationen bereithält.
Eine weitere Quelle für verdeckte Fehler sind ungetestete
Rückgabewerte von Funktionsaufrufen. Man sollte daher immer
testen, ob bspw. die open() Funktion korrekt abgeschlossen wurde:
open (my $file, '<', './etc/passwd')
or die "Fehler beim Öffnen von /etc/passwd. Grund: $!\n";
----------------------------------------------------------------------
Mein Script läuft nicht bei meinem Provider.
---------------------------------------------------------------------- ^
Grundsätzlich stellt sich die Frage, ob der Provider überhaupt die
Ausführung von CGI-Scripten sowie Perl erlaubt. Das kann nur
direkt mit dem jeweiligen Provider geklärt werden.
Wenn das geklärt ist, muß das Script noch an die richtige Stelle
kopiert werden. Es ist üblich, daß dazu ein spezielles Verzeichnis
auf dem Server existiert das cgi-bin heißt. Dorthin muß das
Script kopiert werden.
Gemeinhin wird das Script mit der Dateiendung .cgi oder .pl
versehen. Dies kann jedoch von Provider zu Provider (bzw.
Webserver zu Webserver) variieren. Für den Anfang ist man mit der
Endung .cgi gut beraten.
Nachdem nun das Script an der richtigen Stelle sitzt, muß es noch
ausführbar gemacht werden.
Generell sollte man sein Script zunächst "offline" testen, damit
man sichergehen kann, daß es überhaupt läuft.
Ein wichtiger Punkt bei der Übertragung seines Scriptes per FTP
ist die Verwendung des ASCII-Modus. Bei WS_FTP kann man diesen am
unteren Bildschirmrand einstellen.
Hinweis:
Bei der Einstellung <auto> erkennt WS_FTP anhand der
Dateiendung, ob es sich um eine ASCII- oder Binärdatei
handelt. Wenn die Endungen .pl bzw. .cgi nicht eingestellt
worden sind, überträgt WS_FTP die Dateien binär!
----------------------------------------------------------------------
Was hat es mit CHMOD 755 auf sich?
---------------------------------------------------------------------- ^
Damit ein CGI-Script durch den Webserver ausgeführt werden
kann, muß es "weltweite" Ausführrechte besitzen. Mit dem Befehl
chmod unter UNIX erreicht man genau dieses.
Wer nur Zugang via FTP-Programm hat, kann trotzdem ein chmod
durchführen. Programme wie z. B. WS_FTP lassen dies auch zu. Dazu
selektiert man die entsprechende Datei und rechtsklickt darauf.
Nachdem man den Befehl chmod angewählt hat, erscheint eine
ähnliche Maske wie unten abgebildet. Dort müssen folgende Felder
selektiert werden:
Wenn man mit einer Gruppe von Benutzern zu tun hat, bietet sich
noch ein chmod 0775 an, was für die Gruppe Schreibrechte
bedeutet. Es mag sicherlich noch andere mögliche Kombinationen
geben, doch hat sich ein chmod 0755 in der Praxis für den Anfang
gut bewährt. :-)
Siehe auch: chmod(1), perldoc -f chmod
----------------------------------------------------------------------
Was bedeuten die Fehlernummern bei einem Servererror?
---------------------------------------------------------------------- ^
Bei der Ausführung eines Scriptes erscheint eine Server- bzw.
Client-Fehlermeldung. Anhand der Codezahl lassen sich eventuelle
Fehler schneller eingrenzen.
Siehe auch: Dokumentation des jeweiligen Webservers
----------------------------------------------------------------------
Was bedeutet ein "Internal Server Error"?
---------------------------------------------------------------------- ^
Bei dem Versuch ein Script auszuführen, erscheint eine Seite mit
einem "Internal Server Error".
Grundsätzlich bedeutet dies, daß der Server ein Problem bei der
Verarbeitung oder Ausgabe des Scriptes hatte. Dieser Fehler taucht
z. B. dann auf, wenn ein Script falsch geschriebene Anweisungen
enthält und der Perl-Interpreter die Ausführung abbricht.
Detailierte Informationen zur Fehlerursache finden sich in den
Logfiles des Webservers -- genauer gesagt in den Error-Logfiles.
Falls auf die Log-Dateien nicht zugegriffen werden kann, so können
mit Hilfe des folgenden Scriptes nähere Informationen
herausgefunden werden.
Hinweis:
Dies funktioniert nur bei dem Apache Webserver.
Einbinden in die .htaccess Datei:
ErrorDocument 500 /cgi-bin/internal-error.pl
Das Script internal-error.pl sieht folgendermaßen aus:
#!/usr/bin/perl -w
print "Content-type: text/plain\r\n\r\n";
print "Internal Server Error: $ENV{REDIRECT_ERROR_NOTES}\n";
Beim nächsten Internal Server Error würden dann Informationen zur
Fehlerursache ausgegeben werden.
Häufige Fehlerursachen sind falsch geschriebene Header am
Scriptanfang (Content-type), die den berühmten "Premature end of
script headers"-Fehler hervorrufen.
Siehe auch: Dokumentation des jeweiligen Webservers
----------------------------------------------------------------------
Was ist der Unterschied zwischen einem Win32- und einem UNIX-Server?
---------------------------------------------------------------------- ^
Grundsätzlich müssen Perl-Scripte auf einem UNIX-Server mit
folgender Zeile beginnen:
#!/usr/bin/perl
Bei einigen UNIXen auch
#!/usr/local/bin/perl
genauen Aufschluß gibt notfalls der Administrator.
Auf Win2000/WinXP Systemen mit Apache muss die Lage des
Perl-Interpreters als Windows-Dateipfad angegeben werden. Z. B.:
#!c:\perl\perl.exe
Zwar wird in Windows eine Systemvariable gesetzt, die mit Dateien
der Endung *.pl verknüpft ist, auf obiger Konfiguration führt dies
dennoch zu einem Error "Couldn't spawn child process" wenn ein
Script via CGI ausgeführt wird. Auf anderen Konfigurationen (mit
anderem Webserver als Apache) ist die Angabe des
Perlinterpreterpfades nicht nötig (kann aber auch nicht schaden).
Unter UNIX spielt die Groß- und Kleinschreibung ein Rolle. Ein
use Strict;
ist nicht gleich einem
use strict;
Gerade wer von Win32 auf UNIX umstellt, sollte seine Scripte auf
korrekte Schreibweise überprüfen.
Ohne auf die Vor- und Nachteile des jeweiligen Betriebssystems
einzugehen kann man sagen, daß unter UNIX standardmäßig mehr Tools
und Eigenschaften wie sendmail, cron oder File-Locking zur
Verfügung stehen, die unter Windows nicht vorhanden sind oder aber
nachinstalliert werden müssen.
Wer welches Betriebssystem besser findet, ist letzenendes
Glaubenssache. Beide eignen sich für die Verwendung von Perl und
CGI.
Siehe auch: perldoc perlport, perldoc perlwin32
----------------------------------------------------------------------
Wo finde ich einen Provider für meine CGI-Scripte?
---------------------------------------------------------------------- ^
----------------------------------------------------------------------
Wie konfiguriere ich den Webserver, um Perl und CGI Scripte ausführen
zu können?
---------------------------------------------------------------------- ^
Da eine vertiefende Beantwortung dieser Frage an dieser Stelle
nicht geleistet werden kann, folgen ein paar grundsätzliche Dinge:
- Der Webserver muß installiert und konfiguriert sein
- Perl muß installiert sein
- Der Webserver muß die Dateiendung .cgi oder .pl mit der
Ausführung von Perl verbinden
- Gemeinhin wird die Ausführung von CGI-Scripten auf ein
Verzeichnis namens 'cgi-bin' begrenzt
- Die Scripte müssen ausführbar und via Web aufrufbar sein
Zu bemerken bleibt, daß CGI-Scripte generell nicht von einem
bestimmten Aufrufpfad ausgehen sollten. Dieses ist im CGI-
Standard auch nicht festgelegt.
----------------------------------------------------------------------
Welche Sicherheitsaspekte sollte man beim Einsatz von CGI-Scripten
bedenken?
---------------------------------------------------------------------- ^
Mittels einer ausreichend großen Datei ist es möglich, bei einer
POST Operation oder eines Datei-Uploads den betreffenden Server
lahmzulegen. Dies wird auch als "Denial of Service"-Attacke
bezeichnet.
Unter der Verwendung von CGI.pm lassen sich präventiv folgende
Einstellungen treffen:
$CGI::POST_MAX gibt die in Bytes zulässige Größe für POST-
Operationen an.
Sicherhaltshalber sollten Speicher, CPU-Zeit und Plattenplatz
für CGI-Scripte serverseitig limitiert werden.
Desweiteren sollte der Parameter '-T' in Betracht gezogen werden,
der Perl veranlaßt im sogenannten taint mode zu starten. In diesem
Modus werden spezielle Sicherheitsüberprüfungen durchgeführt.
Vielfach befinden sich Scripte aus Matt's Script Archive (MSA) im
Einsatz in Produktionsumgebungen. Diese Scripte sind gerade bei
unerfahrenen Anwendern sehr beliebt, weil sie sehr schnell zu
installieren sind. Leider sind diese Script _äußerst_ unsicher
und stellen ein großes Sicherheitsrisiko dar! Unter
----------------------------------------------------------------------
Wie kann man Dateien vor mehrfachen Zugriff schützen?
---------------------------------------------------------------------- ^
Um Dateien vor gemeinsamen Zugriff zu schützen, kann man ein
sogenanntes File-Locking durchführen.
Beispiel:
#!/usr/bin/perl
use warnings;
use strict;
use Fcntl ':flock';
my $my_file = '/tmp/foo.txt';
open (my $file, '<', $my_file)
or die "Kann $my_file nicht öffnen: $!";
flock ($file, LOCK_SH)
or die "Kann $my_file nicht sperren: $!";
# Irgend etwas mit my_file anstellen...
close ($file)
or die "Kann $my_file nicht schließen: $!";
Die Funktion flock() erwartet zum einen das zu sperrende
Filehandle und zum anderen eine Zahl, die die Art des zu
verwendenden Lockings angibt. Verwendet man das Modul Fcntl, kann
man die Zahlen durch unten genannte Platzhalter ersetzen. Die
Werte haben folgende Bedeutung:
Das Schließen des zuvor gesperrten Filehandles hebt das Lock
auf.
Hinweis:
Betriebssysteme wie Windows (3.11, 95, 98) besitzen kein
File-Locking!
Grundsätzlich sollte man eine Datei mittels LOCK_SH sperren, wenn
man aus ihr nur lesen möchte. Bei Schreiboperationen sollte man
das LOCK_EX verwenden.
######################################################################
VERSENDEN VON MAIL
######################################################################
----------------------------------------------------------------------
Wie prüfe ich die Echtheit einer E-Mail-Adresse?
---------------------------------------------------------------------- ^
Der einzige Weg zur reinen Gewissheit ist dieser:
- Du erhältst eine Mail-Adresse, die Du prüfen möchtest
- Du schreibst an diese Adresse folgende Nachricht:
Hallo,
wenn dieser Account echt ist, dann beantworte doch
bitte folgende Frage: "Wer hat den 'Herr der Ringe'
geschrieben?"
- Wenn Du eine Antwort erhältst (und diese J. R. R. Tolkien
lautet) dann ist davon auszugehen, daß der Account echt ist.
Fazit: Man kann zwar überprüfen, ob die E-Mail-Adresse aus
erlaubten Zeichen besteht und es läßt sich auch überprüfen, ob
eine Mail an diesen Account bounced, jedoch sagt dies noch nichts
über die Echtheit des Accounts aus.
Ein gutes Tool zum Überprüfen von Adressen stammt von Tom
Christiansen und nennt sich addrcheck. Es findet sich unter
----------------------------------------------------------------------
Wie versende ich Mail?
---------------------------------------------------------------------- ^
Man kann den MTA (Mail Transport Agent) direkt aufrufen:
open(SENDMAIL, '|/usr/lib/sendmail -oi -t -f foo@example.com -odq')
or die "Kein fork fuer sendmail: $!\n";
print SENDMAIL <<'EOF';
From: Foo <foo@example.com>
To: Bar <bar@example.com>
Subject: Wichtig!
Inhalt der Nachricht, wobei die oben stehende Leerzeile
von Bedeutung ist.
EOF
close(SENDMAIL)
or warn "Sendmail nicht korrekt beendet";
Alternativ dazu kann man das CPAN Modul Mail::Mailer benutzen.
Wenn die Empfängeradresse aus einer Variablen stammt, so sollte
man unbedingt sicherstellen, dass sie keine unerlaubten Zeichen
enthält.
----------------------------------------------------------------------
Wie versende ich Mail mit Attachments?
---------------------------------------------------------------------- ^
Mit dem CPAN Modul MIME::Lite. Es erlaubt z. B. das Versenden von
angehängten Bildern oder multipart messages.
Beispiel:
#!/usr/bin/perl
use warnings;
use strict;
use MIME::Lite;
my $msg = MIME::Lite->new(
From => 'foo@example.com',
To => 'bar@example.com',
Subject => 'Look at this',
Type => 'image/gif',
Encoding => 'base64',
Path => 'foo_and_bar.gif',
);
$msg->send();
Siehe auch: perldoc MIME::Lite
----------------------------------------------------------------------
Gibt es ein sendmail für Windows?
---------------------------------------------------------------------- ^
Sendmail ist ein UNIX-Programm und nicht für Windows-Systeme
verfügbar. Alternativ dazu kann man das Programm Blat benutzen:
######################################################################
VERSCHIEDENE INFORMATIONEN
######################################################################
----------------------------------------------------------------------
Welche Methoden gibt es, um ein Perl- / CGI-Script via HTML
aufzurufen?
---------------------------------------------------------------------- ^
Zunächst sollte folgender Sachverhalt Erwähnung finden:
CGI ist nicht Perl!
Das Common Gateway Interface (CGI) ist lediglich eine
Schnittstelle zwischen dem WWW-Server und dem aufgerufenen
Programm. CGI-Programme können in beliebigen Programmiersprachen
gehalten sein. Perl ist eine davon. Eine ausführliche Beschreibung
der CGI-Schnittstelle gibt es unter
Für einen Aufruf über eine HTML-Seite gibt es grundsätzlich
mehrere Wege:
(1) GET-Methode
Alle übergebenen Parameter werden in der URL kodiert und dem
Web-Server übermittelt. Die Parameter können dann aus der
Umgebungsvariable QUERY_STRING gelesen werden. Die Variable
REQUEST_METHOD wird in diesem Fall auf GET gesetzt.
Beispiel:
<a href="./my_script.cgi">Click</a>
Dies erzeugt einen Textlink, der das Script my_script.cgi
aufruft.
Um dem Script Parameter zu übergeben, können diese angehängt
werden.
Die Parameter 'id1' und 'id2' lassen sich dann z. B. mit CGI.pm
abfragen:
#!/usr/bin/perl
use warnings;
use strict;
use CGI;
my $query = new CGI;
my $para1 = $query->param('id1');
my $para2 = $query->param('id2');
(2) POST-Methode
Im Gegensatz zur GET-Methode werden die Daten nicht über die URL
kodiert, sondern an den HTTP-Header angehängt. Das hat zur Folge,
daß die Parameter nicht in der URL-Zeile des Browsers zu sehen
sind. Die Variable REQUEST_METHOD wird auf POST gesetzt und die
Länge der Daten steht in CONTENT_LENGTH.
Die Parameter lassen sich mit CGI.pm genauso auslesen wie oben
beschrieben.
Hinweis:
Bei der Verwendung von CGI.pm muß man sich nicht um die
verwendete REQUEST_METHOD kümmern; CGI.pm entscheidet selbst
und stellt die Parameter in param() zur Verfügung.
(3) Server-Side Includes (SSI)
SSI sind Tags, die direkt im HTML-Quellcode eingetragen werden.
Dadurch wird das Perl-Script beim Laden der Seite ausgeführt und
kann somit zum Erzeugen dynamischer Inhalte verwendet werden
(z. B. Web-Counter oder Banner).
Um via SSI ein Script in eine HTML-Seite einzubinden, kann man
folgende Methode benutzen:
Das Leerzeichen vor dem '-->' ist wichtig! Fehlt es, kommt es zu
Fehlermeldungen des Webservers und das Script wird nicht
ausgeführt. Weiterhin ist zu beachten, daß der Webserver für den
Einsatz von SSI entsprechend konfiguriert ist. Einige Server
werden durch die Dateiendung '.shtml' anstatt '.html' zur
Verarbeitung von SSI veranlaßt. Zudem lassen sich per SSI keine
Scripte auf fremden Rechnern ausführen.
----------------------------------------------------------------------
Wie kann man einen URL von einem Perl-Skript holen lassen?
---------------------------------------------------------------------- ^
Um eine HTML-Datei von einem anderen Server anzusprechen,
verwendet man das Modul LWP::Simple aus dem CPAN.
die "Fehler beim Holen von $URL: $!" unless defined $page;
Siehe auch: perldoc LWP::Simple
----------------------------------------------------------------------
Wie extrahiert man URLs aus einer HTML-Datei?
---------------------------------------------------------------------- ^
Man verwendet das Modul HTML::LinkExtor aus dem CPAN.
----------------------------------------------------------------------
Wie generiert man einen gültigen HTML 4.x Header?
---------------------------------------------------------------------- ^
Der HTML-Standard 4.x sieht vor, dem Document-Header eine
Definition des verwendeten Charsets hinzuzufügen. Dies geschieht
mittels
----------------------------------------------------------------------
Wie kann man die IP-Adresse eines Clients ermitteln?
---------------------------------------------------------------------- ^
In der Theorie steht die IP-Adresse eines Clients in der
Environment Variable $ENV{'REMOTE_ADDR'}. Allerdings verwenden
viele User heutzutage einen Proxyserver. Somit bekommt man
lediglich die Adresse des Proxyservers heraus.
Eine Ausnahme bildet der Fall, wenn der Proxy-Server selbst eine
Variable setzt. Dann findet sich die IP-Adresse gemeinhin unter
$ENV{'HTTP_CLIENT_IP'}.
----------------------------------------------------------------------
Wie implementiere ich ein Session-Tracking?
---------------------------------------------------------------------- ^
Da HTTP mit nicht-persistenten Verbindungen arbeitet (nach einem
Request ist die Verbindung zwischen Webserver und Client
unterbrochen) ist ein Session-Tracking nicht
trivial. Grundsätzlich kann man folgende Methoden in Betracht
ziehen:
- Cookies
Man setzt auf dem Client ein Cookie. Wenn der Client
diesen ablehnt oder der Empfang ausgeschaltet ist,
funktioniert diese Methode nicht.
- HTML Hidden-Fields
Man übergibt der HTML-Seite ein sogenanntes Hidden Field,
in dem man Informationen über die Session
speichert. Vorrausetzung dafür ist aber, daß das
CGI-Script bei jeder Aktion des Clients aufgerufen wird,
um dessen Session ID nicht zu verlieren.
----------------------------------------------------------------------
Kontakt
---------------------------------------------------------------------- ^
Kritik, Anregungen und Ergänzungen sind immer willkommen. Schreibt
eine Mail an Volker Rattel <vrattel@noarch.net> mit dem Betreff
"dclpc-faq".
Die aktuelle Version dieses Dokumentes ist unter folgender Adresse
zu erreichen:
----------------------------------------------------------------------
History
---------------------------------------------------------------------- ^
Dieses FAQ wurde inspiriert durch das von Jörgen W. Lang
geschriebene mini-FAQ "[de.comp.lang.perl.misc] Erst lesen - dann
posten" zu finden unter
und löst in der *.cgi Gruppe das "mini-FAQ" ab. Das "mini-FAQ"
wird natürlich weiterhin in der *.misc Gruppe gepostet.
Hintergrund:
Durch die Aufsplittung der alten Gruppe de.comp.lang.perl in
die beiden Untergruppen *.misc und *.cgi eignen sich die
behandelten Themen für zwei FAQs.
Mein Dank geht an folgende Personen für Ihre Unterstützung und
Mithilfe:
- Jörgen W. Lang - Stefan Hornburg - Boris Piwinger
- Martin H. Sluka - Philip Newton - Michael Gerth
- Wolfgang Wiese - Udo Held - Thomas Berger
- Martin Vorländer - Björn Höhrmann - Christian Lackas
- Florian Weingarten - Thomas Neumann - Tobias Zimpel
- Martin Ackermann - Thoren Johne - Tina Müller
- Peter Kraume - Georg Rehfeld - Joachim Zobel
- Tobias Wolter - Voelki - Ulrich Nehls
- Frank Wiegand - Daniel Liebig
----------------------------------------------------------------------
Autor und Copyright
---------------------------------------------------------------------- ^
Copyright (C) 1999 - 2005 by Volker Rattel <vrattel@noarch.net>
Alle Rechte vorbehalten.
Die hier aufgeführten Antworten sind nach bestem Wissen und
Gewissen zusammengestellt worden. In jedem Fall gilt natürlich
TMTOWTDI (There's More Than One Way To Do It).
Der Autor übernimmt keinerlei Haftung für die Richtigkeit der hier
beschriebenen Methoden. Die Verwendung der Informationen aus
diesem Dokument geschieht auf eigene Verantwortung.
