Premature End of Script header

[Joerg Peschke]

Hallo,
YEHOVA. Ich weiß, "Premature end of Script headers" ist ein Klassiker, aber irgendwie stehe ich wirklich auf dem Schlauch.

Nachdem ein CGI-Skript, was auf einem Server tadellos funktionierte nun auf einem anderen Server plötzlich nicht mehr will, habe ich folgendes probiert:

1.) Hello World-Script ("test.pl")gebastelt, um mit dem weiterzutesten. Um Windows/UNIX-Kodierungsfehler auszuschliessen, habe ich das direkt auf dem neuen Webserver im vi gebaut. Inhalt:

#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print header;
print "Hallo Welt";

Dies läuft ebenfalls nicht.

2.) /usr/bin/perl mit "which perl" überprüft
3.) Perl-Script mit "perl -c" überprüft ("Syntax OK")
4.) Perl-Skript mit "./test.pl" gestarted auf der Kommandozeile, funktioniert
5.) Ausführrechte bestehen im Moment für alle User (755)
6.) Eigentümer ist "wwwrun" (user in der httpd.conf)
6.) in httpd.conf geguckt, da ist ".pl" als cgi-Skript-Header eingetragen.

Bin ich bescheuert? Woran kann das noch liegen?

Danke für alle Antworten,

Jörg

[steckl]

Hi,

#!/usr/bin/perl

#!/usr/bin/perl -w
use strict;
use CGI;

print header;
print "Hallo Welt";

Bin ich bescheuert? Woran kann das noch liegen?

Kann es sein, dass da nur ein use CGI; fehlt?
Was mich aber wundert ist, dass keine Fehlermeldung kommt, wenn du das Script so ausführst. Die Funktion header müsste ja dann eigentlich unbekannt sein.
Auf jedenfall solltest du noch "-w" und "use strict;" eingauen.

mfG,
steckl

[Joerg Peschke]

Hallo,

Kann es sein, dass da nur ein use CGI; fehlt?
Auf jedenfall solltest du noch "-w" und "use strict;" eingauen.

Stimmt "header" war verkehrt, mit "-w" kommt ein "print on unopened file handle".

Das war aber auch nicht der Fehler :(

Trotzdem danke.

Jörg

[Patrick Andrieu]

Hallo Joerg!

Stimmt "header" war verkehrt, mit "-w" kommt ein "print on unopened file handle".

Ja, steckl war etwas minimalistisch und hätte Dir auch sagen sollen, wozu die Option "w" gut ist. Mit dieser Option wird die Ausgabe sogenannter Warnungen eingeschaltet, die sehr nützlich sind, und zwar so, dass sie unverzichtbar sind. Auf "-w" in der Shebang-Zeile kannst Du aber verzichten, wenn Du stattdessen:

use warnings;

angibst.

mit "-w" kommt ein "print on unopened file handle".

War die Ausgabe eher nicht ähnlich dieser:

Unquoted string "header" may clash with future reserved word at - line 3.
Name "main::header" used only once: possible typo at - line 3.
print() on unopened filehandle header at - line 3.

?

Alle diese drei Zeilen geben Dir genug Informationen, um herauszufinden, was da schief geht:

Erste Warnung: unquoted string "header"

bedeutet, Perl versteht Dein »print header;« als der evtl. Versuch, die Zeichenkette header auszugeben, die leider nicht in Anführungszeichen steht, und somit verdächtigt wird, mit evtl. reservierten Perl-eigene Namen in Konflikt zu treten... -> Du wirst gewarnt (darüber informiert)

Zweite Warnung: Name "main::header" used only once: possible typo

bedeutet: Sollte header doch eine Variable oder eine Funktion sein, kommt der Name nur einmal vor, es könnte ein Tippfehler sein -> Du wirst gewarnt (darüber informiert)

Dritte Warnung: print() on unopend filehandle

bedeutet: Perl meint, Du gibst print (das ja eine Perl-eigene _Funktion_ ist, deswegen werden die Klammer mit angegeben) einen FileHandle, evtl. um in eine Datei zu schreiben, die Du vorher aber nirgends (mit diesem Filehandle) nicht geöffnet hast.

Und wie kann man das ganze »zum Laufen« bringen?

1.
use strict;
use warnings;
use CGI qw(header);
print header();
print "Hallo Welt";

oder 2.
use strict;
use warnings;
use CGI;
print CGI::header();
print "Hallo Welt";

oder 3. ohne CGI-Modul, dann wie von buzzer vorgeschlagen:
use strict;
use warnings;
print "Content-type: text/html\n\n";
print "Hallo Welt";

Wobei von den dreien Version 1. vorzuziehen ist. Nur fragst Du Dich, warum funktionieren diese Beispiele und Deins nicht?

Weil header nichts ist, womit Perl was anfangen kann. Wenn Du auf Funktionen des CGI-Moduls zurückgreifen willst, die Dir beispielsweise die Angabe des lästigen Content-type ersparen, oder andere, musst Du diese laden (importieren):

use CGI qw(header); oder use CGI "header"; oder einfacher: use CGI qw(:standard); <- da werden alle Standardfunktionen importiert.

Um den Rückgabewert einer _Funktion_ auszugeben, muss Perl auch wissen, dass Du das tun willst:

print header(); oder print CGI::header();
Die Klammer dürfen hier nicht fehlen!

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Hm, hätte auf den Namen achten sollen (Joerg Peschke,  [e-mail])

Dann erzähle ich Dir sicher nichts Neues ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Joerg Peschke]

