nicht angemeldet
Da Du bereits den Perl-Interpreter über den PATH adressieren kannst, würde ich "#!perl" in die 1. Zeile des Skripts schreiben. Bei mir daheim (Windows95) funktioniert das mit Apache 1.3.2.
Der Perl-Interpreter ist bei mir auch in 'PATH' adressiert. Und ich habe auch in allen Scripts jetzt '#!perl' stehen. Nur bekomme ich dann wieder mal einen neuen Eintrag in der error.log statt der Ausgabe auf dem Bildschirm (da kommt HTTP 500 :-( ):
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.)
[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.)
Man kann halt auch mehr als einen Fehler machen ...
Ich will mein Perl-Skript durch einen Doppelklick in den Editor laden können, um schnell etwas darin ändern zu können. Das kann ich aber nicht, wenn der Webserver mich dazu zwingt, *.pl mit dem Perl-Interpreter zu verbinden.
Willkommen im Club! Denn das funzt meist sowieso nicht, weil das Konsolenfenster gleich wieder weg ist.
Klar - aber WebSite zwingt mich dazu, das so zu machen! Sonst führt er kein CGI-Skript aus.
Zum Perl-Ausführen habe ich jeweils eine Batch-Datei mit zwei Kommandos drin:
perl <scriptname>
pause
*Die* klappt nicht sofort zu ...
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.
Und ich werde mir auch dreimal überlegen, ob ich irgend ein Programm an meine sorgsam kommentierte Webserver-Konfiguration ranlasse - nachher sind womöglich die Kommentare weg und ich darf raten, was ich mir letztes Jahr dabei gedacht hatte!
Nein, an meine httpd.conf kommt nur emacs und sonst nichts. Dokumentation ist lebenswichtig, und die beste Dokumentation ist diejenige, die man findet, wenn man sie braucht - also direkt dort, wo ich Anweisungen hinschreiben muß.
Außerdem habe ich dort als letzte Zeile
"include conf/<servername>.conf"
stehen - das heißt, ich habe nicht etwa die Originaldatei umgeschrieben, sondern meine Änderungen fein säuberlich in einer eigenen Datei, welche als letzte eingelesen wird und vorherige Definitionen (fast) sauber überdeckt. (Ich glaube, ein oder zwei Sachen muß man im Original ändern, weil die Installations-Defaults nicht funktionieren können - die findet man aber mit "apachectl test" sofort.)
Das erleichtert eine Migration auf einen neue Apache-Version ungeheuer - ich muß praktisch nur die include-Zeile wieder einfügen und fertig ist die Laube.
Ich kann sogar beliebig geschachtelte INCLUDES verwenden, also in meiner eigenen Konfigurations-Teildatei selbst wiederum Einträge nach Projekten etc. zerlegen, so daß ich auf einen Blick sehe, wer was wofür haben wollte. Das kann ich per graphischer Oberfläche nicht so schön - ebenso wie ich eine graphische Oberfläche nicht "mal schnell" mit grep nach "CGI" durchsuchen kann usw.