Seite 1 von 1

Bug bei CGIHTTPServer ?

Verfasst: Mittwoch 7. Oktober 2009, 21:10
von ms4py
Der CGIHTTPServer funktioniert bei mir nicht, wenn im Dateipfad Leerzeichen auftauchen.
Konnte das Problem bis zur Funktion os.popen3 zurückverfolgen:

Code: Alles auswählen

>>> import os
>>> fobjs = os.popen3(os.path.join("C:\Program Files", "test.texe"))
>>> fobjs[2].read()
'Der Befehl "C:\\Program" ist entweder falsch geschrieben oder\nkonnte nicht gefunden werden.\n'
Habe ich irgendwelche Möglichkeiten, diesen Fehler zu korrigieren oder muss ich meine Benutzer darauf hinweisen, dass das Programm nur ohne Leerzeichen im Pfad ausgeführt werden soll?

Verfasst: Donnerstag 8. Oktober 2009, 01:21
von Defnull
Warum schreibst du, das CGIHTTPServer nicht funktioniert, wenn du den Fehler doch selbst schon auf os.popen3 eingegrenzt hast? Und warum vermutest du einen Bug in einem tausendfach getesteten Modul, statt ihn bei dir selbst zu vermuten? :roll:

os.popen3 gibt den Befehl direkt an os.system() und damit an eine Shell weiter. Schon mal versucht, Pfade mit Leerzeichen darin in die MsDOS Eingabeaufforderung ein zu tippen? Klappt auch nicht.

Aaaaaaber du willst eh subprocess verwenden, da:
"Deprecated since version 2.6: All of the popen*() functions are obsolete. Use the subprocess module."

Verfasst: Donnerstag 8. Oktober 2009, 08:27
von ms4py
Defnull hat geschrieben:Warum schreibst du, das CGIHTTPServer nicht funktioniert, wenn du den Fehler doch selbst schon auf os.popen3 eingegrenzt hast? Und warum vermutest du einen Bug in einem tausendfach getesteten Modul, statt ihn bei dir selbst zu vermuten? :roll:
Weil das CGIHTTPServer-Modul os.popen3 nutzt (unter Win), um die CGI-Skripte auszuführen und er mir dann den äquivalenten Fehler zurückliefert. (Sorry, war in der Frage vielleicht nicht deutlich...)

Verfasst: Donnerstag 8. Oktober 2009, 13:06
von snafu
Zeig doch einfach die Fehlermeldung, die wirklich kommt und den dazu gehörigen Code und nicht irgendein Beispiel, dass du mit os.popen3() selbst erstellt hast.

Verfasst: Donnerstag 8. Oktober 2009, 13:20
von ms4py
snafu hat geschrieben:Zeig doch einfach die Fehlermeldung, die wirklich kommt und den dazu gehörigen Code und nicht irgendein Beispiel, dass du mit os.popen3() selbst erstellt hast.
Genau der selbe Fehler:
localhost - - [08/Oct/2009 14:24:16] command: C:\Program Files (x86)\He
rmle\Python26_Portable\python.exe -u C:\Program Files (x86)\Hermle\HIMS\webclien
t\cgi-bin\overview.py ""
localhost - - [08/Oct/2009 14:24:16] Der Befehl "C:\Program" ist entwed
er falsch geschrieben oder
konnte nicht gefunden werden.
Code:

Code: Alles auswählen

class Handler(CGIHTTPServer.CGIHTTPRequestHandler):
    ''' Handler für CGI-Skripts ohne zusätzliche Ausgabe. '''
    cgi_directories = ["/webclient/cgi-bin"]
    
    
class WebServer(Thread):
    ''' Der Thread. '''
    def __init__(self):
        Thread.__init__(self)
        
        # self.port aus ini lesen

    def run(self):
        ''' Startet den Server. '''
        httpd = BaseHTTPServer.HTTPServer(("", self.port), Handler)
        httpd.serve_forever()
Edit: An der portablen Version liegt es außerdem nicht. Wenn der Pfad zu python.exe ohne Leerzeichen ist und nur der Pfad zum Skript Leerzeichen enthält, funktioniert das Ganze auch nicht!