Hallo,

Hm, hätte auf den Namen achten sollen (Joerg Peschke,  [e-mail])

Dann erzähle ich Dir sicher nichts Neues ;)

Das passt schon, bisweilen bin ich
programmiertechnisch so dermaßen auf dem Holzweg, dass man mir diese Email-Adresse sperren müsste :)

In so einem Fall kann man mir dann gar nicht genug mit dem zaunpfahl winken *g*

Viele Grüße,
Jörg

[Jörg Peschke]

Hallo Patrick,

Ja, steckl war etwas minimalistisch und hätte Dir auch sagen sollen, wozu die Option "w" gut ist. Mit dieser Option wird die Ausgabe sogenannter Warnungen eingeschaltet, die sehr nützlich sind, und zwar so, dass sie unverzichtbar sind.

Joah, normalerweise haben auch alle meine (größeren) Perl-Scripts ein "use strict;" und "-w" in der Shebang-Zeile - machts Debuggen doch deutlich einfacher, und den Code automatisch lesbar, weil man nicht so völlig wild scripten kann.
Bei besagtem Test-Programm hatte ichs im Eifer der Gefechts nur übersehen.

War die Ausgabe eher nicht ähnlich dieser:

Unquoted string "header" may clash with future reserved word at - line 3.
Name "main::header" used only once: possible typo at - line 3.
print() on unopened filehandle header at - line 3.

Ähm nee :)
Aber ich glaub, das hängt auch ein bisschen von der Perl-Version ab, die auf der Kiste läuft, oder? Hab noch gar nicht geguckt welche das ist.

Das Problem ist eigentlich auch weniger dieses header-Teil, das hatte ich urpsürnglich gar nicht drin - aber ohne das gehts auch nicht:

Ich hatte auf meiner wilden Suche nach dem Premature-End-Of-Script-Problem irgendwo ein Beispiel-Programm mit dieser Anweisung gefunden - und dachte/hoffte, dass "print header;" irgendeine abgefahrene reservierte Anweisung zum Flushen von STDOUT bzw. abschalten des IO-Buffers ist, die ich noch nicht kenne, und die mein Problem löst (analog wie $| = 1;)

Aus euren Antworten schliesse ich aber, dass das vermeintliche "Musterprogramm" keins ist, weil "print header;" kein neuer Perl-Kniff sondern vermutlich schlichtweg ein Tippfehler aus "print CGI::header()"; o.ä. ist :)

Trotzdem vielen Dank für Deinen ausführlichen Tipp.

Meine heisseste Spur ist im Moment, dass der Apache schlichtweg noch nicht richtig für Perl konfiguriert ist (mod_perl war z.b. nicht geladen, das habe ich inzwischen behoben).
Naja, morgen ist auch noch ein Arbeitstag :)

Danke jedenfalls und viele Grüße,

Jörg

[steckl]

Hi,

Ja, steckl war etwas minimalistisch und hätte Dir auch sagen sollen, wozu die Option "w" gut ist.

Ich bin davon ausgegangen, dass Jörg schon etwas Grundwissen mitbringt und das nur nicht in dem Script stehen hatte, weil es sich nur um einen Test handelt.

Um den Rückgabewert einer _Funktion_ auszugeben, muss Perl auch wissen, dass Du das tun willst:

print header(); oder print CGI::header();
Die Klammer dürfen hier nicht fehlen!

