kleine cgi-frage (ich werd wahnsinnig!!!)

geogre · Sonntag 13. November 2005, 14:04

erstmal grundsätzlich tausend dank an alle, die so nett sind leuten wie mir hier weiter und auf die sprünge zu helfen!!! wenn ich groß bin werde ich auch mal einer von euch

also: ich habe ein html-formular, welches per submit und post ein python cgi aufruft, funktioniert super.

das python skript erstellt jetzt seinerseits ein neues formular mit einem neuen submit knopf (funktioniert auch super) was ein ANDERES python skript aufrufen soll, genauso wie das erste.

das klappt auch, aber das zweite skript WILL NICHT!!! ich bekomme immer nur einen "internal server error" vom server, ich weiß nicht warum, es ist völlig egal was das skript macht, ich kann nicht mal "hallo" ausgeben. finden tut er das skript, ich hab ein bisschen den verdacht, dass es an der zeile #!/usr/bin/python liegt, vielleicht wegen des nun anderen pfades, aber ich hab grad schon echt viel ausprobiert und mag jetzt nicht mehr...

danke für eure hilfe

Gast · Sonntag 13. November 2005, 15:22

Hi!

geogre hat geschrieben:und mag jetzt nicht mehr...

Wenn meine vermutung richtig ist, hast du da auch den zum-wahnsinn-treib-fehler schlechthin.

Wurde das skript mal auf einem windowsrechner bearbeitet? Wenn ja, steht hinterm "#!/usr/bin/python" noch ein "\r" und "#!/usr/bin/python\r" findet linux natürlich nicht. Leider haben fast alle linuxeditoren mittlerweile die schlechte angewohnheit, "\r" nicht mehr als "^M" darzustellen. Mit dos2unix kannst du die "\r" löschen.
joe

mitsuhiko · Sonntag 13. November 2005, 16:48

Code: Alles auswählen

import cgitb; cgitb.enable()

Rein und Haudi herda

Vergiss nicht die HTTP Header zu senden, also zumindest mal

Code: Alles auswählen

print "Content-Type: text/html"
print

Rein.

geogre · Sonntag 13. November 2005, 21:15

danke für die antworten soweit...
also, das skript habe ich sowohl unter windows (ultraedit bzw idle) aber hauptsächlich unter linux mit kate getippt. das erste skript (das welches geht) habe ich nur in idle geschrieben... gute idee mit den codes, da muss ich grad mal nachforschen... wäre ich NIE drauf gekommen

zur zweiten antwort... da hab ich dran gedacht und auch viele kombinationen ausprobiert:

Code: Alles auswählen

#!/usr/bin/python
# -*- coding: cp1252 -*-
import cgitb; cgitb.enable()
import cgi

form = cgi.FieldStorage()

print "Content-Type: text/html\n"
print "<HTML><HEAD><TITLE>Testseite</TITLE></HEAD><BODY>"
print "<p>hallo</p>"
print "</BODY></HTML>"

aber wie gesagt, sogar das "hallo" verursacht im moment noch einen "internal server error" ...

geogre · Sonntag 13. November 2005, 21:18

also, ich hab mal grade nach den codes am zeilenende geforscht (mit uedit im hexmodus), es ist leider bei beiden skripten das gleiche, 2 byte "0D0A". und wie gesagt, das erste funktioniert blendend, das zweite (s.o.) gar nicht !!! ich dreh durch... nein, ich dreh natürlich nicht durch, aber ich halte mich langsam für echt blöd...

Gast · Sonntag 13. November 2005, 22:25

Vorab: Was steht denn überhaupt in der fehlerlog-datei des webservers?

geogre hat geschrieben:(mit uedit im hexmodus), es ist leider bei beiden skripten das gleiche, 2 byte "0D0A"