Verfasst: Freitag 9. Oktober 2009, 06:08
von gerold
Hallo!

Der *CGIHTTPServer* verhält sich oft anders als der Apache. Ich habe es aufgegeben, damit komplexere CGIs zu testen. Nicht nur, dass es Probleme mit Leerzeichen gibt, es gibt auch Probleme mit den erwarteten Umgebungsvariablen...

Wenn der *CGIHTTPServer* Probleme mach, dann würde ich nicht zögern und diesen nicht weiter verwenden. Der ist wirklich nur geeignet um mal kurz etwas zu testen -- leider.

http://halvar.at/python/xampp_python_cgi/

Aber wie immer hier der Hinweis: CGI ist gut, um mal kurz herauszufinden, wie Webprogrammierung so läuft. Sobald man aber ernste Projekte angehen möchte, sollte man bei Python auf WSGI setzen. Ob das nun CherryPy ( http://halvar.at/python/cherrypy_cheetah/ ) oder Bottle ( http://www.python-forum.de/topic-19451.html ) ist, ist dann "Wurscht".

mfg
Gerold
:-)

Verfasst: Freitag 9. Oktober 2009, 07:54
von mkesper
Defnull hat geschrieben:os.popen3 gibt den Befehl direkt an os.system() und damit an eine Shell weiter. Schon mal versucht, Pfade mit Leerzeichen darin in die MsDOS Eingabeaufforderung ein zu tippen? Klappt auch nicht.
Wenn sie gequotet sind, klappt das einwandfrei (windows XP):

Code: Alles auswählen

C:\>cd "Program Files"

C:\Program Files>

Verfasst: Freitag 9. Oktober 2009, 08:12
von ms4py
Es sollte schon eine einfach und kompakte Lösung sein, da der Webclient nur ein Zusatzfeature von meinem Programm ist. Außerdem sollte das ganze Framework+HTTPServer on the Fly laufen, also ohne Konfiguration/Installation direkt aus *.py heraus.

Bottle scheint mir dafür geeignet. Trotzdem hier mein CGI-Skript:
http://pastebin.com/fbab0656
Ist dieses mit Bottle problemlos umzusetzen?

Verfasst: Freitag 9. Oktober 2009, 10:53
von lunar
Nein. CGI-Skripte lassen sich nicht ohne Änderungen in WSGI-Umgebungen ausführen.

Wenn Du aber einfach nur den Server in das Skript einbetten willst, ist CGI doch ein großer und völlig unnötiger Umweg. Du kannst doch einfach von einer der HTTP-Server-Klassen in der Standardbibliothek ableiten und die eingehenden Requests direkt selbst behandeln.

Verfasst: Freitag 9. Oktober 2009, 13:54
von ms4py
lunar hat geschrieben:Nein. CGI-Skripte lassen sich nicht ohne Änderungen in WSGI-Umgebungen ausführen.
Das war ja auch nicht die Frage, sondern nur ob das Skript umsetzbar ist...
lunar hat geschrieben: Wenn Du aber einfach nur den Server in das Skript einbetten willst, ist CGI doch ein großer und völlig unnötiger Umweg. Du kannst doch einfach von einer der HTTP-Server-Klassen in der Standardbibliothek ableiten und die eingehenden Requests direkt selbst behandeln.
Hört sich auch nicht schlecht an. Hast du mir dafür einen Ansatz? Kann mir nur grob vorstellen, wie du das meinst.
mkallas hat geschrieben:Wenn sie gequotet sind, klappt das einwandfrei (windows XP):
Aus Python heraus über os.system funktioniert das eben nicht!

Verfasst: Freitag 9. Oktober 2009, 14:16
von jbs
Du musst den Pfad nocheinmal quoten.

Code: Alles auswählen

'"C:\Program Files"'

Verfasst: Freitag 9. Oktober 2009, 14:32
von lunar
@ice2k3: Umsetzen lässt sich das schon. So unterschiedlich sind die Umgebungen nicht.

Einen "Ansatz" habe ich nicht. Lies halt die Quellen der HTTP-Server-Klassen, um herauszufinden, wie Du das Request-Handling reimplementieren kannst.