Die Klammern sind in Perl optional. Wenn überhaupt bekommst du eine Warnung, wenn du sie weglässt.

Folgendes Script erzeugt bei mir nichtmal eine Warnung:

  
#!c:\apachefriends\xampp\xampp\perl\bin\perl.exe -w  
  
use warnings;  
use strict;  
use CGI qw(:cgi);  
  
print header;  

mfG,
steckl

[Patrick Andrieu]

Hallo steckl!

Ich bin davon ausgegangen, dass Jörg schon etwas Grundwissen mitbringt

Ich zuerst nicht ;)

Erst nachdem mir der Name doch noch bekannt vorkam...

Die Klammern sind in Perl optional. Wenn überhaupt bekommst du eine Warnung, wenn du sie weglässt.

Ja, habe ich mittlerweile auch verstanden (es gab ja letztens einen Thread diesbezüglich, den ich mir wieder reingezogen habe). Nur muss die Funktion deklariert werden - oder, wenn aus einem Modul, importiert werden, was Du ja in Deinem Beispiel tust.

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo steckl,

Kann es sein, dass da nur ein use CGI; fehlt?

Nein. Dummerweise sind so ziemlich alle anderen in diesem Thread darauf eingestiegen.

Selbstverständlich ist es sogar mehr als angeraten, bei umfangreicheren HTML-Ausgaben das CGI-Modul zu benutzen. Aber _hier_ gehts ja nur darum, nachzuschauen, ob Perl überhaupt genutzt werden kann. Und _dazu_ muß man das CGI-Modul nicht zwingend bemühen - schaden würe es allerdings auch nix.

Aber wenn man schon das CGI-Modul bemüht, funktioniert dann
 print header;
 print "Hallo Welt";
sowieso nicht mehr.

Struppi und ich haben uns große Mühe gegeben, das CGI-Modul wenigstens ansatzweise zu erläutern. Im aktuell veröffentlichten SELFHTML-Kapitel ist der entsprechende Abschnitt zwar noch nicht wirklich aktuell, reicht aber für die hier angesprochene Frage noch aus.

Auf jedenfall solltest du noch "-w" und "use strict;" eingauen.

Das genügt eben nicht.

Grüße aus Berlin

Christoph S.

[Siechfred]

Nein. Dummerweise sind so ziemlich alle anderen in diesem Thread darauf eingestiegen.

Natürlich fehlt wenigstens use CGI, denn eine Funktion "header" gibt's in Perl nicht.

Selbstverständlich ist es sogar mehr als angeraten, bei umfangreicheren HTML-Ausgaben das CGI-Modul zu benutzen. Aber _hier_ gehts ja nur darum, nachzuschauen, ob Perl überhaupt genutzt werden kann. Und _dazu_ muß man das CGI-Modul nicht zwingend bemühen - schaden würe es allerdings auch nix.

Christoph, bitte kurz nachdenken, was "header" für eine Funktion sein könnte und welches allseits bekannte und beliebte Modul diese wohl anbietet.

Aber wenn man schon das CGI-Modul bemüht, funktioniert dann
print header;
print "Hallo Welt";
sowieso nicht mehr.

Warum nicht? Begründung?

Auf jedenfall solltest du noch "-w" und "use strict;" eingauen.
Das genügt eben nicht.

Das wurde nicht behauptet.

Siechfred

[Buzzer]

Hallo,

wenn ein

#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "Hallo Welt";

nicht läuft, vorausgesetzt die shebang stimmt, was bei Dir der Fall ist, stimmt was mit dem Server nicht.

Btw.,
print "Content-type: text/plain\n\n";

Try
print "Content-Type: text/plain\n\n";

t => T

Möglicherweise hat der Apache ein Problem damit (hatte ich auch schon).

Viele Grüße vom Buzzer

[DeWitt]

Btw.,
print "Content-type: text/plain\n\n";

Try
print "Content-Type: text/plain\n\n";

