nicht angemeldet
Aber wir sind uns einig, daß wir jetzt einen Schritt weiter sind, wo der Perl-Interpreter endlich gefunden wird?
Als nächstes werden wir wohl das Skript debuggen müssen. Also: URL des CGI-Aufrufs per Browser bestimmen, der passenden Environment-Variablen zuweisen, Perl-Skript ohne Webserver in simulierter CGI-Umgebung ausführen und sehen, was passiert. (Siehe ausführliche Beschreibung in meiner E-Mail.)
In diesem Teil komm' ich jetzt nicht mit. Wie meinst du das: URL des CGI-Aufrufs; Perl-Skript ohne Webserver in simulierter CGI-Umgebung ausführen; in deiner eMail stand nichts dergleichen. Environment-Variablen sind keine gesetzt bzw werden nicht benötigt.
[Tue Jul 20 17:56:46 1999] [error] [client 127.0.0.1] malformed header from script. Bad header=19: c:/eigene dateien/internet/cncstation.neu/cgi-bin/counter.pl
Immerhin ranzt er jetzt nicht mehr ab, weil er das Skript überhaupt nicht ausführen kann, sondern er jammert nun darüber, daß ihm das Format der erzeugten Ausgabe nicht paßt.
Womöglich ist das jetzt kein korrekter http-Header, sondern eine Fehlermeldung, weil das Perl-Skript binär auf den Server transportiert wurde oder was auch immer - deshalb: siehe oben. (Vorher "perl -c counter.pl" kann auch helfen.)
»»
Wie soll ich die auf einen Server übertragen? Ist doch localhost!
Man kann halt auch mehr als einen Fehler machen ...
leider!
Zum Perl-Ausführen habe ich jeweils eine Batch-Datei mit zwei Kommandos drin:
perl <scriptname>
pause
*Die* klappt nicht sofort zu ...
hab' ich unter Xitami auch versucht. Ist aber nie funktioniert. Aber das ist nicht das Thema
Apache ist "friedlich" und ändert nichts am Betriebssystem herum, bloß um seine CGI-Skripts ausführen zu können.
Zum Glück! Aber die Konfiguraionsdateien-Lösung ist auch nicht gerade das beste. Apache 2.0 soll ja einen Browserbasierten Einstellungs-Dialog haben.Das kann wohl schon Apache 1.3 - ich habe es aber noch nicht versucht.
»»
WO????
MfG Florian Auer