Florian Auer: Problem mit Apache :-)

Beitrag lesen

Florian, wenn Du die mehrfach angegebenen korrekten Lösungstips ignorierst, dann wirst Du Dich selbst unnnötig quälen ... und die Leser gleich mit.

Ich ignoriere sie doch gar nicht. Ich schaue alle 30 min hier rein, nur um eine Lösung für das Problem zu bekommen. Nur leider verstehe ich die Lösungen einfach nicht.

Ob diese Anweisung ausgewertet wird, das hängt nicht vom Betriebssystem ab, sondern vom Webserver.
Apache wertet diese Angabe aus - egal ob unter UNIX oder unter Win32.

Das weiß ich auch! mit dem Befehl start()

Zu Perl-CGI unter Apache unter DOS ist auch irgendwie keine wirklich gute Info zu finden,

Reden wir von DOS oder von Win32? Bitte zukünftig präzise Angaben ...

Win32. DOS ist albern. Mit Lynx in einem 24x80-Zeichen-Raster durch das WWW. ;-)

Falls es dafür eine bessere Lösung gibt,
würde mich die auch brennend interessieren.

Selbstverständlich.
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 :-( ):

[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

Und genau das hasse ich.
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.

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.

MfG FLorian Auer