Der hexmodus des ultraedit ist unbrauchbar. Das ding zeigt immer "0D0A" an, egal ob da nun ein "\r\n" oder ein "\n" ist; zumindest in der version, die ich mal getestet habe. Mach mal unter linux "cat -v myscript.py" und guckt, ob da ein "^M" hinterm shebang ist und wende dann ggf. dos2unix an.
joe

geogre · Sonntag 13. November 2005, 23:16

ok, werde ich tun... danke. ich hab ultaedit 10.20c, macht auf mich *eigentlich* einen ganz brauchbaren eindruck, aber solche details kriegt man ja auch auf den ersten blick nicht mit

werd jetzt mal schauen was cat -v sagt

ich habe leider keine ahnung wie und ob ich an die fehler-log datei komme (provider ist strato)

geogre · Sonntag 13. November 2005, 23:36

also, cat -v hat für beide skripte (das funktionierende und das mit fehlermeldung) für alle zeilen ausnahmslos ^M als zeilenende angezeigt ...

#!/usr/bin/python^M

(ist das ein DOS-zeilenende?) wdas, daran kann es also nicht liegen, denn das eine skript läuft ja prima. kann es etwas mit dem pfad zu tun haben? beide skripte sind in /cgi-bin/ abgespeichert und haben natürlich zulässige dateinamen usw, nur dass das eine aus einer "echten" html-form und das andere aus einer von skript no1 erzeugten form aufgerufen werden...

Gast · Montag 14. November 2005, 00:00

geogre hat geschrieben:(ist das ein DOS-zeilenende?) wdas, daran kann es also nicht liegen, denn das eine skript läuft ja prima. kann es etwas mit dem pfad zu tun haben?

Grrr, nicht lange rumrätseln, sondern dos2unix anwenden!!!!!!!!!!!!!!!111
joe

Gast · Montag 14. November 2005, 00:01

geogre hat geschrieben:(ist das ein DOS-zeilenende?) wdas, daran kann es also nicht liegen, denn das eine skript läuft ja prima. kann es etwas mit dem pfad zu tun haben?

Grrr, nicht lange rumrätseln, sondern dos2unix anwenden!!!!!!!!!!!!!!!111
joe

geogre · Montag 14. November 2005, 01:09

so, habe jetzt die datei mit dos2unix umgewandelt, mit cat -v sieht man jetzt, daß alle ^M verschwunden sind (es sind aber auch keine \n da, sondern nix mehr)

aber... immernoch fehler vom server. ich hab nochmnal die dateirechte gecheckt, aber ausführbar ist sie, genau wie die andere...

gerold · Montag 14. November 2005, 09:09

Hi!

Sieh dir die Berechtigungen der Datei an die funktioniert und vergleiche sie noch einmel mit den Berechtigungen der Datei, die nicht funktioniert.

Sieh dir auch an, wem die Dateien gehören.

Ich habe mir dein Skript angesehen und auf meinem Server ausprobiert. Dein Skript funktioniert, sobald ich die richtigen Zugriffsrechte vergeben habe. Meistens muss so ein Skript für alle ausführbar sein. Nicht nur für den Besitzer oder die Gruppe.

mfg
Gerold

joe · Montag 14. November 2005, 09:17

'nMorgen!

geogre hat geschrieben:aber... immernoch fehler vom server. ich hab nochmnal die dateirechte gecheckt, aber ausführbar ist sie, genau wie die andere...

klein/gross-schreibung der dateinamen beachtet?
Ansonsten hilft nur noch die meldung aus der errorlog-datei des webservers weiter. Liegt meist unter sowas wie /var/log. Zur Not mal mit
find / -name "error.*" -print
suchen.
joe

Gast · Montag 14. November 2005, 09:20

joe hat geschrieben:find / -name "error.*" -print

Sorry, ohne den punkt:
find / -name "error*" -print
Ich meine, die datei heißt meist "error_log".
joe

jens · Montag 14. November 2005, 09:37

gerold hat geschrieben:Meistens muss so ein Skript für alle ausführbar sein. Nicht nur für den Besitzer oder die Gruppe.