Interessant, ich habe mich immer (laut http://de.selfhtml.org/perl/intro.htm#testen@title=SELFHTML) an die erste Variante "Content-type" gehalten, aber im RFC2616 steht "Content-Type".
Gibt es tatsächlich Umgebungen, die bei "Content-type" meckern?

Ciao,
David //aka DeWitt

[Buzzer]

Hallo,

Btw.,
print "Content-type: text/plain\n\n";

Try
print "Content-Type: text/plain\n\n";

Interessant, ich habe mich immer (laut http://de.selfhtml.org/perl/intro.htm#testen@title=SELFHTML) an die erste Variante "Content-type" gehalten, aber im RFC2616 steht "Content-Type".
Gibt es tatsächlich Umgebungen, die bei "Content-type" meckern?

So ists. Es gibt Apache'ies, die sowohl bei
Content-type

als auch bei
Content-Type

meckern. Das habe ich schon erlebt auf verschiedenen Appliances (z.B. Cobalt Raq's).

Viele Grüße!

[Siechfred]

Gibt es tatsächlich Umgebungen, die bei "Content-type" meckern?

Nach meiner Erfahrung gibt es dann Probleme, wenn kein Headerparsing stattfindet. So machte der Apache 1.3 seinerzeit Probleme bei NPH-Scripts, wenn ich die Groß-/Kleinschreibung laut RFC 2616 nicht beachtet hatte, siehe Content-Type.

Siechfred

[Gunnar Bittersmann]

Hello out there!

[…] wenn ich die Groß-/Kleinschreibung laut RFC 2616 nicht beachtet hatte, siehe Content-Type.

???

RFC 2616 sagt: “Field names are case-insensitive.” [RFC2616 §4.2]

See ya up the road,
Gunnar

[Siechfred]

[…] wenn ich die Groß-/Kleinschreibung laut RFC 2616 nicht beachtet hatte, siehe Content-Type.
RFC 2616 sagt: “Field names are case-insensitive.” [RFC2616 §4.2]

Ups, diese Aussage hatte ich gesucht, aber nicht gefunden. Danke für die Korrektur.

Siechfred

[Jörg Peschke]

Hallo,
Danke für Euren Hinweis. Daran hatte ich auch schon gedacht, und beide Schreibweisen ausprobiert. Auch mal mit/ohne Leerzeichen zwischen "Content-Type:" und "text/plain" hatte ich probiert.

Naja, trotzdem danke. Inzwischen habe ich die Vermutung, dass vielleicht mod_perl nicht richtig/sauber läuft, oder sowas.

Bastel ich morgen nochmal dran rum.

Viele Grüße,
Jörg

[Christoph Schnauß]

hallo Joerg,

ich habe mir jetzt mit Interesse den ganzen Thread durchgelesen und zwischendurch Patrick mal einen Pluspunkt wegen "hilfreich" verteilt - trotzdem haben alle, die sich hier geäußert haben, etwas Entscheidendes übersehen:

#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print header;
print "Hallo Welt";
Dies läuft ebenfalls nicht.

Doch, es "läuft", und ausschlaggebend ist, daß du es so aufrufen kannst:

4.) Perl-Skript mit "./test.pl" gestarted auf der Kommandozeile, funktioniert

Aber welche Schlußfolgerung hast du daraus gezogen bzw. welche Schlußfolgerung(en) haben die bisher Antwortenden gezogen?
Wenn du auf der Konsole was ausgeben willst, ist "text/plain" kein Problem - aber im Browser ist es eins. Mein Vorschlag:

#!/usr/bin/perl -w  
print "Content-type: text/html\n\n";  
print "hallo Welt!";

Das Ding funktioniert bei mir bereits seit Jahren - und tut es auch mit den allerneuesten Perl-Versionen. Zum Testen, ob Perl überhaupt mitspielt, ist das sehr gut geeignet - meiner Erfahrung nach.

Grüße aus Berlin

Christoph S.

[steckl]

Hi,

Wenn du auf der Konsole was ausgeben willst, ist "text/plain" kein Problem - aber im Browser ist es eins.

Hab das gerade ausprobiert. Dem IE 6 ist es ganz egal ob es sich um "text/plain" oder "text/html" handelt und der FF 2 macht nur Unterschiede wie er die Ausgabe Anzeigt (parst?).

mfG,
steckl

[Christoph Schnauß]

hallo steckl,

Dem IE 6 ist es ganz egal ob es sich um "text/plain" oder "text/html" handelt

Unterscheide doch bitte, was dein Browser zugeschickt bekommt, und was der Server macht.

und der FF 2 macht nur Unterschiede wie er die Ausgabe Anzeigt (parst?).

Dein "Anzeigegerät" (Browser) _kann_ nur etwas anzeigen, was ihm vom Server geschickt wird. Die Angabe
 print "Content-type: text/html\n\n";
erreicht deinen Browser gar nicht. Die gilt für den Perl-Interpreter, der liefert das an den Server aus, und erst der liefert dann irgendwas an deinen Browser.

Grüße aus Berlin

Christoph S.

[Struppi]

und der FF 2 macht nur Unterschiede wie er die Ausgabe Anzeigt (parst?).

Dein "Anzeigegerät" (Browser) _kann_ nur etwas anzeigen, was ihm vom Server geschickt wird. Die Angabe
print "Content-type: text/html\n\n";
erreicht deinen Browser gar nicht.

Quatsch, genau das erreicht den Browser zuerst und dann weiß er was er mit den folgenden Daten machen muss. Bei text/html versucht er das folgende als HTML umzusetzten und bei text/plain sollte er den reinen Text anzeigen, was aber der IE nicht tut.

Die IEs reagieren sowieso auf den content/type eher so wie sie wollen, aber das ist ein anderes Thema.

Struppi.

[Christoph Schnauß]

hallo Struppi,

Quatsch

Keineswegs.

bei text/plain sollte er den reinen Text anzeigen, was aber der IE nicht tut.

Das ist allerdings vermutlich der Kern des Anzeigeproblems bei Jörg.

Die IEs reagieren sowieso auf den content/type eher so wie sie wollen, aber das ist ein anderes Thema.

Och ... Na gut, dann kriegen wir das später.

Grüße aus Berlin

Christoph S.

[Struppi]

Quatsch

Keineswegs.

Diese Aussage von dir:

Die Angabe print "Content-type: text/html\n\n"; erreicht deinen Browser gar nicht

ist Quatsch.

Struppi.

[Christoph Schnauß]

hallo Struppi,

Quatsch
Keineswegs.
Diese Aussage von dir:
Die Angabe print "Content-type: text/html\n\n"; erreicht deinen Browser gar nicht
ist Quatsch.

Ha!

Jetzt spielen wir ein bißchen Ping-Pong. Du sagst immer "ist Quatsch", und ich sage immer "nö, quatsch doch nicht". Wer gibt dann als erster auf oder schlägt ins Aus?

;-)

Grüße aus Berlin

Christoph S.

[Siechfred]

Jetzt spielen wir ein bißchen Ping-Pong. Du sagst immer "ist Quatsch", und ich sage immer "nö, quatsch doch nicht". Wer gibt dann als erster auf oder schlägt ins Aus?

Es würde genügen, wenn du Struppi Recht gäbest, denn er hat Recht :)

