nicht angemeldet
cgi.pm geht nicht mit Webserver "tinyweb"
0 0 
Struppi
0 So gehts...
cgi.pm geht nicht mit Webserver "tinyweb"
Hallo,
ich verwende unter WinXP den Webserver "tinyweb" und versuche folgendes Perl Skript "hello.pl" zum Laufen zu bringen:
###################################
use CGI;
print "Content-Type: text/html\n\n";
print "Hello, World!\n";
###################################
tinyweb gibt aus: "CGI script /cgi-bin/hello.pl returned nothing". Das Einlesen der cgi.pm verursacht den Fehler. Habe schon ältere Versionen von cgi.pm getestet - ohne Erfolg. Ohne tinyweb läuft das Skript auf der Kommandozeile wunderbar.
Hat jemand eine Idee? Bin am verzweifeln...
Gruß, Heiko
-
hallo,
ich verwende unter WinXP den Webserver "tinyweb"
Das ist ungewöhnlich. Die meisten testen auch unter WindowsXP den Apache
und versuche folgendes Perl Skript "hello.pl" zum Laufen zu bringen:
###################################
use CGI;
print "Content-Type: text/html\n\n";
print "Hello, World!\n";
###################################Du hast dich aber über die Rolle der shebang informiert? Für den Apache kann man sie "deaktivieren", indem man in der httpd.conf "ScriptInterpreterSource registry" angibt - für tinyweb gibt es eine solche Möglichkeit meines Wissens nicht. Also muß sie notiert werden, und das ist in deinem Script nicht erfolgt.
tinyweb gibt aus: "CGI script /cgi-bin/hello.pl returned nothing".
Klar - weil der Interpreter gar nicht erst angesprochen wurde.
Ohne tinyweb läuft das Skript auf der Kommandozeile wunderbar.
Auch klar - weil der Perl-Interpreter vom System über %PATH gefunden und angesprochen werden kann. Dein System weiß, welches ausführende Programm es für Dateien mit der Extension "pl" aufrufen soll. Dein lokaler Webserver allerdings weiß das nicht.
Hat jemand eine Idee? Bin am verzweifeln...
Langsam wirds langweiig, andauernd irgendwas von "verzweifeln" zu lesen. Neuerdings schreiben das fast alle in ihre postings, in der stillen Hoffnung, daß es hilft. Es hilft nicht. Verzweifle du ruhig.
Grüße aus Berlin
Christoph S.
-
Moin.
ich verwende unter WinXP den Webserver "tinyweb"
Das ist ungewöhnlich. Die meisten testen auch unter WindowsXP den ApacheMag sein, aber tinyweb ist zum Testen von Scripten ok.
und versuche folgendes Perl Skript "hello.pl" zum Laufen zu bringen:
###################################
use CGI;
print "Content-Type: text/html\n\n";
print "Hello, World!\n";
###################################Du bindest das CGI-Modul zwar ein, es wird aber nicht benutzt, das ist also nicht der Grund für Dein Problem...
Du hast dich aber über die Rolle der shebang informiert? [...] Also muß sie notiert werden, und das ist in deinem Script nicht erfolgt.
tinyweb braucht diese Zeile nicht, was eigentlich gar nicht schlecht ist. So muß man weder die Verzeichnisstruktur des ZielServers auf seinem Test-PC nachbilden noch die Zeile vorm hochladen an den Server anpassen - eine Fehlerquelle weniger.
Vielmehr ist wichtig, daß die Extention ".pl" mit dem Perlinterpreter verknüpft ist. (Ordneroptionen -> Dateitypen)
tinyweb gibt aus: "CGI script /cgi-bin/hello.pl returned nothing".
Klar - weil der Interpreter gar nicht erst angesprochen wurde.Und zwar aus o.g. Grund.
Gruß Frank
-
Ich danke Euch für die Antworten.
Ich möchte mit tinyweb arbeiten, weil ich einen Webserver benötige, den man lediglich starten aber nicht installieren muss.
shebang ist nicht das Problem, wird bei tinyweb nicht benötigt.
Die Extension ".pl" ist mit dem Perlinterpreter korrekt verknüpft.
Folgendes Skript funktioniert zum Beispiel:
###################################
#use CGI;
use CARP;
print "Content-Type: text/html\n\n";
print "Hello, World!\n";
###################################Das Einbinden klappt nur für das Modul cgi.pm nicht. Ich vermute das Problem liegt irgendwie beim tinyweb. Hatte gehofft, das Problem ist bekannt.
Kennt jemand einen anderen kostenlosen, cgi-fähigen Winzig-Webserver, der nicht installiert werden muss?
Gruß, Heiko
-
Die Extension ".pl" ist mit dem Perlinterpreter korrekt verknüpft.
d.h. mit einem Doppelklick wird das Skript gestartet?
Folgendes Skript funktioniert zum Beispiel:
###################################
#use CGI;
use CARP;
print "Content-Type: text/html\n\n";
print "Hello, World!\n";
###################################Das kann nicht funktionieren, es sei denn du hast irgendwo in @INC ein Modul das CARP heißt versteckt.
Das Einbinden klappt nur für das Modul cgi.pm nicht. Ich vermute das Problem liegt irgendwie beim tinyweb. Hatte gehofft, das Problem ist bekannt.
Das Modul heißt CGI.pm, nein das Problem existiert normalerweise nicht, was für ein Perl hast du den?
Struppi.
--
Javascript ist toll (Perl auch!) -
Moin.
Ich möchte mit tinyweb arbeiten, weil ich einen Webserver benötige, den man lediglich starten aber nicht installieren muss.
Dazu ist TinyWeb bestens geeignet.
shebang ist nicht das Problem, wird bei tinyweb nicht benötigt.
Wie ich schon sagte.
Das Einbinden klappt nur für das Modul cgi.pm nicht. Ich vermute das Problem liegt irgendwie beim tinyweb. Hatte gehofft, das Problem ist bekannt. Kennt jemand einen anderen kostenlosen, cgi-fähigen Winzig-Webserver, der nicht installiert werden muss?
Du brauchst keinen anderen Webserver, sondern eine ordentliche Perlinstallation. ActivPerl wäre eine. Aber vielleicht mußt Du auch nur den Suchpfad richtig einstellen.
Was steht eigentlich in den logfiles des Servers drin? Und was steht in @INC drin?
print "Content-Type: text/html\n\n";
print @INC;Gruß Frank
-
Hallo Struppi, hallo Frank,
Danke für Eure prompte Hilfe.Doppelklick oder auf der Kommandozeile funktioniert beides. Soll aber bitte auch über tinyweb funktionieren.
Die Datei C:\Perl\lib\Carp.pm wurde standardmäßig bei meiner Perlinstallation eingerichtet. Ich habs nicht selbst nachinstalliert, sollte hier nur als irgendein Beispiel fungieren. Beliebige andere Module funktionieren ebenso - nur eben CGI.pm nicht.
Ich habe die Download-Datei "ActivePerl-5.8.6.811-MSWin32-x86-122208.msi" installiert. Probiere vielleicht mal noch 5.8.8 aus.
In der CGI.pm sind offensichtlich irgendwo im Quellcode Stellen, die der tinyweb nicht mag. Ich habe bereits unterschiedliche Versionen von CGI.pm ausprobiert, kein Erfolg. Habe nicht genügend Erfahrung mit Debuggen.
Die error_log bleibt leider leer. Dieses Problem haben offensichtlich auch schon andere. Konnte ich nachlesen, aber leider auch nicht lösen.
Ich würde zur Lösung des Problems gerne auch auf einen anderen Winzig-Webserver umsteigen. Kenne aber keinen vergleichbaren.
Hintergrund:
Ein bereits existentes, umfangreiches WWW-Info-System mit Perlskripten sollen Kunden für eine lokale Nutzung auf einer CD erhalten. Die Kunden müssen also Perl installieren. Da möchte ich vermeiden, dass sie nicht auch noch Apache o.ä. installieren müssen.Ich muss evtl. einfach auf CGI.pm verzichten. Aber das wird ein ziemlicher Aufwand.
Gruß, Heiko
-
Hallo,
Ein bereits existentes, umfangreiches WWW-Info-System mit Perlskripten sollen Kunden für eine lokale Nutzung auf einer CD erhalten. Die Kunden müssen also Perl installieren. Da möchte ich vermeiden, dass sie nicht auch noch Apache o.ä. installieren müssen.
Es ist durchaus auch möglich, den Apache komplett ohne installation zu betreiben. auch ist es nihct zwangsläufig notwendig, dass Perl installiert werden muss. Das Ganze kann in einer Verzeichnis-Struktur zusammen kompiert werden und dann über eine batch-Datei die Umgebungsvariablen gesetzt und danach der Indianer gestartet werden.
AFAIK gibt es für sowas bereits fertige Pakete irgendwo zum runterladen.
Grüße
Klaus-
Hallo Klaus,
danke für Deinen interessanten Hinweis.AFAIK gibt es für sowas bereits fertige Pakete irgendwo zum runterladen.
Habe geschaut. Wahrscheinlich meinst Du www.apachefriends.org/de/xampp.html. Das ist eine Überlegung wert.
Bisher war mir aber noch gar nicht so klar, dass ein Webserver einen Rechner mit Sicherheit unsicher macht. Ich sollte darüber nachdenken, das ganze Perl-Zeugs in Javascript umzuschreiben. Dann brauch ich keinen Webserver mehr.
Gruß, Heiko
-
hallo,
Wahrscheinlich meinst Du www.apachefriends.org/de/xampp.html.
Nein, das meint er sicher nicht. Das ist im Gegensatz zu deinem Wunsch nach etwas "Kleinem" ein ziemlich riesiges Paket, das weit mehr als bloß Apache und Perl beinhaltet.
Bisher war mir aber noch gar nicht so klar, dass ein Webserver einen Rechner mit Sicherheit unsicher macht.
Tut er auch nicht.
Grüße aus Berlin
Christoph S.
-
-
-
Doppelklick oder auf der Kommandozeile funktioniert beides. Soll aber bitte auch über tinyweb funktionieren.
Du hast auch die Hinweise beim Hersteller beachtet: http://www.ritlabs.com/en/products/tinyweb/features.php
Die Datei C:\Perl\lib\Carp.pm wurde standardmäßig bei meiner Perlinstallation eingerichtet. Ich habs nicht selbst nachinstalliert, sollte hier nur als irgendein Beispiel fungieren. Beliebige andere Module funktionieren ebenso - nur eben CGI.pm nicht.
OK, ich vergaß das du unter Windows arbeitest, du solltest trotzdem immer Groß- und kleinschreibung beachten, da die Module in packeten liegen, die du entsprechend ansprechen musst, also use Carp oder use CGI
Ich habe die Download-Datei "ActivePerl-5.8.6.811-MSWin32-x86-122208.msi" installiert. Probiere vielleicht mal noch 5.8.8 aus.
Ne ist ok, CGI ist seit Ewigkeiten bei jeder Perl installation dabei.
Hintergrund:
Ein bereits existentes, umfangreiches WWW-Info-System mit Perlskripten sollen Kunden für eine lokale Nutzung auf einer CD erhalten. Die Kunden müssen also Perl installieren. Da möchte ich vermeiden, dass sie nicht auch noch Apache o.ä. installieren müssen.Mir scheint tyinyweb dafür auch dei beste Wahl.
Ich muss evtl. einfach auf CGI.pm verzichten. Aber das wird ein ziemlicher Aufwand.
Das glaube ich wiederrum nicht. Das Modul ist rein in Perl (im gegensatz zu manch anderen) und kann problemlos auch in einem eigenen lib Verzeichniss installiert werden.
Struppi.
--
Javascript ist toll (Perl auch!)-
hallo,
CGI ist seit Ewigkeiten bei jeder Perl installation dabei.
Seit Mai 1997 gehört CGI.pm zu den Standardmodulen.
Grüße aus Berlin
Christoph S.
-
-
-
-
-
-
-
ich verwende unter WinXP den Webserver "tinyweb" und versuche folgendes Perl Skript "hello.pl" zum Laufen zu bringen:
ich kenne den Server auch nicht, aber du musst ihnen mitteilen, was er mit den Perl Skripten machen soll.
Es gibt mehrere Möglichkeiten, Apache liest auch unter Win die Shebang zeile, d.h. dort muss dann der konkrete Pfad zur Perl.exe stehen, er kann aber auch dazu gebracht werden die Registryeintrag zu lesen. Oder der server hat eine Einstellung wo du den Pfad angibst.Struppi.
--
Javascript ist toll (Perl auch!) -
Moin.
Hat jemand eine Idee?
Ja, eben ist es mir eingefallen, ich hatte mal ein ähnliches Problem. Aber ich glaube mich zu erinnern, das es nicht mit TinyWeb war.
Also: den Grund dafür habe ich noch nicht untersucht, ich habe aber eine Lösung. Irgendwie möchte CGI den HTML-Header selbst ausgeben.
Eine kleine Änderung, und schon gehts:
###################################
use CGI;$query = new CGI;
print $query->header('text/html');print "Hello, World!\n";
###################################Und konsequenter weise dann so:
use CGI::Carp qw(fatalsToBrowser);
use CGI;$query = new CGI;
print $query->header('text/html');
print $query->start_html(-title=>'Hello world');
print "hello world!\n";
print $query->end_html;Und vielleicht können die Perl-Gurus hier mal schreiben, warum man nach dem "use CGI" den Header zwingend wie o.g. ausgeben muß.
Gruß Frank
-
Also: den Grund dafür habe ich noch nicht untersucht, ich habe aber eine Lösung. Irgendwie möchte CGI den HTML-Header selbst ausgeben.
Natürlich, macht er aber auch.
Und vielleicht können die Perl-Gurus hier mal schreiben, warum man nach dem "use CGI" den Header zwingend wie o.g. ausgeben muß.
Weil sonst der Browser nicht weiß was er machen soll.
Struppi.
--
Javascript ist toll (Perl auch!)-
Moin.
Und vielleicht können die Perl-Gurus hier mal schreiben, warum man nach dem "use CGI" den Header zwingend wie o.g. ausgeben muß.
Weil sonst der Browser nicht weiß was er machen soll.
Ja, das ist schon klar. Daß diese Variante funktioniert, ist klar:
use CGI;
$query = new CGI;
print $query->header('text/html');
print "Hello, World!\n";Aber warum geht das nicht:
use CGI;
print "Content-Type: text/html\n\n";
print "Hello, World!\n";Schließlich wird auch hier ein gültiger Header ausgegeben...?
Gruß Frank
-
hallo,
Aber warum geht das nicht:
use CGI;
print "Content-Type: text/html\n\n";
print "Hello, World!\n";Im Apache funktioniert es. Ich habe mir grade mal Tinyweb gezogen, muß aber auf dem Rechner, auf dem er dann laufen soll, erst noch Perl installieren.
Grüße aus Berlin
Christoph S.
-
Moin.
Im Apache funktioniert es. Ich habe mir grade mal Tinyweb gezogen, muß aber auf dem Rechner, auf dem er dann laufen soll, erst noch Perl installieren.
Das habe ich nun auch ausprobiert:
- Apache/2.0.48,
- Perl v5.8.3 built for MSWin32-x86-multi-thread
Mit TinyWeb gehts nicht. Kann es sein, daß mit dem Modul CGI das Script ausgaben macht, die der Apache bekommt, TinyWeb aber nicht?
Gruß Frank
-
hallo,
Im Apache funktioniert es.
Mit TinyWeb gehts nicht.Weiß ich inzwischen auch.
Kann es sein, daß mit dem Modul CGI das Script ausgaben macht, die der Apache bekommt, TinyWeb aber nicht?
Nein. Schau dir dieses sehr magere Script doch an. Es steht zwar "use CGI" da, das wird aber nicht benutzt, sondern die Ausgabe, die erzeugt werden soll, geht gewissermaßen an CGI.pm vorbei. Wenn du "use CGI" ausklammerst, bekommst du ja das Gewünschte angezeigt.
Tinyweb kann aber mit dem CGI-Modul umgehen. Nimm das Beispiel, das ich weiter oben angegeben habe. Das funktioniert, und da werden die Ausgaben mit Hilfe von CGI.pm zusammengestellt.
Eventuell will Tinyweb bloß, daß man keine überflüssigen Zeilen ins Script schreibt.
Grüße aus Berlin
Christoph S.
-
Im Apache funktioniert es.
Mit TinyWeb gehts nicht.Weiß ich inzwischen auch.
auch wenn der klein ist ist mir das jetzt zuviel, eine Möglichgkeit zu erfahren was hier falsch läuft wäre vor dem einbinden der Module Fehlermeldungen und Warnungen abzufangen:
BEGIN { print "content-type:text/plain\n\n"; $SIG{__WARN__} = sub { print "Warnung: @_ \n"; }; }Tinyweb kann aber mit dem CGI-Modul umgehen. Nimm das Beispiel, das ich weiter oben angegeben habe. Das funktioniert, und da werden die Ausgaben mit Hilfe von CGI.pm zusammengestellt.
sehr seltsam.
Eventuell will Tinyweb bloß, daß man keine überflüssigen Zeilen ins Script schreibt.
Das kann eigentlich nicht sein, da tinyweb nichts von Perl weiß, sondern lediglich den Interpreter startet und die entsprechenden CGI Parameter weiterreicht und die Ausgabe annimmt.
Struppi.
--
Javascript ist toll (Perl auch!) -
Moin.
Kann es sein, daß mit dem Modul CGI das Script ausgaben macht, die der Apache bekommt, TinyWeb aber nicht?
Nein. Schau dir dieses sehr magere Script doch an. Es steht zwar "use CGI" da, das wird aber nicht benutzt, sondern die Ausgabe, die erzeugt werden soll, geht gewissermaßen an CGI.pm vorbei. Wenn du "use CGI" ausklammerst, bekommst du ja das Gewünschte angezeigt.
Eben. Mir fehlt nur im Moment leider die Zeit, das Modul genauer zu untersuchen. Mein Verdacht ist folgender: Im CGI.pm wird die Standard-Perl-Methode print ersetzt. Und die gibt solange die Ausgaben nach STDERR aus, bis ein gültiger Header mittels
$query = new CGI;
print $query->header('text/html'); # o.ä.erzeugt wurde. Vielleicht lauscht der (Win-)Apache sowohl an STDERR als auch an STDIN, TinyWeb aber nur an STDIN.
Tinyweb kann aber mit dem CGI-Modul umgehen. Nimm das Beispiel, das ich weiter oben angegeben habe. Das funktioniert, und da werden die Ausgaben mit Hilfe von CGI.pm zusammengestellt.
TinyWeb muß nicht damit umgehen können. Perl muß es können.
Eventuell will Tinyweb bloß, daß man keine überflüssigen Zeilen ins Script schreibt.
Das würde heißen, daß TinyWeb das Script parsed, bevor der Server es ausführt. TinyWeb hat aber keine Ahnung von der Sprache, in der das Programm geschrieben wurde, das dort ausgeführt werden soll.
Der Browser fordert bei TinyWeb eine Resource an. Der Server erkennt (TinyWeb vermutlich am Pfad "cgi-bin"), daß es eine Resource ist, die ausgeführt werden soll. Also wird das Programm gestartet, vorher werden natürlich die erforderlichen Umgebungsvariablen gesetzt und ggf. entsprechend der Request Methode die Parameter übergeben. Dann wartet der Server, bis er an STDIN die Daten bekommt, die das Programm ausgibt. Endet es, ohne daß die Ausgabe z.B. einem gültigen HTML-Header enthält, sendet der Server einen Error 500, endet es ohne Ausgabe: ... returned nothing... Und dabei ist es völlig egal, ob das Programm ein shell script, ein Bachtfile, eine .exe oder eben ein Perlscript ist.
Gruß Frank
-
Mahlzeit.
Mir fehlt nur im Moment leider die Zeit, das Modul genauer zu untersuchen. Mein Verdacht ist folgender: Im CGI.pm wird die Standard-Perl-Methode print ersetzt.
Nö, das isses nich. Aber: CGI.pm setzt STDOUT unter WINDOWS|DOS|OS2|MSWin|CYGWIN in den binmode:
$CGI::DefaultClass->binmode(main::STDOUT);
Damit ist \n nicht mehr 0x0d 0x0a sondern nur 0x0a. Und das scheint Tinyweb nicht zu genügen, der Indianer ist da toleranter, er kennt das ja von Linux... Eine kleine Änderung des Scripts bringt das gewünschte Ergebnis:
use CGI;
print "Content-Type: text/html;\r\n\r\n";
print "Hello, World!\n";Damit wird der Header richtig beendet und Tinyweb ist zufrieden.
Warum es dann aber mit
print $query->header('text/html');
geht? Unter Windows wird in CGI.pm $CRLF = "\015\012"; gesetzt. Und diese Variable wird, nachdem die Methode header() den selbigen zusammengebaut hat, 2x an ihn angehangen:
my $header = join($CRLF,@header)."${CRLF}${CRLF}";
Das liefert dann "ordentliche" Zeilenenden...
Gruß Frank
-
-
-
-
-
-
hallo,
vielleicht können die Perl-Gurus hier mal schreiben, warum man nach dem "use CGI" den Header zwingend wie o.g. ausgeben muß.
Muß man nicht. "text/html" ist Standardbelegung, das muß also nicht angegeben werden. Dein Vorschlag funktioniert auch so:
use CGI::Carp qw(fatalsToBrowser); use CGI qw/:standard/; print header, start_html('Hello world'), h1("hello world!"), end_html;Grüße aus Berlin
Christoph S.
-