I.d.R. reicht es aus nur für "Öffentliche Berechtigung" das ausführbar-Tag zu setzten! Also chmod 645
Da der Apache ja als nobody laufen sollte und er das Skript ja startet...

mitsuhiko · Montag 14. November 2005, 10:41

cgi scripte sollten als 755 laufen.

geogre · Montag 14. November 2005, 13:59

wow... vielen dank für die vielen beiträge und hilfe-versuche!!!! ihr seid echt großartig! aber leider gehts immernoch nicht... am ende kommt bestimmt ein so idiotischer fehler heraus, daß ich mich mindestens 1 woche schäme... aber dann hat vielleicht wenigstens jemand was zu lachen

also:
- die dateirechte waren mit denen des funktionierenden skripts identisch, nämlich rwxr-xr-x
ich habe nochmal ausprobiert, auch für gruppe und sonstige schreiben zu erlauben (wobei das natürlich nicht wirklich sinn macht, aber ich bin halt echt am verzweifeln, raten und stumpfen ausprobieren) und bin letztlich bei rwxrwxrwx gelandet, das alles interessiert den server offenbar überhauptnicht, stumpf die 500 internal server error.
- groß-kleinschreibung: ich habe komplett und ausschliesslich alles klein geschrieben und die dateinamen sind natürlich frei von irgendwelchen sonderzeichen oder besonderheiten
- an die error.log datei komme ich wohl nicht heran, da es wie gesagt eine strato domain ist und die rechte und möglichkeiten u.a. dahingehend eingeschränkt.

ich hab noch versucht die datei umzubenennen, mal mit py endung oder mit cgi, den "pfad" im shebang zu ändern, nützt alles nix. dabei ist das skript welches den html-code erzeugt, welcher wiederum dieses problemskript aufruft viel länger (natürlich) und "komplizierter" und vor allem in fast jeder äusseren hinsicht (wie z.b. dateirechte etc) völlig identisch!!! kann es am erzeugten html liegen? enctype? ist aber auch mit skript1 identisch (also vom prinzip her)...

ausschnitt aus dem html:
<form enctype="multipart/form-data" method="POST" action="peng.cgi" name="form2">
<input type="text" name="eingabe" value="irgendwas">
<input type="submit" value="absenden" name="knopf">
</form>

...das funktioniert ja auch, skript2 WIRD aufgerufen, wenn ich es z.b. in einem falschen ordner habe oder unter falschem namen kommt eine andere fehlermeldung vom apache (irgendwas file not found mässiges), also wird es ja wenigstens gefunden und gestartet...

läuft das andere im hintergrund irgendwie weiter und ich muss es erst irgendwie killen bevor python ein neues ausführen kann?

jens · Montag 14. November 2005, 15:24

Also ich würde immer schritt für schnitt testen... d.H. nach dem der HTML-Header ausgegeben wurde, ein print "Hello World" und sys.exit()... Dann Im Browser testen... Wenn's geht dann das print und sys.exit verschieben...

Du sagst du rufst von einem Skript ein anderes auf. Sowas wie generiere_forumlar.py und werte_formular_aus.py ??? Und das Auswerten funktioniert nicht? Dann rufe es doch einfach mal direkt auf.

Generell kannst du sowas natürlich alles in ein Skript packen. Wenn kein "Senden"-Button geklickt wurde (in den CGI-Daten vorhanden), dann zeige das Forumular...

mitsuhiko · Montag 14. November 2005, 16:15

Wann lernen die Leute mal die Logfiles zu lesen ^^

/var/log/apache2/error.log <-- gibt Rückschlüsse

joe · Montag 14. November 2005, 17:53

blackbird hat geschrieben:Wann lernen die Leute mal die Logfiles zu lesen

Wann lernen die leute mal threads lesen?

geogre schrieb, daß er nicht an die datei rankäme (was ich allerdings nicht recht glauben mag.)
joe