Siechfred

[Siechfred]

Dem IE 6 ist es ganz egal ob es sich um "text/plain" oder "text/html" handelt
Unterscheide doch bitte, was dein Browser zugeschickt bekommt, und was der Server macht.

Dieser Hinweis ist hier nicht relevant.

Die Angabe
print "Content-type: text/html\n\n";
erreicht deinen Browser gar nicht. Die gilt für den Perl-Interpreter, der liefert das an den Server aus, und erst der liefert dann irgendwas an deinen Browser.

Sorry, aber das kann so nicht stehen bleiben. Ich gehe davon aus, dass dir HTTP bekannt ist. Ich gehe weiterhin davon aus, das dir bekannt ist, wie ein Webserver die Ausgaben eines serverseitigen Programmes im CGI-Kontext abarbeitet.

Deshalb für's Archiv:

Der Browser sendet einen HTTP-Request an den Server. Dieser wird via CGI-Schnittstelle "verteilt" (es werden insbesondere Umgebungsvariablen gesetzt und die Ein- und Ausgabekanäle STDIN und STDOUT bereitgestellt). Das Perl-Script nimmt den aufbereiteten Request entgegen und verarbeitet ihn.

Nach erfolgter Verarbeitung muss das Script zwingend eine HTTP-Response an den anfragenden Client schicken. Dieser Response ist wie folgt aufgebaut:

1. Statuszeile, bestehend aus HTTP-Version, HTTP-Statuscode als 3-stellige Zahl und die dazu gehörende Erklärung gemäß RFC 2616, Sect. 10. Darauf folgt ein "Zeilenumbruch" (CRLF).

2. Response-Header, bestehend aus verschiedenen Header-Zeilen, einige davon zwingend, andere optional. Welche Header zwingend und welche optional sind, beschreibt wie bereits genannt RFC 2616. Darauf folgen zwei Zeilenumbrüche.

3. Der Body der Antwort, welcher die eigentlichen Daten enthält.

