nicht angemeldet
Skript läuft nicht - internal server error
Hallo Forum,
ich habe folgendes Problem:
beim Aufrufen eines CGI-Skripts bekomme ich den Fehler 500: internal server error. Dabei habe ich - wie ich meine - alles richtig gemacht:
- Editor: edit.exe (DOS)
- upload in ASCII-Format
- chmod 755
- korrekte Pfadangaben (#!/usr/local/bin/perl)
- simples Skript ( z.b. print "Hallo";) läuft auch nicht
- Server (Unix) unterstützt cgi, Skript liegt im Verzeichnis "cgi-local"
Ich habe auch versucht, das Programm "perlcheck" von John Cokos zu benutzen, scheitere aber an den Angaben im Kopf bzgl. des "base_path", jedenfalls kriege ich es nicht zum Laufen...
Bin dankbar für jede Hilfe...
Heiko
-
Hallo Heiko,
einige potentielle Fehlerquellen hast Du ja ausgeschlossen lt. Deinem Bericht weitere evtl. Fehler kannst Du hier finden: http://cgi.faq-zentrale.de.
Wenn PerlCheck schon nicht läuft ist die Sache recht gediegen, man kann dann evtl. noch mal in der error_log-Datei nachschauen, ob ein verwertbarer Eintrag vorliegt.
Alternativ mit Telnet auf den Server gehen und "perl scriptName.pl" aufrufen, um zu sehen, an welcher Zeile das Script abbricht.
Ggf. auch den chmod Status des cgi-local Verzeichnisses prüfen (müsste 755 sein).
Vielleicht hilfts ...
Gruß aus Hamburg
Knud Schiffmann-
Hallo Heiko,
einige potentielle Fehlerquellen hast Du ja ausgeschlossen lt. Deinem Bericht weitere evtl. Fehler kannst Du hier finden: http://cgi.faq-zentrale.de.
Wenn PerlCheck schon nicht läuft ist die Sache recht gediegen, man kann dann evtl. noch mal in der error_log-Datei nachschauen, ob ein verwertbarer Eintrag vorliegt.
Alternativ mit Telnet auf den Server gehen und "perl scriptName.pl" aufrufen, um zu sehen, an welcher Zeile das Script abbricht.
Ggf. auch den chmod Status des cgi-local Verzeichnisses prüfen (müsste 755 sein).
Vielleicht hilfts ...
Gruß aus Hamburg
Knud SchiffmannHi Knud,
danke erstmal für deine Antwort. Perlcheck habe ich mittlerweile zum Laufen gekriegt, ich bekomme aber nur den Hinweis "Syntax ok". Das Skript läuft aber trotzdem nicht, selbst wenn es nur aus der Zeile print "Hallo"; besteht.
Mit Telnet habe ich noch nie gearbeitet, was muss ich tun?
Was mir noch aufgefallen ist: die Änderung der Zugriffsrechte ( chmod 755 mittels WS-FTP) wird zwar positiv bestätigt, wenn ich dann die Datei überprüfe, wird nur 753 angezeigt. Könnte es damit zu tun haben? Mit dem cgi-local Verzeichnis dasselbe: ich ändere in 755, wirksam wird aber nur 753. Trotzdem läuft aber das Perlcheck-Skript. Es ist zum Mäusekriegen...
Heiko
-
einige potentielle Fehlerquellen hast Du ja ausgeschlossen lt. Deinem Bericht weitere evtl. Fehler kannst Du hier finden: http://cgi.faq-zentrale.de.
oder hier: http://www.teamone.de/selfaktuell/schroepl03.htm.
Gefühlsmäßig würde ich ja auf den angeblich korrekten Perl-Pfad tippen ...Was mir noch aufgefallen ist: die Änderung der Zugriffsrechte ( chmod 755 mittels WS-FTP) wird zwar positiv bestätigt, wenn ich dann die Datei überprüfe, wird nur 753 angezeigt. Könnte es damit zu tun haben? Mit dem cgi-local Verzeichnis dasselbe: ich ändere in 755, wirksam wird aber nur 753. Trotzdem läuft aber das Perlcheck-Skript. Es ist zum Mäusekriegen...
Zunächst mal: Wenn Du in der Lage bist, selbst chmod-Kommandos auszuführen, dann hast Du vermutlich einen Zugang zum System, mit dem Du alles machen kannst, wofür Dir telnet empfohlen wurde.
Aber dann: 753 ist verdächtig wenig. (Und außerdem Unfug: Das erlaubt allen Leuten, die Datei zu schreiben, nicht aber sie zu lesen!)
Wenn der Webserver wie üblich so ein "other"-Benutzer ist, dann kann er in der Tat Dein Skript nicht lesen. Das aber müßte er, weil der Perl-Interpreter es ja interpretieren muß. (Bei einem binary wäre chmod 111 genug zum Ausführen.)Daß Deine chmod-Kommandos verändert werden, wundert mich. Es gibt zwar umask-Einstellungen für Benutzerkennungen, aber nach meiner Erfahrung wirken die bloß dann, wenn Du unzureichende Angaben machst (beispielsweise gar keine, als einfach eine Datei zum Schreiben öffnest oder so).
Was passiert denn, wenn Du (unter telnet ... ;-) das Kommando "umask" ausführst?Allgemein: Die besten Informationen über Dein Problem stehen nun mal in der errorlog-Datei des Webservers. Kommst Du da irgendwie ran?
-
einige potentielle Fehlerquellen hast Du ja ausgeschlossen lt. Deinem Bericht weitere evtl. Fehler kannst Du hier finden: http://cgi.faq-zentrale.de.
oder hier: http://www.teamone.de/selfaktuell/schroepl03.htm.
Gefühlsmäßig würde ich ja auf den angeblich korrekten Perl-Pfad tippen ...Pfad war ok, ich hatte einfach die Zeile
print "Content-type: text/html\n\n";
vergessen, damit habe ich mich wohl als newbie geoutet, sorry.
Was mir noch aufgefallen ist: die Änderung der Zugriffsrechte ( chmod 755 mittels WS-FTP) wird zwar positiv bestätigt, wenn ich dann die Datei überprüfe, wird nur 753 angezeigt. Könnte es damit zu tun haben? Mit dem cgi-local Verzeichnis dasselbe: ich ändere in 755, wirksam wird aber nur 753. Trotzdem läuft aber das Perlcheck-Skript. Es ist zum Mäusekriegen...
Zunächst mal: Wenn Du in der Lage bist, selbst chmod-Kommandos auszuführen, dann hast Du vermutlich einen Zugang zum System, mit dem Du alles machen kannst, wofür Dir telnet empfohlen wurde.
Aber dann: 753 ist verdächtig wenig. (Und außerdem Unfug: Das erlaubt allen Leuten, die Datei zu schreiben, nicht aber sie zu lesen!)
Wenn der Webserver wie üblich so ein "other"-Benutzer ist, dann kann er in der Tat Dein Skript nicht lesen. Das aber müßte er, weil der Perl-Interpreter es ja interpretieren muß. (Bei einem binary wäre chmod 111 genug zum Ausführen.)Daß Deine chmod-Kommandos verändert werden, wundert mich. Es gibt zwar umask-Einstellungen für Benutzerkennungen, aber nach meiner Erfahrung wirken die bloß dann, wenn Du unzureichende Angaben machst (beispielsweise gar keine, als einfach eine Datei zum Schreiben öffnest oder so).
Auch hier mein (Wissens-)Fehler: ich habe mich auf die check-Boxen von WS_FTP verlassen, die zeigen aber gar nicht die aktuellen Zugriffsrechte an...
Was passiert denn, wenn Du (unter telnet ... ;-) das Kommando "umask" ausführst?
Immerhin habe ich jetzt auch gelernt, mit telnet umzugehen :-)
Allgemein: Die besten Informationen über Dein Problem stehen nun mal in der errorlog-Datei des Webservers. Kommst Du da irgendwie ran?
War gottseidank nicht mehr nötig, dafür stehe ich jetzt vor folgendem Problem: sobald ich in ein Formular-Skript die Variable
$Empfaenger= "hlinn@ctcinternet.cl";
einfüge, taucht wieder der bekannte 500-Fehler auf. Es liegt an dem @-Zeichen, wie ich schon gemerkt habe (wenn ich das Zeichen herausnehme, läuft‚s). Gibt es eine andere Möglichkeit?
Danke
Heiko
-
einfüge, taucht wieder der bekannte 500-Fehler auf. Es liegt an dem @-Zeichen, wie ich schon gemerkt habe (wenn ich das Zeichen herausnehme, läuft‚s). Gibt es eine andere Möglichkeit?
Zeichen, die etwas besonderes bedeuten können (@ ist das Zeichen, das arrays kennzeichnet - Du könntest ja eine Variable in Deinen ""-quoted String einfügen wollen) müssen für ihre 'eigentliche' Bedeutung escaped werden (durch das Zeichen \ davor).
Alternativ tut es in Deinem Fall auch, " durch ' zu ersetzen (innerhalb '...' werden keine Ersetzungen vorgenommen).
-
einfüge, taucht wieder der bekannte 500-Fehler auf. Es liegt an dem @-Zeichen, wie ich schon gemerkt habe (wenn ich das Zeichen herausnehme, läuft‚s). Gibt es eine andere Möglichkeit?
Zeichen, die etwas besonderes bedeuten können (@ ist das Zeichen, das arrays kennzeichnet - Du könntest ja eine Variable in Deinen ""-quoted String einfügen wollen) müssen für ihre 'eigentliche' Bedeutung escaped werden (durch das Zeichen \ davor).
Alternativ tut es in Deinem Fall auch, " durch ' zu ersetzen (innerhalb '...' werden keine Ersetzungen vorgenommen).
Genial, es funktioniert, fühle mich schon fast wie ein richtiger Programmierer. Besten Dank...
Heiko
-
-
-
-
-
-
- Editor: edit.exe (DOS)
Das ist vielleicht Dein Problem. DOS speichert einen Zeilenumbruch als 0Ah 0Dh. UNIX will allerdings nur ein 0Ah. Einige HTML-Editoren (z.B. HTML-Edit von Ulli Meybohm, http://www.meybohm.de) haben zum Speichern im UNIX-Format extra einen Menüpunkt.
Gruß Frank
-
Das ist vielleicht Dein Problem.
Nicht, wenn er ASCII-Upload gemacht hat.
-
Nicht, wenn er ASCII-Upload gemacht hat.
Der FTP-Client des Windows-Commanders bietet z.B. als Transfermodus "auto", "binär", "text" an und entfernt bei "text" nicht das 0Dh...
Gruß Frank
-
Nicht, wenn er ASCII-Upload gemacht hat.
Der FTP-Client des Windows-Commanders bietet z.B. als Transfermodus "auto", "binär", "text" an und entfernt bei "text" nicht das 0Dh...:-)))
Das ist kein Widerspruch zu meiner Aussage.
(Bloß ein Bug im Win Commander ...)
-
-