Um nun allen Beteiligten das Leben zu erleichtern, bieten die meisten Webserver so genanntes Header-Parsing an. Das bedeutet, dass man in einem Script lediglich bestimmte Header-Angaben machen muss, nämlich solche, die eine Software nicht eindeutig und ohne den Request zu verfälschen ergänzen kann. Alles andere ergänzt der Webserver automagisch, u.a. auch die HTTP-Statuszeile. Daneben bringt er vom Script gelieferte Headerzeilen in die RFC-gerechte Form. Dann hängt er die Daten an und versendet den bereinigten und ergänzten Request an den Client.

Um das mal am konkreten Beispiel zu demonstrieren:

#! /usr/bin/perl -w  
use strict;  
  
print "content-type:text/html\n\n";  
print 'Hier ich bin!';

Der Header verstößt formal gegen RFC 2616 (Groß-/Kleinschreibung, kein Leerzeichen zwischen ':' und 'text/html'). Jetzt schauen wir mal, was im Zuge des Header-Parsings im Apache herauskommt:

HTTP/1.0 200 OK  
Connection: close  
Date: Thu, 20 Sep 2007 07:45:25 GMT  
Server: Apache  
Content-Type: text/html  
  
Hier ich bin!

Alles Bestens! Und genau diese HTTP-Response kommt auch im Client an, und nicht "irgendwas". Falls du das so gemeint haben solltest (wovon ich ausgehe), dann wäre es schön, wenn du es das nächste Mal auch unmissverständlich zum Ausdruck brächtest :)

Siechfred

[Christoph Schnauß]

hi,

grmpf, ich habe eben vergessen, ein Beispiel anzugeben. Genau für so einen Fall würde ich übrigens die Möglichkeit einer nachträglichen Editierung des eigenen postings und seiner Veränderung begrüßen ...

Probiere es einfach mal mit meinem Testscript aus. Da gibt es natürlich das Problem, daß du mir soweit vertrauen mußt, daß ich für dieses kleine Scriptchen wirklich nur den Code

#!/usr/bin/perl -w  
print "Content-type: text/html\n\n";  
print "hallo Welt!";

eingesetzt habe - aber wer wäre ich denn, wenn ich an einer solchen Stelle versuchen wollte, dich zu hintergehen und einen anderen Code zu benutzen ;-)

Grüße aus Berlin

Christoph S.

[Patrick Andrieu]

Hallo Christoph!

Danke für den hilfreich bei meiner vorschnellen Antwort an Jörg, der sich sicher besser auskennt als ich.

Probiere es einfach mal mit meinem Testscript

#!/usr/bin/perl -w

print "Content-type: text/html\n\n";
print "hallo Welt!";

>   
  
Schön und gut, nur beantwortet es nicht (oder geht nicht auf steckls Hinweis ein):  
  

> Dem IE 6 ist es ganz egal ob es sich um "text/plain" oder "text/html" handelt und der FF 2 macht nur Unterschiede wie er die Ausgabe Anzeigt (parst?).  
  
Denn text/plain war nie ein Problem. Statt dessen wollen die IEs immer diesen Script downloaden:  
  
~~~perl
  
#!/usr/bin/perl -w  
  
use strict;  
use warnings;  
use diagnostics;  
use CGI::Carp qw(fatalsToBrowser);  
  
my $type ="text/plain";  
  
print "Content-type: $type\n\n";  
  
my $dcr = $ENV{'DOCUMENT_ROOT'};  
  
chdir "$dcr/logs" or die "BLUBBDIR: $!";  
open (LOG, "gzip -dc <access.log.34.gz|") or die "BLUBBFILE: $!";  
while (<LOG>) {print if m!fdashuUksj1s8!;}  

Wüßte ich auch gerne warum...

daß du mir soweit vertrauen mußt, daß ich für dieses kleine Scriptchen wirklich nur den Code

Nun ja, bist ja der Alterspräsident und bist bisher durch Schlimmeres aufgefallen, als durch Hackerversuche ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo Patrick,

bist ja der Alterspräsident und bist bisher durch Schlimmeres aufgefallen, als durch Hackerversuche ;)

Du machst mich sprachlos. Ich als von dir bestätigter Alterspräsident sollte noch Schlimmeres angestellt haben?

Au weia. Ich stelle sofort den Antrag, alle meine postings, die in den letzten zehn Jahren "noch schlimmer" waren, aus dem Archiv zu entfernen.

Grüße aus Berlin

Christoph S.