Perl unter Xampp. Andere Behandlung von @INC?

[Patrick Andrieu]

Hallo alle!

Nutzers meines Gästebuchs sind meistens damit zufrieden und kommen fast alle damit klar, so dass ich keinen Support leisten muß. Allerdings gibt es bei einer lokalen Installation unter Xampp immer wieder das Problem, dass eine mittels require eingebundene Library nicht gefunden wird.

Bei mir auf dem lokalen Xitami läuft dieses ohne Problem:

D
-www
--cgi-bin
---web-lib.pl
---require_test.pl

require_test.pl:

  
#!/usr/bin/perl -w  
  
require 'web-lib.pl';  
  
print "Content-type: text/html\n\n";  
  
print $date;  

$date wird in web-lib.pl ermittelt.

Xampp-User berichten hier, das GB-Skript (und auch dieses Test-Skript) wirft eine Fehlermeldung 'raus:

Can't locate web-lib.pl in @INC (@INC contains: X:/xampp/perl/site/lib/ X:/xampp/perl/site/lib X:/xampp/perl/lib/ . X:/xampp/apache) at X:/xampp/htdocs/cgi-bin/require_test.pl line 3.

Dabei steht doch der Punkt ».« in @INC für das aktuelle Verzeichnis, in dem Fall also »cgi-bin«. Und da ist auch die web-lib.pl, warum kommt hier bei Xampp-Usern eine Fehlermeldung? Wenn diese das GB auf ihren Webspace installieren, funktioniert auch alles wieder tadellos. Nur mit Xampp nicht.

Ich selbst habe Xampp nicht installiert.
Das GB wird irgendwann umgeschrieben und die Chose anders geregelt, doch befürchte ich, dass ein Modul im cgi-bin ebenfalls nicht in @INC located werden würde...

Jemand eine Idee (außer den Nutzern den Rat geben, die Datei zu verschieben)?

Viele Grüße aus Frankfurt/Main,
Patrick

[Horst]

Hallo,

@INC ist ja schön und gut, aber wenn die Software von Dritten sich nicht darum schert, kann da drin stehen, was will.

Beispiel von mir: Ich führe ein Perl-Script im Fenster des Editors "Textpad" aus. Eingebunden werden soll eine lib, die im gleichen Verzeichnis liegt. @INC hat auch den Eintrag ".", aber die lib wird trotzdem nicht eingebunden.

Die lib wird erst dann eingebunden, wenn ich im Editor "Textpad" festlege: "Arbeistverzeichnis folgt dem aktiven Dokument", dann gehts.

In Deinem Fall liegt dasselbe Verhalten vor, behaupte ich.
Mache ein
use lib '/home/usw'; # das hilft bestimmt

Hotte

[Christoph Schnauß]

hallo Horst,

Die lib wird erst dann eingebunden, wenn ich im Editor "Textpad" festlege: "Arbeistverzeichnis folgt dem aktiven Dokument", dann gehts.

Textpad ist leider kein geeignetes Vergleichsinstrument gegenüber einem HTTP-Server; in XAMPPO wird ja der Apache eingesetzt

In Deinem Fall liegt dasselbe Verhalten vor, behaupte ich.

Nein, das tut es nicht, die Lösung liegt an gänzlich anderer Stelle

Mache ein
use lib '/home/usw'; # das hilft bestimmt

Das hilft nicht, wenn unter Windows gearbeitet wird.

Grüße aus Berlin

Christoph S.

[Horst]

hallo,

Mache ein
use lib '/home/usw'; # das hilft bestimmt

Das hilft nicht, wenn unter Windows gearbeitet wird.

lieber Christoph, bitte sei sogut und probiere sowas aus, bevor du hier was falsches erzählst, das ist nicht OK.

Btw., unter Windows funktioniert das sogar ohne Laufwerkangabe und mit slash, anstelle Backslash.

Hotte

[Christoph Schnauß]

hallo,

lieber Christoph, bitte sei sogut und probiere sowas aus, bevor du hier was falsches erzählst, das ist nicht OK.

Ich kenne Patricks Gästebuch. Ich habe es hier.

Btw., unter Windows funktioniert das sogar ohne Laufwerkangabe und mit slash, anstelle Backslash.

Natürlich braucht es an dieser Stelle keinen Laufwerksbuchstaben, da es über / einen Ausgangspunkt gibt.

Patricks Script arbeitet derzeit aber nicht mit "use", sondern mit "require". Was er künftig vielleicht ändert, ist natürlich seine Sache.

Grüße aus Berlin

Christoph S.

[Patrick Andrieu]

Hallo Christoph!

Sorry, wenn ich so spät antworte!

Ich kenne Patricks Gästebuch. Ich habe es hier.

Ach ja? Genial! Und was machst Du damit (gleiche Frage ging auch an Struppi weiter »oben« im Thread)? ;)

Ich hoffe, Du liest noch hier alles mit und musst zugeben, dass das alles, sachichmal, etwas unverständlich ist. Mit dem Xitami gebe ich mein gewünschtes cgi-Verzeichnis im Admin-Panel an, und gut ist. Nur bei SSI ging es nicht so recht, weswegen ein anpassen der mitgelieferten perlssi-Datei notwendig war.

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo Patrick,

#!/usr/bin/perl -w

Die shebang ist dein Problem bzw. das deiner Gästebuchbenutzer. Der mit XAMPP ausgelieferte Apache hat nicht unbedingt als Voreinstellung "ScriptInterpreterSource registry", womit die shebang gelegentlich ausgehebelt werden kann. Daher suchen Webserver/Perlinterpreter nach dem in der shebang festgelegten Pfad, den sie unter Windows selbstverständlich nicht finden können.

Grüße aus Berlin

Christoph S.

[Silke]

Hallo Christoph,

Die shebang ist dein Problem bzw. das deiner Gästebuchbenutzer. Der mit XAMPP ausgelieferte Apache hat nicht unbedingt als Voreinstellung "ScriptInterpreterSource registry", womit die shebang gelegentlich ausgehebelt werden kann. Daher suchen Webserver/Perlinterpreter nach dem in der shebang festgelegten Pfad, den sie unter Windows selbstverständlich nicht finden können.

Ich habe die Einstellung "ScriptInterpreterSource registry"
und trotzdem klappt es bei mir nicht, während alles andere (z.B. Kontaktformular) bisher funktioniert.
Gruß
Silke

[Christoph Schnauß]

hallo Silke,

Ich habe die Einstellung "ScriptInterpreterSource registry"
und trotzdem klappt es bei mir nicht, während alles andere (z.B. Kontaktformular) bisher funktioniert.

Nun, ich habe auch kein XAMPP, aber ich habe natürlich Perl und Apache usw. - auch unter Windows. Kannst du denn außer "es klappt nicht" bestätigen, daß du die von Patrick angeführte Fehlermeldung bekommen hast? Und was steht korrespondierend dazu in deinem log (error.log und access.log)?

Grüße aus Berlin

Christoph S.

[Silke]

Hallo

Nun, ich habe auch kein XAMPP, aber ich habe natürlich Perl und Apache usw. - auch unter Windows. Kannst du denn außer "es klappt nicht" bestätigen, daß du die von Patrick angeführte Fehlermeldung bekommen hast? Und was steht korrespondierend dazu in deinem log (error.log und access.log)?

Es ist der von Patrick beschriebene Fehler und in der log-Datei steht
im Prinzip der gleiche Text - natürlich andere Verzeichnisse. Aber das Verzeichnis ...cgi-bin ist in der Auflistung (@inc contains ....) enthalten.
Gruß
Silke

[Struppi]

#!/usr/bin/perl -w

Die shebang ist dein Problem bzw. das deiner Gästebuchbenutzer. Der mit XAMPP ausgelieferte Apache hat nicht unbedingt als Voreinstellung "ScriptInterpreterSource registry", womit die shebang gelegentlich ausgehebelt werden kann. Daher suchen Webserver/Perlinterpreter nach dem in der shebang festgelegten Pfad, den sie unter Windows selbstverständlich nicht finden können.

Und deshalb bricht das Skript mit:
Can't locate web-lib.pl in @INC (@INC contains: X:/xampp/perl/site/lib/ X:/xampp/perl/site/lib X:/xampp/perl/lib/ . X:/xampp/apache) at X:/xampp/htdocs/cgi-bin/require_test.pl line 3.

die Ausführung ab?
Das ist doch Unsinn.

Struppi.

[Struppi]

Xampp-User berichten hier, das GB-Skript (und auch dieses Test-Skript) wirft eine Fehlermeldung 'raus:

Can't locate web-lib.pl in @INC (@INC contains: X:/xampp/perl/site/lib/ X:/xampp/perl/site/lib X:/xampp/perl/lib/ . X:/xampp/apache) at X:/xampp/htdocs/cgi-bin/require_test.pl line 3.

Dabei steht doch der Punkt ».« in @INC für das aktuelle Verzeichnis, in dem Fall also »cgi-bin«.

Das ist der Trugschluß. Das aktuelle Verzeichniss muss nicht cgi-bin sein. Das kann wohl so konfigurieren dass es nicht so ist, ist aber eher selten. Um das zu vermeiden könnte man mit FinBin das tasächlich aktuelle Verzeichniss @INC hinzugefügt werden.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Um das zu vermeiden könnte man mit FinBin das tasächlich aktuelle Verzeichniss @INC hinzugefügt werden.

Danke für den Hinweis. Wie ich feststellte, gehört das Modul zwar zur ActiveState-Perl-Installation (5.8.7), wird auch vom Autor so beschrieben: »FindBin is supported as part of the core perl distribution«, jetzt müsste man wissen, ob es auch bei Xampp der Fall ist. Den meistens Perl-unerfahrerenen Usern des GB möchte ich nämlich nicht unbedingt dazu bringen, Module zu installieren ;)

Ich schau mal, was ich lokal für Ergenisse damit erziele, und vielleicht kann Silke oder ein anderer Xampp-User, der mich angeschrieben hat, Tester spielen!

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Danke für den Hinweis. Wie ich feststellte, gehört das Modul zwar zur ActiveState-Perl-Installation (5.8.7), wird auch vom Autor so beschrieben: »FindBin is supported as part of the core perl distribution«, jetzt müsste man wissen, ob es auch bei Xampp der Fall ist. Den meistens Perl-unerfahrerenen Usern des GB möchte ich nämlich nicht unbedingt dazu bringen, Module zu installieren ;)

Also wenn du keine Standardmodule verwerndest ist Perl nur die hälfte Wert. Es geht gar nicht ohne. Zumal du schon 4 Module verwendest.

Ich schau mal, was ich lokal für Ergenisse damit erziele, und vielleicht kann Silke oder ein anderer Xampp-User, der mich angeschrieben hat, Tester spielen!

wie schon gesagt, so wie du es beschreibst ist ein Server eher selten konfiguriert, ich hab das zuletzt vor 10 Jahren auf einem kostenlosen cgi/perl Server erlebt. Das liegt also nicht unbedingt an Xampp, sondern an einer spezifischen Version oder es wurde etwas verändert.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Also wenn du keine Standardmodule verwerndest ist Perl nur die hälfte Wert. Es geht gar nicht ohne. Zumal du schon 4 Module verwendest.

Na klar, ich kenne zwar nicht alle, aber wenn was mit einem Modul zu regeln geht, mache ich das auch. Nur hieß es hier des Öfteren, dass Xampp ja eine minimale Perl-Installation mitbringt, insofern weiß ich nicht, was für Module mit einer Xampp-Installation standardmäßig dabei sind.

wie schon gesagt, so wie du es beschreibst ist ein Server eher selten konfiguriert, ich hab das zuletzt vor 10 Jahren auf einem kostenlosen cgi/perl Server erlebt. Das liegt also nicht unbedingt an Xampp, sondern an einer spezifischen Version oder es wurde etwas verändert.

Eben das verstehe ich nicht ganz... ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo,

Das ist der Trugschluß. Das aktuelle Verzeichniss muss nicht cgi-bin sein. Das kann wohl so konfigurieren dass es nicht so ist, ist aber eher selten. Um das zu vermeiden könnte man mit FinBin das tasächlich aktuelle Verzeichniss @INC hinzugefügt werden.

FindBin bringt keine Änderung, es liefert den Standard-Pfad, nicht aber den Pfad in dem das Gästebuch liegt.

Der Pfad, in dem meine cgi-bin liegt ist in @inc bereits vorhanden
(@inc contains: C:/xampp/perl/site/lib/ E:/test/cgi-bin/ . C:/xampp/apache .......).

Meine bisherigen Perl-Programme liegen in E:/test/cgi-bin/ und funktionieren einwandfrei.
Das Gästebuch von Patrick liegt in E:/test/cgi-bin/ bzw. E:/test/cgi-bin/ugb/

Gruß
Silke

[Struppi]

FindBin bringt keine Änderung, es liefert den Standard-Pfad, nicht aber den Pfad in dem das Gästebuch liegt.

sollte aber. Wo und wie verwendest du den $FinBin um den Suchpfad zu erweitern?

Der Pfad, in dem meine cgi-bin liegt ist in @inc bereits vorhanden
(@inc contains: C:/xampp/perl/site/lib/ E:/test/cgi-bin/ . C:/xampp/apache .......).

Meine bisherigen Perl-Programme liegen in E:/test/cgi-bin/ und funktionieren einwandfrei.
Das Gästebuch von Patrick liegt in E:/test/cgi-bin/ bzw. E:/test/cgi-bin/ugb/

Das Problem ist ja: ist das aktuelle Arbeitsverzeichniss, beim Aufruf des Skriptes, das in dem das skript liegt?
Kannst du das mal prüfen?

use Cwd;  
....  
print "aktuelles Arbeitsverzeichniss: ", cwd;  

Wenn es das gleiche ist sollte es eigentlich funktionieren

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Das Problem ist ja: ist das aktuelle Arbeitsverzeichniss, beim Aufruf des Skriptes, das in dem das skript liegt?

ugb ist ein Unterordner von cgi-bin. Dort liegt ugb.pl, das eigentliche Skript. Das wiederum greift auf web-lib.pl, das nun liegt im cgi-bin:

require '../web-lib.pl';

Da mir ein anderer User von den selben Problemen berichtete wie Silke, habe ich ihm dieses Test-Skript require_test.pl zukommen lassen, das sollte er aber direkt im cgi-bin kopieren. Dort ist der Aufruf:

require 'web-lib.pl';

Auch eine komplette Pfadangabe:

require 'X:\xampp\...\cgi-bin\web-lib.pl';

bringt beim User laut seiner Aussage keinen Erfolg (funktioniert auf dem Xitami-Webserver aber - natürlich mit dem entsprechenden Pfad).

Ich bin schon am Überlegen, mir Xampp zu installieren, nur möchte ich nicht, dass meine bisherige Perl-Installation davon betroffen wird. Geht das überhaupt? Vielleicht auf einem anderen Laufwerk (bisher habe ich Perl direkt auf C:, Xitami auch - mein Webordner ist auf D:).

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

ugb ist ein Unterordner von cgi-bin. Dort liegt ugb.pl, das eigentliche Skript. Das wiederum greift auf web-lib.pl, das nun liegt im cgi-bin:

require '../web-lib.pl';

Warum machst du denn sowas?

Da mir ein anderer User von den selben Problemen berichtete wie Silke, habe ich ihm dieses Test-Skript require_test.pl zukommen lassen, das sollte er aber direkt im cgi-bin kopieren. Dort ist der Aufruf:

require 'web-lib.pl';

Wenn es im gleichen Verzeichniss liegt, dann wird das Modul eingebunden

bringt beim User laut seiner Aussage keinen Erfolg

Ohne Fehlermledung läßt sich dazu nichts sagen.

Ich bin schon am Überlegen, mir Xampp zu installieren, nur möchte ich nicht, dass meine bisherige Perl-Installation davon betroffen wird. Geht das überhaupt? Vielleicht auf einem anderen Laufwerk (bisher habe ich Perl direkt auf C:, Xitami auch - mein Webordner ist auf D:).

Du kannst - soweit ich weiß-  mehrere Perl Installationen Parallel installieren. Würde ich aber nicht machen. Wie gesagt, es sieht eher so aus, als ob das was an der Serverkonfiguration nicht stimmt und ob du es schaffst den Apache dann so falsch zu konfigurieren ist wieder eine andere Frage.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

require '../web-lib.pl';
Warum machst du denn sowas?

Stammt noch aus frühren Zeiten. Heute würde das GB ohnehin ganz anders aussehen, aber web-lib.pl wird von mehreren Skripten gebraucht, deswegen habe ich das mal so im cgi-bin gelassen.

require 'web-lib.pl';

Wenn es im gleichen Verzeichniss liegt, dann wird das Modul eingebunden

Eben das geschieht bei den Xampp-Usern nicht, weswegen ich ja diesen Thread angefangen habe ;)

bringt beim User laut seiner Aussage keinen Erfolg
Ohne Fehlermledung läßt sich dazu nichts sagen.

Immer dieselbe: Can't locate ... in @INC...

Du kannst - soweit ich weiß-  mehrere Perl Installationen Parallel installieren. Würde ich aber nicht machen. Wie gesagt, es sieht eher so aus, als ob das was an der Serverkonfiguration nicht stimmt und ob du es schaffst den Apache dann so falsch zu konfigurieren ist wieder eine andere Frage.

Notfalls installiere ich es auf dem Laptop, nur der pfeift aus allen Löcher und wird nur für meine E-Mails gebraucht. Vielleicht reicht es aber für einen Versuch. Ansonsten traue ich den bisherigen Usern nicht zu, großartige Konfigurationsschritte am Xampp-Apache unternommen zu haben, es sieht eher nach Standardinstallation aus. Bei nur einem User hätte ich gedacht, der macht wohl was falsch, beim zweiten fange ich etwas an zu zweifeln, und beim Dritten... habe ich hier gepostet ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Hallo Silke!

FindBin bringt keine Änderung, es liefert den Standard-Pfad, nicht aber den Pfad in dem das Gästebuch liegt.

Die Anweisungen:

use FindBin qw($Bin);
use lib '$Bin/';

dürften aber gehen (in ugb.pl bei den anderen use-Anweisungen notieren), zumindest für config.pl. In dem Fall, diese Anweisungen ja notieren und web-lib.pl von »cgi-bin« in »cgi-bin/ugb/« kopieren... und ohne »../« einbinden:

use FindBin qw($Bin);
use lib '$Bin/';
require 'web-lib.pl';
require 'config.pl';

Meine bisherigen Perl-Programme liegen in E:/test/cgi-bin/ und funktionieren einwandfrei.

Die haben sicher kein require ''; oder greifen auf Module oder Libs, die in @INC auch gefunden werden...

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

FindBin bringt keine Änderung, es liefert den Standard-Pfad, nicht aber den Pfad in dem das Gästebuch liegt.

Die Anweisungen:

use FindBin qw($Bin);
use lib '$Bin/';

Das ist Unsinn Das Verzeichniss $Bin dürfte nicht existieren, du musst hier doppelte Anführungszeichen verwenden.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

du musst hier doppelte Anführungszeichen verwenden.

Hm, ja ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

du musst hier doppelte Anführungszeichen verwenden.

Hm, ja ;)

Quatsch, du solltest hier gar keine Anführungszeichen verwenden - mein Fehler.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Hm, ja ;)
Quatsch, du solltest hier gar keine Anführungszeichen verwenden - mein Fehler.

Doch, mein »Hm, ja« war gar nicht ironisch gemeint. Die doppelten Anführungszeichen braucht man in so einem Fall schon:

C:\Dokumente und Einstellungen\User>perl -w
use FindBin qw&$Bin&;
use lib "$Bin/desktop";
require 'web-lib.pl';
print $date;
print $/;

mit einfachen wird $Bin ja nicht interpoliert. Mein »Hm, ja« meinte her: ich sollte richtig überlegen, bevor ich zu schnell meine Posts abtippe, zumal der Abschnitt über Variableninterpolation zu den ersten gehört, die man sich beim Lernen reinzieht ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Ihr!

use FindBin qw($Bin);
use lib '$Bin/';

dürften aber gehen (in ugb.pl bei den anderen use-Anweisungen notieren), zumindest für config.pl. In dem Fall, diese Anweisungen ja notieren und web-lib.pl von »cgi-bin« in »cgi-bin/ugb/« kopieren... und ohne »../« einbinden:

use FindBin qw($Bin);
use lib '$Bin/';
require 'web-lib.pl';
require 'config.pl';

Alles obige funktioniert nicht (auch nicht mit " statt '), denn wie geschrieben wird meine @inc ergänzt um den Standard-Pfad, in dem aber keine Programme von mir liegen.

Vor der obigen Änderung:
@INC contains:
C:/xampp/perl/site/lib/
E:/test/cgi-bin                   <= hier liegt web-lib.pl und ugb
C:/xampp/perl/site/lib
C:/xampp/perl/lib
.
C:/xampp/apache)

Vor der obigen Änderung:
@INC contains:
C:/xampp/apache/bin/              <== neu
C:/xampp/perl/site/lib/
E:/test/cgi-bin                   <= hier liegt web-lib.pl und ugb
C:/xampp/perl/site/lib
C:/xampp/perl/lib
.
C:/xampp/apache)

[Patrick Andrieu]

Hallo Silke!

Alles obige funktioniert nicht (auch nicht mit " statt ')

Was ergibt die Ausgabe eines einfachen Skripts:

  
#!/usr/bin/perl -w  
  
use FindBin qw/$Bin/;  
print "Content-type: text/html\n\n";  
print $Bin;  

?

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick,

Was ergibt die Ausgabe eines einfachen Skripts:

#!/usr/bin/perl -w

use FindBin qw/$Bin/;
print "Content-type: text/html\n\n";
print $Bin;

>   
  
Ergebnis:  
C:/xampp/apache/bin  
  
  
Viele Grüße  
Silke

[Patrick Andrieu]

Hallo Silke!

Ergebnis:
C:/xampp/apache/bin

Ja. Und eben das ist IMHO nicht OK, da sollte das Verzeichnis 'rauskommen, von wo aus das Skript aufgerufen wird?

<cite>
FindBin - Locate directory of original perl script

SYNOPSIS
 use FindBin;
 use lib "$FindBin::Bin/../lib";

or

use FindBin qw($Bin);
 use lib "$Bin/../lib";
DESCRIPTION
Locates the full path to the script bin directory to allow the use of paths relative to the bin directory.
</cite>

Keine Ahnung, warum bei Xampp so eine Ausgabe erfolgt...

Was ergibt:

use Cwd;
print cwd();

?

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo,

Was ergibt:
use Cwd;
print cwd();
?

Ergebnis ist
C:/xampp

Viele Grüße
Silke

[Struppi]

Ergebnis ist
C:/xampp

Sag doch mal, wo du die einzelnen Dateien hingepackt hast?
und was bei dir das cgi-bin ist (Wissen wir schon) und das home Verzeichniss?

Struppi.

[Silke]

Hallo,

Sag doch mal, wo du die einzelnen Dateien hingepackt hast?

e:/test/formpage.html        (und meine HTML-Dokumente, die laufen)
e:/test/cgi-bin/web-lib.pl   (und meine Perl-Programme, die funktionieren)
e:/test/cgi-bin/ugb/

und was bei dir das cgi-bin ist (Wissen wir schon) und das home Verzeichniss?

Home Verzeichnis?

Gruß
Silke

[Struppi]

Sag doch mal, wo du die einzelnen Dateien hingepackt hast?
e:/test/formpage.html        (und meine HTML-Dokumente, die laufen)
e:/test/cgi-bin/web-lib.pl   (und meine Perl-Programme, die funktionieren)
e:/test/cgi-bin/ugb/

Das kann nicht sein. eben hast du noch geschrieben:

print cwd();
?

Ergebnis ist
C:/xampp

und was bei dir das cgi-bin ist (Wissen wir schon) und das home Verzeichniss?

Home Verzeichnis?

Das Verzeichniss das aufgerufen wird, wenn du localhost im Browser eingibst.

Struppi.

[Silke]

Sag doch mal, wo du die einzelnen Dateien hingepackt hast?
e:/test/formpage.html        (und meine HTML-Dokumente, die laufen)
e:/test/cgi-bin/web-lib.pl   (und meine Perl-Programme, die funktionieren)
e:/test/cgi-bin/ugb/

Das kann nicht sein. eben hast du noch geschrieben:

print cwd();
?

Ergebnis ist
C:/xampp

Das liegt wohl an der httpd.conf, s.u.

und was bei dir das cgi-bin ist (Wissen wir schon) und das home Verzeichniss?

Home Verzeichnis?

Das Verzeichniss das aufgerufen wird, wenn du localhost im Browser eingibst.

Home Verzeichnis ist E:/test

Auszug aus der httpd.conf:

DocumentRoot "E:/test"

"c:/xampp/cgi-bin" should be changed to whatever your ScriptAliased

CGI directory exists, if you have that configured.

#<Directory "c:/xampp/cgi-bin">
#    AllowOverride None
#    Options None
#    Order allow,deny
#    Allow from all
#</Directory>

<Directory "E:/test/cgi-bin">
     Options Indexes +FollowSymLinks +SymLinksifOwnerMatch Includes ExecCGI
     AllowOverride all
     Order allow,deny
     Allow from all
 </Directory>

# ScriptAlias /cgi-bin/ "c:/xampp/cgi-bin/"
 ScriptAlias /cgi-bin/ "E:/test/cgi-bin/"

Gruß
Silke

[Struppi]

ScriptAlias /cgi-bin/ "c:/xampp/cgi-bin/"

ScriptAlias /cgi-bin/ "E:/test/cgi-bin/"

Das ist klar, aber dann darf trotzdem cwd() nicht c:/xampp sein, wenn du in cgi-bin ein Skript aufrufst.

Struppi.

[Silke]

Das ist klar, aber dann darf trotzdem cwd() nicht c:/xampp sein, wenn du in cgi-bin ein Skript aufrufst.

Ist aber so! Habe es gerade mit (seriösem) Zeugen nach dem 4-Augen-Prinzip noch einmal getestet.
Silke

[Struppi]

Das ist klar, aber dann darf trotzdem cwd() nicht c:/xampp sein, wenn du in cgi-bin ein Skript aufrufst.

Ist aber so! Habe es gerade mit (seriösem) Zeugen nach dem 4-Augen-Prinzip noch einmal getestet.

So, ich hab das bei mir getestet und es ist definitiv nicht so.

So sieht mein Eintrag in der apache config aus

ScriptAlias /cgi-bin/ "C:/Programme/Apache Group/Apache/bin/"
<Directory "C:/Programme/Apache Group/Apache/bin">
        AllowOverride None
        Options None
        Order allow,deny
        Allow from all
    </Directory>

er weicht also nur leicht von deinem ab.
Das skript ist hier:
C:/Programme/Apache Group/Apache/bin/test.pl

und wird aufgerufen mit:
http://localhost/cgi-bin/test.pl

Ausgabe:
C:/Programme/Apache Group/Apache/bin

Also genau wie es sein soll.

Ich weiß das der Apache Server extrem konfigurierbar ist, aber so wie du es schilderst hättest du ziemlich dran rumschrauben müssen.

Struppi.

[Silke]

Ist aber so! Habe es gerade mit (seriösem) Zeugen nach dem 4-Augen-Prinzip noch einmal getestet.

So, ich hab das bei mir getestet und es ist definitiv nicht so.

Ja bei Dir! Aber bei mir und offensichtlich anderen leider doch.
Es sind sicher weitere Anpassungen erfolgt. Ein Bekannter, der leider nicht mehr erreichbar ist hatte es damals gemacht und er hatte auch viel in Foren herumgetobt.

[Struppi]

Ist aber so! Habe es gerade mit (seriösem) Zeugen nach dem 4-Augen-Prinzip noch einmal getestet.

So, ich hab das bei mir getestet und es ist definitiv nicht so.

Ja bei Dir! Aber bei mir und offensichtlich anderen leider doch.

Nein, das ist einfach unmöglich, das ein Skript was in Verzeichniss A liegt und von dort aufgerufen wird, B als Verzeichniss ausgibt. Du machst irgendetwas falsch.

Struppi.

[Silke]

Nichts ist unmöglich, <jap. Automarke>!

[Struppi]

Nichts ist unmöglich, <jap. Automarke>!

Wenn du meinst. Ich brauch auch keine Hilfe.

Struppi.

[Patrick Andrieu]

Hallo Silke!

Das ist klar, aber dann darf trotzdem cwd() nicht c:/xampp sein, wenn du in cgi-bin ein Skript aufrufst.»»
Ist aber so! Habe es gerade mit (seriösem) Zeugen nach dem 4-Augen-Prinzip noch einmal getestet.

Bin bald soweit. Habe eben Xampp auf dem müden Laptop [1] auf E: installiert (hier: http://www.apachefriends.org/de/xampp-windows.html#628). Nur: kein einziges Modul vorhanden!

Bin noch am Suchen, wobei ich, da ich Besuch habe, nicht die Zeit zur Verfügung habe, wie sonst.

[1] Um den aber nicht zu strapazieren greife ich vom anderen Rechner drauf, so dass keine Browserinstanz auf dem Laptop laufen muss (http://patrick2/).

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Re (kleiner Zwischenbericht)!

Nur: kein einziges Modul vorhanden!
Bin noch am Suchen, wobei ich, da ich Besuch habe, nicht die Zeit zur Verfügung habe, wie sonst.

Solele, der Addon-Installer wollte schon mal nicht, so habe ich die Module mit Hilfe des ZIP-Archivs und gewöhlichem Extrahieren kopiert, anschließend die setup_xampp.bat zum Aktualisieren aufgerufen. Module sind jetzt vorhanden und können eingebunden werden.

Direkt unter E:\xampp befinden sich, nebst anderen Verzeichnissen,:

E:
-xampp
--cgi-bin
--htdocs

In diesem cgi-bin sind Test-Skripte, eins davon, cgi.cgi habe ich erweitert:

  
#!E:\xampp\perl\bin\perl.exe  
  
use Cwd;  
use CGI::Carp qw/fatalsToBrowser);  
  
require 'web-lib.pl'; # <- habe ich ins cgi-bin kopiert  
  
print "OK<br>", $/;  
print $ENV{DOCUMENT_ROOT};  
print "<br>", $/;  
print "\@INC contains: \"@INC\"<br>", $/;  
print cwd();  
print "<br>", $/;  
print $date;         # aus web-lib.pl  
print "<br>", $/;  

Ausgabe (Aufruf vom Hauptrechner: http://patrick2/cgi-bin/cgi.cgi):

OK
E:/xampp/htdocs
@INC contains: "E:/xampp/perl/site/lib E:/xampp/perl/lib ."
E:/xampp/cgi-bin
Freitag, 4. Januar 2008 - 09.46 Uhr

Ein Ändern der Shebang in #!/usr/bin/perl bringt einen 500er, ich suche noch in den Einstellungen, wo ich das ändern kann (wenn es jemand weiß, erspart es mir aber Suchzeit *g*), genauso, wie ich einen cgi-bin-Ordner unterhalb von htdocs einrichten kann, der dann _das_ cgi-bin werden soll (also über http://patrick2/cgi-bin/ erreichbar ist).

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Nur: kein einziges Modul vorhanden!

Das kann ja kaum sein?

Solele, der Addon-Installer wollte schon mal nicht, so habe ich die Module mit Hilfe des ZIP-Archivs und gewöhlichem Extrahieren kopiert, anschließend die setup_xampp.bat zum Aktualisieren aufgerufen. Module sind jetzt vorhanden und können eingebunden werden.

Redest du von Perl Modulen?
Dann ist dieses Vorgehen extrem seltsam. Das ist doch ActiveState Perl, Gibt es kein ppm?

Ausgabe (Aufruf vom Hauptrechner: http://patrick2/cgi-bin/cgi.cgi):

OK
E:/xampp/htdocs
@INC contains: "E:/xampp/perl/site/lib E:/xampp/perl/lib ."
E:/xampp/cgi-bin
Freitag, 4. Januar 2008 - 09.46 Uhr

Ja, so sollte es sein.

Ein Ändern der Shebang in #!/usr/bin/perl bringt einen 500er, ich suche noch in den Einstellungen, wo ich das ändern kann (wenn es jemand weiß, erspart es mir aber Suchzeit *g*), genauso, wie ich einen cgi-bin-Ordner unterhalb von htdocs einrichten kann, der dann _das_ cgi-bin werden soll (also über http://patrick2/cgi-bin/ erreichbar ist).

Das sind jetzt alles Apache Fragen. Ich kann dir aber sagen, das auf einem anders konfigurierten Apache das Skript tadellos läuft. Warum das manchen nicht so ist, läßt sich mnangels mithilfe wohl nicht mehr herrausfinden.

Frage 1:
ScriptInterpreterSource registry

Frage 2
ScriptAlias /cgi-bin/ "E:/xampp/htdocs/cgi-bin"

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Nur: kein einziges Modul vorhanden!
Das kann ja kaum sein?

Da habe ich mich gestern auch gewundert. Unter E:\xampp\perl stand eine einsame, traurige perl.exe - sonst nichts.

Ich rede von dieser Installation:
http://www.apachefriends.org/de/xampp-windows.html#628,
XAMPP für Windows 1.6.5 vom 24.12.2007

Version
Größe
Inhalt
XAMPP Windows 1.6.5
[Basispaket]   Apache HTTPD 2.2.6, MySQL 5.0.51, PHP 5.2.5 + 4.4.7 + PEAR + Switch, MiniPerl 5.8.7, Openssl 0.9.8g, PHPMyAdmin 2.11.3, XAMPP Control Panel 2.5, Webalizer 2.01-10, Mercury Mail Transport System v4.52, FileZilla FTP Server 0.9.24, SQLite 2.8.15, ADODB 4.96, Zend Optimizer 3.3.0, XAMPP Security, Ming. Für Windows 98, 2000, XP. Siehe README
Installer  33 MB  Installer-Version
MD5 checksum: 9ad46876110d81e62f6945083c34c71f

Solele, der Addon-Installer wollte schon mal nicht,

von diesem Addon:

http://www.apachefriends.org/de/xampp-windows.html#629,
Perl 5.8.8-2.2.4
XAMPP 1.6.x
Apache 2.2.4   Mod_Perl funktioniert nicht mit Apache 2.2.6 (XAMPP 1.6.4)!
Perl 5.8.8 + mod_perl 2.0.3 Addon für das XAMPP Paket 1.6.x und den Apache 2.2.4. Für NT, 2000 oder XP Systeme. Für frühere XAMPP Pakete gibt es die älteren Perl Add-ons unter www.sourceforge.net (Last Update: 2007-03-27)
Docs: README + PPM Module Inside
Installer  61 MB  Installer-Version
MD5 checksum: 1add4101c78cb1daa28d7bf92b8912a3

so habe ich die Module mit Hilfe des ZIP-Archivs

und dem darunter ebenfalls zum Dowload angebotenen ZIP-Archiv, das ich dann wie erwähnt manuell extrahiert habe. Xampp anschließend aktualisiert durch Aufrufen der setup_xampp.bat.

Dann ist dieses Vorgehen extrem seltsam. Das ist doch ActiveState Perl, Gibt es kein ppm?

Keine Ahnung, was für ein Perl (auf den Seiten ist von »MiniPerl« die Rede)...

OK
E:/xampp/htdocs
@INC contains: "E:/xampp/perl/site/lib E:/xampp/perl/lib ."
E:/xampp/cgi-bin
Freitag, 4. Januar 2008 - 09.46 Uhr

Ja, so sollte es sein.

So weit, so gut, ja...

Frage 1:
ScriptInterpreterSource registry

Frage 2
ScriptAlias /cgi-bin/ "E:/xampp/htdocs/cgi-bin"

Ah danke. Ich hatte noch keine Gelegenheit, mich mit der Konfiguration zu beschäftigen, hoffentlich packe ich das heute...

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Re Struppi!

@INC contains: "E:/xampp/perl/site/lib E:/xampp/perl/lib ."

Sollte auch korrekt sein, gestern, vor der Modul-Install-Aktion, warf das Skript nur den Punkt ».« als Inhalt von @INC raus.

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Nur: kein einziges Modul vorhanden!
Das kann ja kaum sein?

Da habe ich mich gestern auch gewundert. Unter E:\xampp\perl stand eine einsame, traurige perl.exe - sonst nichts.

Ich würde mal sagen, dass Paket ist soweit ich das sehe, um irgendwas mit Perl zu machen völlig ungeeignet. Wenn noch nicht mal die minimalen Standardpakete vorhanden sind, macht das keinen Sinn.

Keine Ahnung, was für ein Perl (auf den Seiten ist von »MiniPerl« die Rede)...

Kann ich auch nichts mit anfangen.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Frage 2
ScriptAlias /cgi-bin/ "E:/xampp/htdocs/cgi-bin"

Das habe ich geändert, das ist jetzt OK. Das Skript aus meinem vorigen Post (cgi.cgi) mit dem vollen Pfad in der Shebang bringt aus Ausgabe:

OK
E:/xampp/htdocs
@INC contains: "E:/xampp/perl/site/lib E:/xampp/perl/lib ."
E:/xampp/htdocs/cgi-bin
Freitag, 4. Januar 2008 - 16.21 Uhr
E:/xampp/htdocs/cgi-bin/cgi.cgi
5.008008

Frage 1:
ScriptInterpreterSource registry

cgi.cgi als cgi.pl kopiert mit Shebang: #!/usr/bin/perl

Das allerdings bringt den Apache zum Absturz. Hier nehme ich aber an, dass es damit zu tun hat, dass ich ja noch meine erste Perl-Installation auf dem Laptop habe (auf C:). Oder liegt es doch an etwas anders (bevor ich in der Registry rumpfusche... *g*)?

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Frage 1:
ScriptInterpreterSource registry

cgi.cgi als cgi.pl kopiert mit Shebang: #!/usr/bin/perl

Das allerdings bringt den Apache zum Absturz. Hier nehme ich aber an, dass es damit zu tun hat, dass ich ja noch meine erste Perl-Installation auf dem Laptop habe (auf C:). Oder liegt es doch an etwas anders (bevor ich in der Registry rumpfusche... *g*)?

Du musst eine (welche dürfte egal sein) Perl installation haben, die in der Registry eingetragen ist. Also die die startet, wenn du eine .pl Datei einen Doppelklick machst.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Du musst eine (welche dürfte egal sein) Perl installation haben, die in der Registry eingetragen ist. Also die die startet, wenn du eine .pl Datei einen Doppelklick machst.

Ja, .pl ist »verknüpft« mit perl.exe (C:\Perl\bin\perl.exe). Von der Perl-Installation, die xampp auf E:\xampp\perl\bin\perl.exe mitgebracht hat, ist in der Registry nichts zu sehen. Alle Einträge (shell->open->command) beinhalten den Pfad C:\Perl\bin\perl.exe ... .

Mich juckt's zu probieren, was denn passiert, wenn ich all diese Einträge in E:\xampp\perl\bin\perl.exe ... abändere, dafür brauche ich aber Ruhe (bis Dienstag nicht gegeben).

BTW: Die Ausgabe hier zeigt sehr wohl, dass die web-lib.pl gefunden wird:

E:
-xampp
--htdocs
---cgi-bin
----web-lib.pl
----test
-----cgi.cgi

Also web-lib.pl in /htdocs/cgi-bin und cgi.cgi in /htdocs/cgi-bin/test:

  
#!"E:\xampp\perl\bin\perl.exe"  
  
use Cwd;  
use FindBin qw/$Bin/;  
use CGI qw(header);  
use CGI::Carp qw(fatalsToBrowser);  
  
require '../web-lib.pl';  
  
print "Content-Type: text/html\n\n";  
  
  
print "OK<br>\n";  
print "Root is: ", $ENV{DOCUMENT_ROOT};  
print "<br>", $/;  
print "\@INC contains: \"@INC\"<br>", $/;  
print "CWD is: ", cwd();  
print "<br>", $/;  
print "Datum aus web-lib.pl ermittelt ist: ", $date;  
print "<br>", $/;  
print "\$0 is: ", $0, "<br>", $/;  
print "Perl Version is: ", $], "<br>", $/;  
print "\$FindBin::Bin is: ", $Bin, "<br>", $/;  

Ausgabe im Browser:
OK
Root is: E:/xampp/htdocs
@INC contains: "E:/xampp/perl/site/lib E:/xampp/perl/lib ."
CWD is: E:/xampp/htdocs/cgi-bin/test
Datum aus web-lib.pl ermittelt ist: Samstag, 5. Januar 2008 - 10.34 Uhr
$0 is: E:/xampp/htdocs/cgi-bin/test/cgi.cgi
Perl Version is: 5.008008
$FindBin::Bin is: E:/xampp/htdocs/cgi-bin/test

Fehlt, wie gesagt, der Test mit der »richtigen« Shebang, um zu sehen, ob was an Christophs Hinweis dran ist und es evtl. doch daran liegt.

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Du musst eine (welche dürfte egal sein) Perl installation haben, die in der Registry eingetragen ist. Also die die startet, wenn du eine .pl Datei einen Doppelklick machst.

Ja, .pl ist »verknüpft« mit perl.exe (C:\Perl\bin\perl.exe). Von der Perl-Installation, die xampp auf E:\xampp\perl\bin\perl.exe mitgebracht hat, ist in der Registry nichts zu sehen. Alle Einträge (shell->open->command) beinhalten den Pfad C:\Perl\bin\perl.exe ... .

D.h. wenn du eine pl datei startest wird diese mit der Perlversion gestartet?
Dann sollte der Apache nicht abstürzen, seltsam.

Mich juckt's zu probieren, was denn passiert, wenn ich all diese Einträge in E:\xampp\perl\bin\perl.exe ... abändere, dafür brauche ich aber Ruhe (bis Dienstag nicht gegeben).

Soweit ich das sehe macht ActivePerl einen Eintrag HKCR->Perl->Shell->Open->Command
und der PATH wird erweitert.

Fehlt, wie gesagt, der Test mit der »richtigen« Shebang, um zu sehen, ob was an Christophs Hinweis dran ist und es evtl. doch daran liegt.

Nein, du hast ja die richtige Shebang Zeile, die exakt auf die Perl Version die bei einer xampp Installation dabei ist, zeigt. Wenn du den Apache Server anpasst, wird die Zeile einfach ignoriert und das Perl das in der Registry eingetragen ist gestartet. Warum dein Apache dann abstürzt ist mir nicht klar, steht vielleicht im errorg log?

Struppi.

[Patrick Andrieu]

Hallo Struppi!

D.h. wenn du eine pl datei startest wird diese mit der Perlversion gestartet?

Ja. Doppelklick auf eine .pl-Datei öffnet cmd.exe mit in der Titelleiste:
C:\Perl\bin\perl.exe

Dann sollte der Apache nicht abstürzen, seltsam.

... ;)

Soweit ich das sehe macht ActivePerl einen Eintrag HKCR->Perl->Shell->Open->Command

Ja auch in HKLM. Insgesamt habe ich den Pfad C:\Perl\bin\perl.exe (plus Erweiterungen im Stil von %irgendwas) an 4 oder 5 verschiedenen Stellen gefunden.

Wenn du den Apache Server anpasst, wird die Zeile einfach ignoriert und das Perl das in der Registry eingetragen ist gestartet.

Aargh, ja, so steht es auch in der httpd.conf erklärt, sorry.

Warum dein Apache dann abstürzt ist mir nicht klar, steht vielleicht im errorg log?

Gut... cgi.pl mit der Unix-Shebang in E:\xampp\htdocs\cgi-bin
       Aufruf um 11:50 Uhr (IE): http://patrick2/cgi-bin/cgi.pl

IE bringt: Server nicht gefunden

Errorlog-Einträge:
[Sat Jan 05 11:50:32 2008] [notice] Child 3868: Child process is running
[Sat Jan 05 11:50:32 2008] [notice] Child 3868: Acquired the start mutex.
[Sat Jan 05 11:50:32 2008] [notice] Child 3868: Starting 250 worker threads.
[Sat Jan 05 11:50:32 2008] [notice] Child 3868: Starting thread to listen on port 443.
[Sat Jan 05 11:50:32 2008] [notice] Child 3868: Starting thread to listen on port 80.
[Sat Jan 05 11:50:37 2008] [notice] Parent: child process exited with status 9 -- Restarting.

Aufruf um 12:00 Uhr (Firefox): http://patrick2/cgi-bin/cgi.pl

Firefox leitet mich auf http://www.patrick2.com/ um (LOL),

Errorlog-Eintrag:
[Sat Jan 05 12:00:27 2008] [notice] Parent: child process exited with status 9 -- Restarting.

Ich als Apache-Neuling kann mir keinen Reim machen... Mit dem Xitami hatte ich nie Probleme, nur dass (zumindest bei meiner Version, soll bei den neueren anders sein), die SSI-Implementierung miserabel war, was mich ja zu dem einen Feature-Artikel bewegt hatte.

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Warum dein Apache dann abstürzt ist mir nicht klar, steht vielleicht im errorg log?

Gut... cgi.pl mit der Unix-Shebang in E:\xampp\htdocs\cgi-bin
       Aufruf um 11:50 Uhr (IE): http://patrick2/cgi-bin/cgi.pl

IE bringt: Server nicht gefunden

Ich dachte der Server stürzt ab?

[Sat Jan 05 11:50:37 2008] [notice] Parent: child process exited with status 9 -- Restarting.

Da liegt wohl das Problem.

Aufruf um 12:00 Uhr (Firefox): http://patrick2/cgi-bin/cgi.pl

Firefox leitet mich auf http://www.patrick2.com/ um (LOL),

Das liegt wohl an der Konfiguration des Apache, da bin ich aber auch nicht so der Experte.

Errorlog-Eintrag:
[Sat Jan 05 12:00:27 2008] [notice] Parent: child process exited with status 9 -- Restarting.

Wenn ich das richtig deute, kann aus irgendeinem Grund der Server das Perl nicht startet.

Ich als Apache-Neuling kann mir keinen Reim machen... Mit dem Xitami hatte ich nie Probleme,

ich kenn den nicht, aber der Apache ist halt enorm mächtig und läßt sich viel konfigurieren, aber das macht es auch relativ kompliziert

Struppi.

[Patrick Andrieu]

Hallo Struppi!

IE bringt: Server nicht gefunden

Ich dachte der Server stürzt ab?

Tut er auch. Den IE habe ich auf dem Hauptrechner geöffnet (patrick1 oder 192.168.0.1), den Xampp-Server auf dem Laptop (patrick2 oder 192.168.0.2).

Auf dem Laptop poppt dann das Windwows-Fenster »Sofort beenden« auf - aber auch nicht immer.

Doch die Error-Log zeigt wohl, dass der Server abstürzt (wozu sonst »restarting«?), und deswegen kommt dann bei IE »Server nicht gefunden«.

Warum der Firefox da umleitet, weiß ich nicht, ich denke aber eher, dass der sich eine passende URL selber sucht. Wenn ich das Skript über die Laptop-Netzwerk-IP aufrufe:

http://192.168.0.2/cgi-bin/cgi.pl

bekomme ich:

Seiten-Ladefehler

Fehler: Verbindung unterbrochen

Was passiert also? Der Aufruf bringt den Apache zum Exitus, danach ist logischerweise die Verbindung unterbrochen bzw. den Server nicht gefunden.

[Sat Jan 05 11:50:37 2008] [notice] Parent: child process exited with status 9 -- Restarting.

Da liegt wohl das Problem.

Japp. Aber was bedeutet status 9, und warum ist es so? Wenn man das wüßte, könnte man u.U. Gegenmaßnahmen ergreifen...

ich kenn den nicht, aber der Apache ist halt enorm mächtig und läßt sich viel konfigurieren, aber das macht es auch relativ kompliziert

Den Apache installieren wollte ich eh schon länger. Diese Sache hat mir den richtigen Tritt in den Allerwertesten gegeben, es zu tun, auch wenn ich ursprünglich vor hatte, vorher Linux zu installieren.

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

[Sat Jan 05 11:50:37 2008] [notice] Parent: child process exited with status 9 -- Restarting.

Da liegt wohl das Problem.

Japp. Aber was bedeutet status 9, und warum ist es so? Wenn man das wüßte, könnte man u.U. Gegenmaßnahmen ergreifen...

Evtl. gibt es Probleme weil die verschiedenen Perlversionen auch die PATH Variabel setzten. Gib mal im DOS Fenster "set path" ein.

Den Apache installieren wollte ich eh schon länger. Diese Sache hat mir den richtigen Tritt in den Allerwertesten gegeben, es zu tun, auch wenn ich ursprünglich vor hatte, vorher Linux zu installieren.

Sei froh, unter Linux ist er vermutlich leichter zu konfigurieren ;-)

Struppi.

[Struppi]

Japp. Aber was bedeutet status 9, und warum ist es so? Wenn man das wüßte, könnte man u.U. Gegenmaßnahmen ergreifen...

Wir hätten vielleicht auch mal die Doku zu Rate ziehen sollen:
http://httpd.apache.org/docs/2.0/mod/core.html#scriptinterpretersource
(Abschnitt Sicherheit)

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Wir hätten vielleicht auch mal die Doku zu Rate ziehen sollen:

Ja, vielleicht hätten wir. Doch:

http://httpd.apache.org/docs/2.0/mod/core.html#scriptinterpretersource
(Abschnitt Sicherheit)

den ich hier zi- und kommentiere (*g für das ungewöhnliche ku-pie-ren*):

DOKU: Die Einstellung Registry kann unerwünschte Programmaufrufe bei Dateien verursachen, die üblicherweise nicht ausgeführt werden.

Eine .pl-Datei wird aber ausgeführt. Oder etwa nicht?

DOKU: Auf den meisten Windows-Systemen beispielsweise startet der voreingestellte Öffnen-Befehl für .htm-Dateien den Microsoft Internet Explorer, so dass jede HTTP-Anfrage nach einer existierenden .htm-Datei im Skript-Verzeichnis den Browser auf dem Server im Hintergrund starten würde.

Ich starte aber keine .htm-Datei-Anfrage. So dass:

DOKU: Dies ist leichte Art und Weise, Ihr System binnen etwa einer Minute zum Absturz zu bringen.´

Das nicht zutreffen dürfte, oder? Wird ja im gleichen Atemzug mit der .htm-Anfrage genannt.

Wie schaffen das die Anderen, Silke?

Und dann:

DOKU: Die seit Apache 2.0 neue Option Registry-Strict macht das gleiche wie Registry, verwendet jedoch nur den Unterschlüssel Shell\ExecCGI\Command. Der Schlüssel ExecCGI ist gewöhnlich nicht voreingestellt. Er muss manuell in der Windows-Registrierungsdatenbank eingerichtet werden und verhindert dann versehentlicht Programmaufrufe auf Ihrem System.

Wo »manuell«? In der Registry pfusche ich nur 'rum, wenn ich weiß, was und vor allem wo ich etwas tue...

Aber für Deine Hartnäckigkeit in diesem Fall verdienst Du ein ganz dickes Lob, Struppi, das hat mich schon ein ganz weites Stück weiter gebracht. Ich werde mich morgen weiter mit der Geschichte beschäftigen, heute kein Nerv mehr dazu...

Struppi.

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

den ich hier zi- und kommentiere (*g für das ungewöhnliche ku-pie-ren*):

DOKU: Die Einstellung Registry kann unerwünschte Programmaufrufe bei Dateien verursachen, die üblicherweise nicht ausgeführt werden.

Eine .pl-Datei wird aber ausgeführt. Oder etwa nicht?

JA, aber die Doku meint es auch anders und ich hab es beim schnell lesen auch falsch gedeutet. Der Hinweis beschreibt ein anders Problem.

Wie schaffen das die Anderen, Silke?

Was heißt Silke, bei mir ist diese Direktive ebenfalls aktiv und ohne Probleme.

DOKU: Die seit Apache 2.0 neue Option Registry-Strict macht das gleiche wie Registry, verwendet jedoch nur den Unterschlüssel Shell\ExecCGI\Command. Der Schlüssel ExecCGI ist gewöhnlich nicht voreingestellt. Er muss manuell in der Windows-Registrierungsdatenbank eingerichtet werden und verhindert dann versehentlicht Programmaufrufe auf Ihrem System.

Wo »manuell«? In der Registry pfusche ich nur 'rum, wenn ich weiß, was und vor allem wo ich etwas tue...

Der Schlüssel wird von dem Installationsprogramm der Perlversion eingetragen.

Aber für Deine Hartnäckigkeit in diesem Fall verdienst Du ein ganz dickes Lob, Struppi, das hat mich schon ein ganz weites Stück weiter gebracht. Ich werde mich morgen weiter mit der Geschichte beschäftigen, heute kein Nerv mehr dazu...

Ich hatte durchaus auch Schwierigkeiten beim konfigurieren des Servers, daher kann ich die Probleme nachvollziehen.

So - ich muss jetzt aber auch mal weg, morgen früh wird im Rheingau gwandert!

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Wo »manuell«? In der Registry pfusche ich nur 'rum, wenn ich weiß, was und vor allem wo ich etwas tue...
Der Schlüssel wird von dem Installationsprogramm der Perlversion eingetragen.

Ich habe gestern regedit gestartet und nach »perl« gesucht (siehe früheren Post), doch keinen einzigen Schlüssel ExecCGI gefunden. Musstest Du denn händisch irgend etwas nachtragen? Glaubst Du, dass die unerfahrenen User, die mich angemailt haben, etwas in der Registry geändert haben? Warum funzt(TM) denn alles bei mir nicht?

Mir ist die ganze Angelegenheit dermaßen unverständlich. Ich traue mir zwar zu, die Probleme bei mir lokal zu beheben, aber... wie soll ich auf zukünftige Anfragen antworten?

So - ich muss jetzt aber auch mal weg, morgen früh wird im Rheingau gwandert!

Also vom »gwandert« aus zu schließen, wäre Orlandos Heimat eher geeignet. Aber gut, Rheingau kann auch zum GAU werden ;)

Viel Spaß wünscht Dir mit
vielen Grüßen aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

<Directory "E:/xampp/htdocs/cgi-bin">
    AllowOverride None
    Options ExecCGI                  # in dieser Zeile stand die ganze Zeit »Options None«
    Order allow,deny
    Allow from all
</Directory>

Ohne Worte... aber warum sagt mir das keiner? ;)

Jetzt funzt's(TM). Und auch keine Probs mit require!

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Ich zitierte hier aus der Xitami-Doku:

<cite>To provide compatibility with Perl scripts coming from UNIX, Xitami will handle a path like '/usr/bin/perl' by removing '/usr/bin/' and looking for PERL.EXE on the PATH, if /usr/bin/perl does not actually exist as a file.</cite>

Anscheinend handelt es der Apache genauso und die Shebang wird, entgegen der Erläuterungen hier NICHT ignoriert, sondern manipuliert!

Ein Skript mit der Endung .pl und mit als Shebang:

#!/was/das/fuern/murks -w

liefert einen 500er.

Ändert man die Shebang in:

#!/was/das/fuern/murks/mit/perl -w

funzt(TM) das Skript.

Und nachdem es wirklich daran lag, dass ich Option ExecCGI vergessen hatte, kann ich, je nach Skriptdateiendung, mit meinen zwei Perl-Versionen spielen:

.cgi (Shebang: #!"E:\xampp\perl\bin\perl.exe"):

Perl Version is: 5.008008
@INC contains: "E:/xampp/perl/site/lib E:/xampp/perl/lib ."

.pl (Shebang: #!/is/doch/egal/hauptsache/perl)

Perl Version is: 5.008007
@INC contains: "C:/Perl/lib C:/Perl/site/lib ."

;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo Patrick,

Anscheinend handelt es der Apache genauso und die Shebang wird, entgegen der Erläuterungen hier NICHT ignoriert, sondern manipuliert!

Nein, da muß ich ich energisch widersprechen. An der shebang wird nichts manipuliert, allerdings ist die zitierte Aussage in meinem Artikel tatsächlch nicht absolut korrekt.

Ein Skript mit der Endung .pl und mit als Shebang:
#!/was/das/fuern/murks -w
liefert einen 500er.
Ändert man die Shebang in:
#!/was/das/fuern/murks/mit/perl -w
funzt(TM) das Skript.

Tatsächlich "funzt" das auch mit einem unsinnigen Pfad. Die sheabng _muß_ einen Namen enthalten, der vom Apache als Perl-Interpreter akzeptiert wird, also entweder "perl" oder eben "perl.exe". Die Einstellung "ScriptInterpreterSource registry" bewirkt, daß der Apache, falls er unter dem in der shebang angegebenen Pfad nix findet, dann eben in der registry nachschaut. _Irgendein_ Pfad muß aber angegeben sein. Weglassen kannst du die shebang nicht.

Und nachdem es wirklich daran lag, dass ich Option ExecCGI vergessen hatte

Tut mir leid, da komme ich mit meinem entsprechenden Hinweis zu spät :-(

Grüße aus Berlin

Christoph S.

[Patrick Andrieu]

Hallo Christoph!

Tatsächlich "funzt" das auch mit einem unsinnigen Pfad. Die sheabng _muß_ einen Namen enthalten, der vom Apache als Perl-Interpreter akzeptiert wird

Wer mich kennt, kennt mich als erbarmungsloser Tester (frag Struppi, als es um Time::HighRes ging *g*).

Alle folgende Shebangs funzen(TM):

#!perlhuhn
#!/ich/mag/keine/perlenketten
#!perl
#!/egal/wo/perl/steht/hauptsache/es/steht/in/der/shebang

Weglassen kannst du die shebang nicht.

Eben. Deswegem wird sie nicht ignoriert, sondern vermutlich regexp-mässig auseinandergenommen... Wenn »perl« innerhalb des Shebang-String gefunden wird, dann BINGO, der Perl-Interpreter wird gerufen ;)

#!rebhuhn

funzt nämlich nicht *fG*

Tut mir leid, da komme ich mit meinem entsprechenden Hinweis zu spät :-(

Ma, da freue ich mich trotzdem, habe ich es doch selber herausgefunden :)

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

wie ist denn jetzt der Stand der Dinge? Wie kriege ich Perl bei mir zum laufen?
Ich hab derzeit alles rausgeschmissen, was ich drauf hatte und xampp neu draufgepackt.
Vielleicht könnt ihr ja ein kurzes Tut dazu schreiben, wenn ihr die lösung habt.

Xampp ist echt zu blöde, Perl geht irgendwie garnicht (nur diese test.pl), einige wichtige PHP funktionen geben
fehlermeldungen aus.

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

wie ist denn jetzt der Stand der Dinge? Wie kriege ich Perl bei mir zum laufen?

Das ist hier zu lesen:
https://forum.selfhtml.org/?t=164295&m=1071350 ff.

Ich hab derzeit alles rausgeschmissen, was ich drauf hatte und xampp neu draufgepackt.

Gut, nehm gleich die Version und das Addon (als ZIP, falls der Addon-Installer immer noch nicht »geht«) und installiere die Module.

Dann hast du diese Strukur:

Laufwerk (Ich nenne ihn hier X:):
-xampp
--Menge Ordner... unter anderem:
--cgi-bin
--htdocs
---xampp

Per default ist das cgi-bin eben dieses außerhalb von htdocs und direkt unter xampp. Wenn du http://localhost aurufst, sorgt die index.php in X:\xampp\htdocs für eine Umleitung auf X:\xampp\htdocs\xampp

Mit http://localhost/cgi-bin/cgi.cgi rufst Du das Skript cgi.cgi, das sich in X:\xampp\cgi-bin befindet.

Nach der Installation aus dieser Adresse:
http://www.apachefriends.org/de/xampp-windows.html#628
hast Du unter X:\xampp\perl nur die Datei perl.exe

Weiter unten auf der selben Seiten findest Du die addons, Du musst noch das Perl-Addon installieren (was, wie erwähnt, mit dem Installer nicht klappte, aber mit dem ZIP-Archiv).

Wenn Du einen anderen Default-cgi-bin willst, das sich innerhalb von htdocs befindet, musst Du den Ordner erstellen und (siehe Antwort von Struppi) mittels ScriptAlias-Direktive in der httpd.conf (in /xampp/apache/conf) zum Default machen.

Dann kannst Du Perl-Skripte erstmal laufen lassen.

Xampp ist echt zu blöde, Perl geht irgendwie garnicht (nur diese test.pl),

Wahrscheinlich fehlen die Module.

einige wichtige PHP funktionen geben fehlermeldungen aus.

Dazu kann ich leider nichts sagen... :)

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Re!

Weiter unten auf der selben Seiten findest Du die addons, Du musst noch das Perl-Addon installieren (was, wie erwähnt, mit dem Installer nicht klappte, aber mit dem ZIP-Archiv).

Nachdem das ZIP-Archiv entpackt wurde, musst Du die setup_xampp.bat _einmal_ aufrufen.

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick!

Weiter unten auf der selben Seiten findest Du die addons, Du musst noch das Perl-Addon installieren (was, wie erwähnt, mit dem Installer nicht klappte, aber mit dem ZIP-Archiv).

Darauf hatte ich garnicht gechtet.

Weiter unten auf der selben Seiten findest Du die addons, Du musst noch das Perl-Addon installieren (was, wie erwähnt, mit dem Installer nicht klappte, aber mit dem ZIP-Archiv).

Nachdem das ZIP-Archiv entpackt wurde, musst Du die setup_xampp.bat _einmal_ aufrufen.

Das klingt doch schon sehr viel verspechend, werde es Heute Abend testen, geh jetzt erstmal schlafen.

Funktioniert es denn jetzt bei dir reibungslos? Und wie findest du xampp?
Wenn du dir vhosts anlegen möchtest, sag bescheid, da kann ich dir meine conf DAtei hochladen,
da sind schon 7 Vhosts eingetragen, müsstest nur die Namen ändern und Fertig.

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

Darauf hatte ich garnicht gechtet.

Du muss auch nicht drauf gechten, sondern nur drauf achten ;)

Heute Abend testen, geh jetzt erstmal schlafen.

Aber hallo, ab in die Heia, es ist schon spät, deswegen spätstücke ich gleich.

Funktioniert es denn jetzt bei dir reibungslos? Und wie findest du xampp?

Was ich haben wollte, funktioniert jetzt. Auf dem Hautprechner werde ich vermutlich eine richtige Apache-Installation vornehmen, aber erst mit Xampp auf dem Schleppi eine Weile 'rumtesten.

Wenn du dir vhosts anlegen möchtest,

Das wird der nächste Test sein, wenn ich mit der Korrekturlesung einiger Dateien für SELFHMTL fr. fertig bin.

sag bescheid, da kann ich dir meine conf DAtei hochladen,

Kann nicht schaden, danke!

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Darauf hatte ich garnicht gechtet.

Du muss auch nicht drauf gechten, sondern nur drauf achten ;)

Kennst mich doch, ich gecht auf alles. :)

Aber hallo, ab in die Heia, es ist schon spät, deswegen spätstücke ich gleich.

Meine Musch äähh Katze macht mich noch Wahnsinnig, die lässt mich nicht schlafen.

sag bescheid, da kann ich dir meine conf DAtei hochladen,

Kann nicht schaden, danke!

Hab in das /china Verzeichnis einen Ordner /vhosts abgelegt mit 2 Dateien, in der httpd-vhosts ist in einem Rauteblock
ne kurze Anleitung, was du machen musst.

Was da nicht steht ist, das du nachdem du alle Dateien fertig eingerichtet hast Windoof neu starten musst,
sonst geht es nicht.

So, und jetzt wollen ma sehen, ob wir Perl hier zum Perlen kriegen.

Grüße,
Engin
 GYRO

[Engin]

Hi Patrick!

So, und jetzt wollen ma sehen, ob wir Perl hier zum Perlen kriegen.

So, und noch ne ganz Doofe frage hinten drangestellt, wo wird

"Can't locate ../web-lib.pl in @INC (@INC contains: C:/xampp/perl/site/lib C:/xampp/perl/lib .) at C:/xampp/cgi-bin/ugb/ugb.pl line 7."

das hier durchgekaut. Ich hab ein wenig den überblick hier verloren.

Kurz zu meiner Hirarchie,

C:\xampp
   --anonymous   # hier befinden sich meine Vhosts verzeichnisse
   --perl
   --htdocs
   --cgi-bin

ServerAlias ist default.

C:\Perl    # ActivePerl

Grüße,
Engin
 GYRO

[Struppi]

So, und noch ne ganz Doofe frage hinten drangestellt, wo wird

"Can't locate ../web-lib.pl in @INC (@INC contains: C:/xampp/perl/site/lib C:/xampp/perl/lib .) at C:/xampp/cgi-bin/ugb/ugb.pl line 7."

das hier durchgekaut. Ich hab ein wenig den überblick hier verloren.

Nirgends, es war für uns bisher nicht nachvollziehbar, wieso diese Meldung auftaucht. (Das Problem ist auch das Skript, ein Modul aus einem tiefer liegendem Verzeichniss zu laden ist nicht üblich)

Kurz zu meiner Hirarchie,

C:\xampp
   --anonymous   # hier befinden sich meine Vhosts verzeichnisse
   --perl
   --htdocs
   --cgi-bin

ServerAlias ist default.

C:\Perl    # ActivePerl

Das ist soweit klar - wir müssen Wissen wo genau auf der Platte das Skript liegt und wo dies nach Modulen sucht (@INC), Patrick hat hier ein Skript gepostet mit dessen Ausgabe es eiegnetlich möglich sein müßte weiter zu kommen (aber bisher nicht ist):

#!/usr/bin/perl -w  
use strict;  
use Cwd;  
use FindBin qw/$Bin/;  
use CGI qw(header);  
use CGI::Carp qw(fatalsToBrowser);  
use constant NL => "\n";  
  
print header,  '<pre>',  
'Root is: ', $ENV{DOCUMENT_ROOT}, NL,  
'@INC contains: ', @INC,  NL,  
'CWD is: ', cwd(), NL,  
'$0 is: ', $0, NL,  
'Perl Version is: ', $], NL,  
'$FindBin::Bin is: ', $Bin, NL,  
'PATH is: ', $ENV{PATH}, NL,  
'</pre>';  

Struppi.

[Engin]

Hi Struppi,

Das ist soweit klar - wir müssen Wissen wo genau auf der Platte das Skript liegt und wo dies nach Modulen sucht (@INC), Patrick hat hier ein Skript gepostet mit dessen Ausgabe es eiegnetlich möglich sein müßte weiter zu kommen (aber bisher nicht ist):

Das Script (ugb.pl) liegt in C:\xampp\cgi-bin\ugb\ugb.pl

Ich hatte die bsp. scripts die Patrick hier gepostet hat (mit $Bin und Cwd) schon ausprobiert,
nur dann kommt

"Fehlermeldung: couldn't create child process: 720003: test.pl"

bei beiden Scripten, bei deinem übrigens auch.

Sorry, grade mal die shebang anders probiert und siehe da,
#!"C:\xampp\perl\bin\perl.exe"

Root is: C:/xampp/anonymous/nimmet  
@INC contains: C:/xampp/perl/site/libC:/xampp/perl/lib.  
CWD is: C:/xampp/cgi-bin  
$0 is: C:/xampp/cgi-bin/test.pl  
Perl Version is: 5.008008  
$FindBin::Bin is: C:/xampp/cgi-bin  
PATH is: C:\xampp\bin\;C:\Perl\site\bin;C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\QuickTime\QTSystem\;C:\Programme\Gemeinsame Dateien\GTK\2.0\bin

Auch ging jetzt Patricks Script mit Cwd, das gibt aus

C:/xampp/cgi-bin

Das GB geht aber auch nicht mit dieser shebang.

Ich versuche das cgi-bin verzeichnis über meine Vhosts aufzurufen, die
Verzeichnisse meiner Vhosts liegen in C:\xampp\anonymous -  da hat dann jeder Vhost sein eigenes Verzeichnis.

Grüße,
Engin
 GYRO

[Struppi]

Sorry, grade mal die shebang anders probiert und siehe da,
#!"C:\xampp\perl\bin\perl.exe"

Da gibt es auch eine Option für den Apache, wurde hier auch schon angesprochen (viel Spaß beim suchen ;-) )

Root is: C:/xampp/anonymous/nimmet

@INC contains: C:/xampp/perl/site/libC:/xampp/perl/lib.
CWD is: C:/xampp/cgi-bin
$0 is: C:/xampp/cgi-bin/test.pl

  
Das ist zumindest mal ein Ausgabe die nachvollziehbar ist (im gegensatz zu der von Silke)  
  
Wenn jetzt das GB im Verzeichniss  
C:/xampp/cgi-bin/ugb/  
liegt und die web-lib.pl in C:/xampp/cgi-bin/ müßte es eigentlich funktionieren. Wie schon gesagt, das ist eigentlich ein konzeptioneller Fehler, zumal dieses "Modul" überflüssig wie ein Kropf ist, es definiert nur einige Variabeln, die sowieso besser mit [strftime](http://perldoc.perl.org/POSIX.html#FUNCTIONS) des POSIX Moduls formatiert werden und gibt den HTML header aus, der sinnvollerweise mit dem sowieso schon genutzen CGI Modul ausgegegebn sollte.  
  
Struppi.

[Engin]

Hi Struppi,

Da gibt es auch eine Option für den Apache, wurde hier auch schon angesprochen (viel Spaß beim suchen ;-) )

Das war doch diee sache mit "hauptsache 'perl' kommt in der shebang vor", ist doch mit usr\bin\perl gegeben, lief aber trotzdem nicht.

liegt und die web-lib.pl in C:/xampp/cgi-bin/ müßte es eigentlich funktionieren.

Tut es auch, die ganze Zeit hab ich mich gefragt, wo ich web-lib.pl finde und hab
im cgi-bin von xampp gesucht, in C:\perl gesucht, erst eine ausgiebige Google
suche hat mich auf diese Seite gebracht, wo ich dann meine Antwort fand.

Das web-lib.pl hielt ich für ein Modul, hatte ganz vergessen, das es zum UGB gehört und ein teil davon ist.

Nach kurzen Test eine kleine Anmerkung, Lokal kann man sich nicht eintragen, da

"Eintrag abgelehnt!
Grund: Datei C:/xampp/anonymous/nimmet/cgi-bin/ugb/files/userlist.txt nicht gefunden. "

Diese Datei ist aber definitiv im Verzeichnis. Und wenn man die Einträge lesen will kommt

"Eintrag abgelehnt!
Grund: Datei C:/xampp/anonymous/nimmet/cgi-bin/ugb/files/bookfile.txt nicht gefunden. "

Obwohl diese definitiv im Verzeichnis liegt.

Da müssen wieder die Experten ran.

Grüße,
Engin
 GYRO

[Struppi]

Da gibt es auch eine Option für den Apache, wurde hier auch schon angesprochen (viel Spaß beim suchen ;-) )

Das war doch diee sache mit "hauptsache 'perl' kommt in der shebang vor", ist doch mit usr\bin\perl gegeben, lief aber trotzdem nicht.

Jaja, wird Zeit das wir einen frischen Thread aufmachen ;-)

Die Aussage steht im Kontext zum ersten, also wenn die Apache Option, dass er nach Perl auch in der Registry sucht, an ist, dann muss der Ausdruck perl in der shebang Zeile vorkommen, ansonsten meldet Apache einen Fehler.

Nach kurzen Test eine kleine Anmerkung, Lokal kann man sich nicht eintragen, da

Ich hab das Skript auch nicht zu, laufen gebracht (zumindest war meine Lust darauf nicht so gross um diese Hürden zu überwinden). Hier sollte sich Patrick nochmal Gedanken machen ob das nicht einfacher geht.

Struppi.

[Engin]

Hi Struppi,

Das war doch diee sache mit "hauptsache 'perl' kommt in der shebang vor", ist doch mit usr\bin\perl gegeben, lief aber trotzdem nicht.

Jaja, wird Zeit das wir einen frischen Thread aufmachen ;-)

So langsam wäre das echt nicht schlecht.

Die Aussage steht im Kontext zum ersten, also wenn die Apache Option, dass er nach Perl auch in der Registry sucht, an ist, dann muss der Ausdruck perl in der shebang Zeile vorkommen, ansonsten meldet Apache einen Fehler.

Ochne, hetzt mich jetzt nicht noch auf meine registry, wenn ihr mich los werden wollt, dann könnt
ihr mir das auch direkt sagen und nicht meinen Rechner vorsätzlich Lahmlegen. :)

Da muss ich Heute Abend mal schauen, was ich in meiner Registry hab.

Ich hab das Skript auch nicht zu, laufen gebracht (zumindest war meine Lust darauf nicht so gross um diese Hürden zu überwinden). Hier sollte sich Patrick nochmal Gedanken machen ob das nicht einfacher geht.

Ich hatte noch vergessen zu erwähnen, das mitten in der Seite auch ein

"Content-type: text/html" da steht, wo es eigentlich nichts zu suchen hat.

Auch mit den tpl. hab ich ein wenig probleme, insbesondere den Errorheader (wird alles Doppelt ausgegeben, einmal normaler head und errorheader gleichzeitig), aber wie
gesagt, schau ich mir Heut Abend genauer an.

Grüße und Gute Nacht,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

Jaja, wird Zeit das wir einen frischen Thread aufmachen ;-)
So langsam wäre das echt nicht schlecht.

Ja, der Thread ist total unübersichtlich und es ist nahezu unmöglich, bereits gepostete Tipps o.Ä. herauszusuchen. Ich weiß langsam nicht mehr, was ich wem geschrieben habe, was ich wo geschrieben habe, und wo was ;)

Ich schlage daher vor (auch mit Rücksicht auf das übliche Forum, denn je länger ein Thread wird und je länger er im Forum bleibt, desto schneller werden andere Threads archiviert), dass wir diesen Thread manuell archivieren. Heute antworten wir alle noch, morgen mittag (also Sonntag mittag) würde ich oder Struppi ihn ins Archiv schicken.

Ich hoffe, alle sind damit einverstanden!

Die Aussage steht im Kontext zum ersten, also wenn die Apache Option, dass er nach Perl auch in der Registry sucht, an ist, dann muss der Ausdruck perl in der shebang Zeile vorkommen, ansonsten meldet Apache einen Fehler.
Ochne, hetzt mich jetzt nicht noch auf meine registry, wenn ihr mich los werden wollt, dann könnt
ihr mir das auch direkt sagen und nicht meinen Rechner vorsätzlich Lahmlegen. :)
Da muss ich Heute Abend mal schauen, was ich in meiner Registry hab.

In Deiner Registry musst Du gar nichts ändern. Der Apache muss nun angewiesen werden, dass er unter Windows bei einer UNIX-like-Shebang im Skript die Anwendungen aufruft, die dafür zuständig ist, nämlich Perl.
Das geht in der httpd.conf mit der Anweisung »ScriptInterpreterSource registry«.

Schau mal in diesem unübersichtlichen Thread nach, irgendwo reden wir ja davon ;)

Ich hab das Skript auch nicht zu, laufen gebracht (zumindest war meine Lust darauf nicht so gross um diese Hürden zu überwinden).

@Struppi: ich dachte, am Ende lief es doch (ziemlich oben im ersten Thread-Zweig, wenn ich mich recht erinnere)?

Hier sollte sich Patrick nochmal Gedanken machen ob das nicht einfacher geht.

Ja, Mann! ;)

Momentan lese ich aber Korrektur für SELFHTML Fr., bzw. update das dortige CSS-Kapitel (CSS-Basierte Layouts sind dort jetzt online).

Ich hatte noch vergessen zu erwähnen, das mitten in der Seite auch ein
"Content-type: text/html" da steht, wo es eigentlich nichts zu suchen hat.
Auch mit den tpl. hab ich ein wenig probleme, insbesondere den Errorheader (wird alles Doppelt ausgegeben, einmal normaler head und errorheader gleichzeitig),

Dann machst Du irgend etwas falsch...

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Ich hoffe, alle sind damit einverstanden!

Warum warten wir denn solange? Dieser Thread ist mittlerweile angsteinflössend,
hab schon 2 mal den Spruch "ist hier im Thread schon diskutiert worden, such doch mal" gehört. :)

Das geht in der httpd.conf mit der Anweisung »ScriptInterpreterSource registry«.

Schau mal in diesem unübersichtlichen Thread nach, irgendwo reden wir ja davon ;)

Ja ich weiss, Christoph hat da auch direkt ein bsp. zu gepostet, werde es gleich mal ausprobieren.
Hat es denn bei dir mit Chritophs Code schnipsel geklappt?

Ich hatte noch vergessen zu erwähnen, das mitten in der Seite auch ein
"Content-type: text/html" da steht, wo es eigentlich nichts zu suchen hat.
Auch mit den tpl. hab ich ein wenig probleme, insbesondere den Errorheader (wird alles Doppelt ausgegeben, einmal normaler head und errorheader gleichzeitig),

Dann machst Du irgend etwas falsch...

Immer auf die unbeholfenen Lehrlinge. :) Ich schau es mir nochmal an,
läuft es denn bei dir tadellos?

Grüße,
Engin
 GYRO

[Engin]

Hi Engin,

vorneweg, es läuft jetzt ohne Doppelte und sonst wie falschen ausgaben, auch ein eintragen ist mir gelungen!

1200207155|Sonntag, 13. Januar 2008 - 07.52 Uhr|Engin|||||hdais idaos doadif qrwet wtegsb
 :-)))

Das geht in der httpd.conf mit der Anweisung »ScriptInterpreterSource registry«.

Schau mal in diesem unübersichtlichen Thread nach, irgendwo reden wir ja davon ;)

Ok, wie versprochen hab ich mich mal drangesetzt,
ScriptInterpreterSource so eingesetzt, wie von Christoph geschrieben, meine shebang musste ich trotzdem mit
#!"C:\xampp\perl\bin\perl.exe" - ist aber nicht so schlimm, hauptsache ist ja, das es läuft

Eine frage bleibt da noch, kann ich was mit der ausgabe, die Christophs Script macht anfangen?

Dann machst Du irgend etwas falsch...

Ich bzw. Apache oder dein Script, der fehler ist jedenfalls das,

Ich hab in
C:\xampp\cgi-bin   -   das UGB

Wenn ich das GB jetzt über mein Vhost aufrufe über

http://nimmetlocal.test/cgi-bin/ugb/ugb.pl

müsste das Script ja eigentlich in

C:\xampp\cgi-bin\ugb\files   -

nach den \files suchen, tut es aber nicht, es sucht dann in

http://nimmetlocal.test/cgi-bin/ugb/files .....
also in
C:\xampp\anonymous\nimmet\cgi-bin\ugb\files

Das heisst, ich müsste jetzt irgendwo in xampp all meinen Vhosts ein cgi-bin zuschreiben, das
sich dann auch in den Verzeichnissen meiner Vhosts befinden, in meinem Fall also,

C:\xampp\anonymous\nimmet  -  müsste ein cgi-bin rein

C:\xampp\anonymous\nispetlocal  -  müsste ein cgi-bin rein

C:\xampp\anonymous\saunaclub  -  müsste ein cgi-bin rein

C:\xampp\anonymous\klickandsurf  -  müsste ein cgi-bin rein

Christoph, falls du noch mit liest, kann ich das irgendwo einstellen, das _alle_ meine
Vhosts ein eigenes cgi-bin Verzeichnis bekommen?

Und gleich eine Frage hinterher, auf meinem Webspace brauche ich bei html und shtml Dateien
die Dateiendung beim aufruf über den Browser nicht mit anzugeben, geht
das auch mit xampp?
http://nimmetlocal.test/nimmet-dateien/impressum.html
                                       ohne     ^^^^^

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

vorneweg, es läuft jetzt ohne Doppelte und sonst wie falschen ausgaben, auch ein eintragen ist mir gelungen!

1200207155|Sonntag, 13. Januar 2008 - 07.52 Uhr|Engin|||||hdais idaos doadif qrwet wtegsb
:-)))

Supi!

Eine frage bleibt da noch, kann ich was mit der ausgabe, die Christophs Script macht anfangen?

Christophs oder Struppis? Oder meins? Welches Skript?

• Christophs Skript hier gibt die Umgebungsvariablen aus.

• Mein Skript hier gibt die Umgebungsvariable $ENV{DOCUMENT_ROOT} aus sowie das Current Working Directory (cwd()-muss eigentlich das cgi-bin sein , aus dem das Skript aufgerufen wird) und auch noch die Variable $Bin aus dem Modul FindBin und muss in dem Testfall ebenfalls das cgi-bin vom Skript sein. Ferner wird die Perl-Version $] ausgegeben und den Skript-Pfad $0. Achja, $ENV{PATH} wird auch noch ausgegeben - und den Inhalt von @INC. Der Array @INC wird von Perl angelegt und enthält alle Pfade zu den Verzeichnissen, in welchen Module gesucht werden.

• Sturppis Skript hier tut das selbe wie meins, nur hat er use strict; verwendet (was man ohnehin machen sollte). Mit Struppis Skript kannst Du keine web-lib.pl einbinden, denn use strict bricht die Ausführung mit einer Fehlermeldung aus. In einer strikten Version des GBs wird dieses Sache deswegen anders gelöst werden. Für eine übersichtlichere Ausgabe von @INC würde ich Struppis Skript noch eine Zeile $, = " "; hinzufügen.

Dann machst Du irgend etwas falsch...
nach den \files suchen, tut es aber nicht, es sucht dann in
http://nimmetlocal.test/cgi-bin/ugb/files .....
also in
C:\xampp\anonymous\nimmet\cgi-bin\ugb\files

Sagte ich doch. »Datei nicht gefunden« heißt »Datei nicht gefunden«. Die Pfade müssen in der config.pl entsprechend angepasst werden. ;)

Für die Shebang-Geschichte reicht eigentlich:

ScriptInterpreterSource registry

in der httpd.conf.

ScriptAlias /cgi-bin/ "E:/xampp/htdocs/cgi-bin/" # diese Zeile setzt das cgi-bin-Verz. in /xampp/htdocs zum Default cgi-bin. Darin enthaltene Dateien aufrufbar mit http://localhost/cgi-bin. Default unmittelbar nach der Xampp-Installation war /xampp/cgi-bin

Ferner muss in der Options-Zeile ExecCGI vermerkt werden (für jedes Deiner cgi-bin-Verzeichnisse):

<Directory "E:/xampp/htdocs/cgi-bin">
    AllowOverride None
    Options ExecCGI
    Order allow,deny
    Allow from all
</Directory>

Mit dieser Konfiguration klappt das mit Perlhuhn in der Shebang, das war ja der Grund für meinen Aaaaaaaaaaaaaaaaargh-Beitrag, dass ich das zunächst vergessen hatte und deswegen nicht funzte(TM).

Das heisst, ich müsste jetzt irgendwo in xampp all meinen Vhosts ein cgi-bin zuschreiben, das
sich dann auch in den Verzeichnissen meiner Vhosts befinden, in meinem Fall also,

C:\xampp\anonymous\nimmet  -  müsste ein cgi-bin rein

C:\xampp\anonymous\nispetlocal  -  müsste ein cgi-bin rein

C:\xampp\anonymous\saunaclub  -  müsste ein cgi-bin rein

C:\xampp\anonymous\klickandsurf  -  müsste ein cgi-bin rein

Ich denke schon. Ich habe aber immer noch nicht mit Vhosts »gespielt« (gestern eine weitere Datei für SELF Fr. übersetzt, die muss ich heute noch durchgehen).

Und gleich eine Frage hinterher, auf meinem Webspace brauche ich bei html und shtml Dateien
die Dateiendung beim aufruf über den Browser nicht mit anzugeben, geht
das auch mit xampp?
http://nimmetlocal.test/nimmet-dateien/impressum.html
                                       ohne     ^^^^^

In der httpd.conf diese Stelle bearbeiten:

#
    # Filters allow you to process content before it is sent to the client.
    #
    # To parse .shtml files for server-side includes (SSI):
    # (You will also need to add "Includes" to the "Options" directive.)
    #
   AddType text/html .shtml
   AddOutputFilter INCLUDES .shtml

Beachte: (You will also need to add "Includes" to the "Options" directive.)

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick!

juhu, mein Apache läuft auch wieder!
Damit auch der Fehler, der Ausgangspunkt des threads war.
Die ganzen Vorschläge des threads nachzuvollziehen und zu berücksichtigen fällt mir allerdings sehr schwer!
Gruß
Silke

[Patrick Andrieu]

Hallo Silke!

juhu, mein Apache läuft auch wieder!

Freut mich, echt (Mail letztens erhalten?)!

Damit auch der Fehler, der Ausgangspunkt des threads war.

Also kein mod_perl und keine falsche Ausgabe von cwd() und $FindBin::Bin?

Die ganzen Vorschläge des threads nachzuvollziehen und zu berücksichtigen fällt mir allerdings sehr schwer!

In wie fern? Wenn die Antwort ist: »Weil der Thread unübersichtlich ist«, dann stimmen wir Dir alle zu.

Ich warte darauf, bis Engin das heute Nacht noch liest, morgen schicke ich den Monster-Thread nun endgültig ins Archiv. Fragen über das ugb sowieso lieber per E-Mail an mich, hat hier im Forum eigentlich nichts zu suchen ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick!

Freut mich, echt (Mail letztens erhalten?)!

Vermutlich im Stress und bei vielen spams untergegangen.
Kannst Du es bitte nochmals senden?

Also kein mod_perl und keine falsche Ausgabe von cwd() und $FindBin::Bin?

?????

Die ganzen Vorschläge des threads nachzuvollziehen und zu berücksichtigen fällt mir allerdings sehr schwer!

In wie fern? Wenn die Antwort ist: »Weil der Thread unübersichtlich ist«, dann stimmen wir Dir alle zu.

Ja, weil der Thread unübersichtlich ist.
Gruß
Silke

[Patrick Andrieu]

Hallo Silke!

Freut mich, echt (Mail letztens erhalten?)!
Vermutlich im Stress und bei vielen spams untergegangen.
Kannst Du es bitte nochmals senden?

Eben geschehen.

Also kein mod_perl und keine falsche Ausgabe von cwd() und $FindBin::Bin?
?????

Ja, es ging doch darum, dass bei Dir C:/xampp 'rauskam anstatt E:/test/cgi-bin, also dem tatsächlichen »current working directory«, dem Verzeichnis, von wo aus das Skript aufgerufen wird.

Ja, weil der Thread unübersichtlich ist.

Ja, der weilt schon 13 Tage lang - wow! Es gab aber in der Forumsgeschichte viel längere, aber dieser wäre bald auch Rekordanwärter.

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick!

Eben geschehen.

Danke!

Ja, es ging doch darum, dass bei Dir C:/xampp 'rauskam anstatt E:/test/cgi-bin, also dem tatsächlichen »current working directory«, dem Verzeichnis, von wo aus das Skript aufgerufen wird.

Das ist nach wie vor so, da ich ja die alte Version wieder habe und
die im thread erwähnten Korrekturen und Korrekturen der Korrekturen nicht vorgenommen habe.

Gruß
Silke

[Engin]

Hi Patrick,

Christophs oder Struppis? Oder meins? Welches Skript?

Da fragste jetzt was. :) Christophs meinte ich, ich selber kann mit keinem
der Scripte von euch was anfangen. :) (noch nicht;)

Sagte ich doch. »Datei nicht gefunden« heißt »Datei nicht gefunden«. Die Pfade müssen in der config.pl entsprechend angepasst werden. ;)

Das ist doch irgendwie ne!
Da muss es doch auch eine möglichkeite geben, das Sauberer zu lösen, wäre doch Unsinn, die ugb.pl - config.pl und admin.pl in C:\xampp\cgi-bin\ugb zu lassen und die
dazugehörigen \files in C:\xampp\anonymous\nimmet\cgi-bin\ugb\files abzulegen.

Für die Shebang-Geschichte reicht eigentlich:
ScriptInterpreterSource registry

Da hatte ich ausversehen einen Fehler gemacht, der sich erst jetzt nach dem Neustart bemerkbar gemacht hat,
muss gleich mein System nochmal Neu starten und gucken.

die Dateiendung beim aufruf über den Browser nicht mit anzugeben, geht das auch mit xampp?
http://nimmetlocal.test/nimmet-dateien/impressum.html
                                       ohne     ^^^^^
   AddType text/html .shtml
   AddOutputFilter INCLUDES .shtml

Beachte: (You will also need to add "Includes" to the "Options" directive.)

So wie du es jetzt geschrieben hast steht es in meiner conf, nur den letzten Satz versteh ich nicht,
muss ich da selber so ne Options Geschichte schreiben?

<Directory />
    Options Includes
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

So?

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

Da fragste jetzt was. :) Christophs meinte ich, ich selber kann mit keinem
der Scripte von euch was anfangen. :) (noch nicht;)

Dabei tun die gar nichts. Die geben nur was aus. Programmierkunst ist keins davon ;).

Alle drei Skripte sind aber aufschlussreich, teste sie einfach alle.

Da muss es doch auch eine möglichkeite geben, das Sauberer zu lösen, wäre doch Unsinn, die ugb.pl - config.pl und admin.pl in C:\xampp\cgi-bin\ugb zu lassen und die
dazugehörigen \files in C:\xampp\anonymous\nimmet\cgi-bin\ugb\files abzulegen.

Schau doch mal... Du hast einen Vhost namens nimmet eingerichtet, dessen ServerRoot C:\xampp\anonymous\nimmet ist.

In der config hast du, nehme ich an, nicht die Pfadvariablen für den lokalen Einsatz gesetzt, sondern die anderen, die sogenannten Pfadvariablen für den Online-Einsatz? Und da gibt es einen Skalar $dcr. Der wird in der config.pl ganz oben deklariert, und was steht da?

$dcr = $ENV{DOCUMENT_ROOT};

So und nun ist Dein Script im C:\xampp\cgi-bin

Du rufst ihn aber über Deinen Vhost auf, also http://nimmet.test. Da ist der Root aber wie gesagt: C:\xampp\anonymous\nimmet, also erhält $dcr diesen Wert.

$BookFile = $dcr."/cgi-bin/ugb/files/bookfile.txt";

das ergibt: C:\xampp\anonymous\nimmet/cgi-bin/ugb/files/bookfile.txt

Und DA wird die bookfile.txt und die anderen Dateien gesucht!

Kommentiere alle diese Zeilen aus, und nutze die Pfadvariablen für den lokalen Einsatz. Wenn Deine Dateien also in:

C:\xampp\cgi-bin/ugb/files/ sind, dann kommentiere alle Pfadvariablen für den Online-Einsatz, und setze die Pfadvariablen für den lokalen Einsatz entsprechend dem Ort, wo die Dateien sind:

$BookFile = "C:\xampp\cgi-bin\ugb\files\bookfile.txt";

usw...

So wie du es jetzt geschrieben hast steht es in meiner conf, nur den letzten Satz versteh ich nicht,
muss ich da selber so ne Options Geschichte schreiben?
<Directory />
    Options Includes
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

So?

So verstehen ich das. Bin aber hier nicht gerade der Apache-Experte, so nach den wenigen Tagen, wo ich das Teil installiert habe...

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Alle drei Skripte sind aber aufschlussreich, teste sie einfach alle.

Muss ich wohl aber auf Morgen verschieben, muss Heute mal wieder richtig "arbeiten".

Und DA wird die bookfile.txt und die anderen Dateien gesucht!

Kommentiere alle diese Zeilen aus, und nutze die Pfadvariablen für den lokalen Einsatz. Wenn Deine Dateien also in:

C:\xampp\cgi-bin/ugb/files/ sind, dann kommentiere alle Pfadvariablen für den Online-Einsatz, und setze die Pfadvariablen für den lokalen Einsatz entsprechend dem Ort, wo die Dateien sind:

$BookFile = "C:\xampp\cgi-bin\ugb\files\bookfile.txt";

DAs werde ich gleich mal probieren, vorher muss ich noch herausfinden, warum plötzlich

http://nimmetlocal.test/cgi-bin/ugb/ugb.pl

Zugriff verweigert!

wird, ich werd noch blöd wegen diesem xampp!

So verstehen ich das. Bin aber hier nicht gerade der Apache-Experte, so nach den wenigen Tagen, wo ich das Teil installiert habe...

Hast aber in den wenigen Tagen ne Menge hingekriegt. :) Ich hab das ding schon
fast ein Jahr und hab grade mal ein Paar Vhosts.

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

Muss ich wohl aber auf Morgen verschieben, muss Heute mal wieder richtig "arbeiten".

Mist, gelle? Gerade wo eine Sache Spaß macht, muss die Arbeit dazwischen kommen ;)

Ich hab das ding schon fast ein Jahr und hab grade mal ein Paar Vhosts.

Wobei es IMHO logischer ist, jedem Vhost sein eigenes cgi-bin zu geben. Willst Du das GB auf deinem lokalen nimmet laufen lassen, dann gib /anonymous/nimmet ein cgi-bin!

Das ist das einfachste, und so habe ich das auch beim Webhoster 1&1! Ich habe dort 4 Domains (bis 5 kann ich verwalten), wobei eine, sach ich mal, »richtig« ist und die 4 anderen nichts anderes sind als Vhosts. Das gleiche für die Subdomains.

Jeder Domain, jeder Subdomain ihr eigenes cgi-bin und gut ist.

Ach ja, ich habe im Moderationsforum (und auch hier im Thread) angekündigt, dass ich den Thread morgen archiviere. Der Thread interessiert eh nur noch Dich, Silke, Struppi, vielleicht Christoph und mich... ist aber viel zu lang und verursacht dadurch eine kürzere Lebensdauer neueren Threads. Falls Du noch Fragen hast, dann per E-Mail oder neuen Server-Thread aufmachen, sobald dieser weggekickt wurde!

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Mist, gelle? Gerade wo eine Sache Spaß macht, muss die Arbeit dazwischen kommen ;)

ich konnte es auf ne halbe Stunde hinausschieben, dann ist aber Ende im Gelände,
hab auch noch einen riesigen Berg Papierkram  :(

Wobei es IMHO logischer ist, jedem Vhost sein eigenes cgi-bin zu geben. Willst Du das GB auf deinem lokalen nimmet laufen lassen, dann gib /anonymous/nimmet ein cgi-bin!

Das mein ich doch, ich will nicht nur für nimmet, sondern für alle Vhosts ein eigenes cgi-bin,
aber ich weiss nicht, wie das von statten gehen soll.

Derzeit werden die UGB _Scripte ugb.pl-config.pl-admin.pl_ über das cgi-bin von apache aufgerufen,
die \files aber über das cgi-bin vom nimmet Vhost Verzeichnis (dein vorschlag mit Pfad änderung funktioniert, ist aber nicht grad das Gelbe vom Ei).

Jeder Domain, jeder Subdomain ihr eigenes cgi-bin und gut ist.

Full Ack!

Falls Du noch Fragen hast, dann per E-Mail oder neuen Server-Thread aufmachen, sobald dieser weggekickt wurde!

Fragen hab ich mehr als genug. :) Ich denke ein neuer Thread wird demnächst folgen,
man findet im Netz nirgends was verständliches zur xampp Konfiguration,
hier gibt es genug Experten, da könnte man eine ganz anständige Thread/Doku für Anfänger auf die Beine stellen,
wei man xampp gehörig macht.

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

Aaargh, muss man lange scrollen, bis man zum Antwortformular gelangt. Zeit, den Thread verstauben zu lassen - Ruhe in Friede im Archiv, Du liebgewonnener Thread!

Derzeit werden die UGB _Scripte ugb.pl-config.pl-admin.pl_ über das cgi-bin von apache aufgerufen,
die \files aber über das cgi-bin vom nimmet Vhost Verzeichnis (dein vorschlag mit Pfad änderung funktioniert, ist aber nicht grad das Gelbe vom Ei).

Nein, aber logisch. Die files können nur gefunden werden, wenn Perl weiß, wo er sie finden kann. Das war nicht gegeben, mit der Änderung ist es gegeben. Das hilft Dir zumindest solange bis Du das:

Jeder Domain, jeder Subdomain ihr eigenes cgi-bin und gut ist.

erledigt hast.

hier gibt es genug Experten, da könnte man eine ganz anständige Thread/Doku für Anfänger auf die Beine stellen,
wei man xampp gehörig macht.

OK. Du hast das <I> fürs Schreiben, ich übernehme es fürs Korrekturlesen (bin übrigens mit den French Files fertig: http://fr.selfhtml.org/css/misesenpage/ und http://fr.selfhtml.org/css/formats/modele_boite.htm)...

Und jetzt gehe ich dodo, morgen ist ja wieder Kindergarten...

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Aaargh, muss man lange scrollen, bis man zum Antwortformular gelangt. Zeit, den Thread verstauben zu lassen - Ruhe in Friede im Archiv, Du liebgewonnener Thread!

Ach, es geht eigentlich mit dem scrollen, nur sachen wie "wurde hier schon diskutiert, such mal".....

OK. Du hast das <I> fürs Schreiben, ich übernehme es fürs Korrekturlesen (bin übrigens mit den French Files fertig: http://fr.selfhtml.org/css/misesenpage/ und http://fr.selfhtml.org/css/formats/modele_boite.htm)...

Sehr schön, wenn ich es noch verstehen würde...:) Habt ihr interesse an einer Türkischen fassung?[1]
Kannst du mir nochmal den link zu der Seite geben, die sachen wie <> selbst maskiert? Habsch leider verloren.

Und jetzt gehe ich dodo, morgen ist ja wieder Kindergarten...

Gute Nacht!

Grüße,
Engin
 GYRO

[1] diese frage ist mit Humor zu geniessen, jedes schäbige Translate Programm würde es um ein vielfaches besser hinkriegen. :)

[Engin]

Hi Patrick,

Kommentiere alle diese Zeilen aus, und nutze die Pfadvariablen für den lokalen Einsatz. Wenn Deine Dateien also in:

C:\xampp\cgi-bin/ugb/files/ sind, dann kommentiere alle Pfadvariablen für den Online-Einsatz, und setze die Pfadvariablen für den lokalen Einsatz entsprechend dem Ort, wo die Dateien sind:

$BookFile = "C:\xampp\cgi-bin\ugb\files\bookfile.txt";

Wollte das nur bestätigen, ist aber dennoch ziemlich Doof, werde die tage mal suchen,
wie man jedem Vhost ein eigenes cgi-bin Verzeichnisse richtig zuordnet, an der apache conf
fummel ich vorerst nicht mehr rum, ohne zu wissen, was ich da tu.

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

vorneweg, es läuft jetzt ohne Doppelte und sonst wie falschen ausgaben, auch ein eintragen ist mir gelungen!

1200207155|Sonntag, 13. Januar 2008 - 07.52 Uhr|Engin|||||hdais idaos doadif qrwet wtegsb
:-)))

Ich weiß, warum bookfile.txt nicht gefunden wurde. Ganz einfach, die Datei wurde nicht gefunden, weil die Datei schlicht und einfach nicht da war! Aus irgendeinem Grund fehlte sie im ZIP-Archiv...

Habe ich bei der Installation des GBs auf meinem Xampp festgestellt. Übrigens, bis auf dieses kleine Ärgernis, läuft es problemlos.

ZIP-Archiv habe ich jetzt ausgetauscht.

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Hallo Engin!

"Eintrag abgelehnt!
Grund: Datei C:/xampp/anonymous/nimmet/cgi-bin/ugb/files/userlist.txt nicht gefunden. "
"Eintrag abgelehnt!
Grund: Datei C:/xampp/anonymous/nimmet/cgi-bin/ugb/files/bookfile.txt nicht gefunden. "
Obwohl diese definitiv im Verzeichnis liegt.

Bist Du Dir da wirklich sicher?

Da müssen wieder die Experten ran.

Hm, Datei nicht gefunden (no such file or directory) heißt im Klartext, hm, Datei nicht gefunden!

;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Obwohl diese definitiv im Verzeichnis liegt.

Bist Du Dir da wirklich sicher?

Ich schwööööörrrrrsss.  :)

Hm, Datei nicht gefunden (no such file or directory) heißt im Klartext, hm, Datei nicht gefunden!

Ich hab, nachdem ich gesehen habe, das es allen anschein nach funktioniert,
mir das gesamte /ugb Verzeichnis von nimmet.de runtergeladen, um die Struktur so wie sie ist (wie mit der formatierung auf nimmet.de)
beizubehalten, das beinhaltet ja auch die /files die

• warte, ich guck nochmal _
  "C:\xampp\cgi-bin\ugb\files" _
  -alle files da, so wie auf nimmet.de.

Vielleicht fehlt ja nur ein Modul, das die files einliest.

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Struppi!

C:/xampp/cgi-bin/ugb/
liegt und die web-lib.pl in C:/xampp/cgi-bin/ müßte es eigentlich funktionieren. Wie schon gesagt, das ist eigentlich ein konzeptioneller Fehler,

Warum eigentlich?

zumal dieses "Modul" überflüssig wie ein Kropf ist, es definiert nur einige Variabeln, die sowieso besser mit

Das nannte sich zuerst Library, war wohl (soweit ich mal gelesen habe) unter Perl 4-Zeiten nicht unüblich, mit solchen Libraries zu arbeiten. Das Gästebuch advguest.cgi habe ich seit August 2000 im Betrieb (siehe ersten Eintrag: http://selfspezial.atomic-eggs.com/cgi-bin/selfugb/ugb.pl?page=132). Das ugb habe ich darauf aufgebaut (steht im Autorenvermerk zu Beginn von ugb.pl), damals ohne mich große Gedanken zu machen, weil mir das Konzept mit den Templates gefiel und auch dass das GB ohne Datenbank auskommt. Im Moment sind 1320 Einträge vorhanden, sicher hat irgendwann solch eine »Textdatenbank« ihre Grenzen... Es ist mir mittlerweile schon lange klar, dass da einiges verbessert werden muss, trotzdem:

Warum sollte man beim Einbinden von (eigenen) Modulen (Libraries) NICHT auf solchen zugreifen, die eine Ebene höher liegen? Wer hat das verboten ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

zumal dieses "Modul" überflüssig wie ein Kropf ist, es definiert nur einige Variabeln, die sowieso besser mit

Das nannte sich zuerst Library, ...

Warum sollte man beim Einbinden von (eigenen) Modulen (Libraries) NICHT auf solchen zugreifen, die eine Ebene höher liegen? Wer hat das verboten ;)

Ja, aber das Konzept ist dass diese in einem Unterordner liegen, z.b. heißt dein Libary Ordner Patrick, dann sagst du allen deinen Skripten
use lib "c:/wer/weiß/wo/Patrick"

Und bindest alle deine Module z.b. mit:
use Patrick::Web::Lib;

So musst du zwar einen Pfad fest verdrahten, aber hast ansonsten keine Probleme mehr, in welcher Ebene in welchem Pfad das Hauptskript ist.

Und kannst zur Not z.b. auch im Modul den Pfad dahin in %INC suchen, um z.b eine "c:/wer/weiß/wo/Patrick/Web/lib.ini" Datei einzubinden. (ich bastel grad an einer Tk Anwendung und nutzt das dort um der Anwendung ein eigenes Icon in der Titelleiste zu verpassen).

Insofern ist es nicht verboten, aber verbaust dir so eine Möglichkeit elegant Module einzubinden, da du immer auf require angewiesen bist oder mit eval arbeiten müßtest, um immer 100% den richtigen Suchpfad zu finden.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Ja, aber das Konzept ist dass diese in einem Unterordner liegen, z.b. heißt dein Libary Ordner Patrick, dann sagst du allen deinen Skripten
use lib "c:/wer/weiß/wo/Patrick"

Und bindest alle deine Module z.b. mit:
use Patrick::Web::Lib;

Das würde ein Modul Lib.pm voraussetzen, das sich in pfad/cgi-bin/Patrick/Web befindet...

So musst du zwar einen Pfad fest verdrahten, aber hast ansonsten keine Probleme mehr, in welcher Ebene in welchem Pfad das Hauptskript ist.

Grmph... Wie soll ich das erklären... bisher nutze ich web-lib.pl in etlicher meiner -zugegeben- etwas altmodischen Skripten. Diese sind _nicht immer_ im cgi-bin. Mit solchen require-Anweisungen hatte ich bisher keine Probleme. Sollte ich, was ich ja vorhabe, später modular arbeiten, erfordert das ja, nach Deiner Aussage, eine komplett andere Verzeichnisstruktur...

P.S.: was dagegen, den Thread heute mittag ins Archiv zu schicken?

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo,

Ich hab derzeit alles rausgeschmissen, was ich drauf hatte und xampp neu draufgepackt.
Xampp ist echt zu blöde, Perl geht irgendwie garnicht (nur diese test.pl), einige wichtige PHP funktionen geben
fehlermeldungen aus.

Das ist einer der Gründe, weshalb ich persönlich immer von XAMPP abrate. Man kann sich alles, was man braucht (Apache, PHP, Perl, MySQL) auch gesondert downloaden und installieren. Geht vielleicht ein kleines bißchen langsamer, aber man hat dann eine bessere Übersicht. Ich selber benutze XAMPP nicht, die einzelnen Programme aber schon.

Grüße aus Berlin

Christoph S.

[Struppi]

Das ist einer der Gründe, weshalb ich persönlich immer von XAMPP abrate. Man kann sich alles, was man braucht (Apache, PHP, Perl, MySQL) auch gesondert downloaden und installieren. Geht vielleicht ein kleines bißchen langsamer, aber man hat dann eine bessere Übersicht. Ich selber benutze XAMPP nicht, die einzelnen Programme aber schon.

Mich würd da mal interessieren, ob du es so geschafft hast mod_perl einzurichten (unter windows XP)?

Da das - soweit das hier im Thread zu erkennen war - mit XAMPP ganz einfach geht und ich schon seit Wochen bei jedem Versuch scheitere.

Struppi.

[Christoph Schnauß]

hallo Struppi,

Mich würd da mal interessieren, ob du es so geschafft hast mod_perl einzurichten (unter windows XP)?

Das habe ich ganz einfach noch nicht probiert, da ich mod_perl bisher nicht gebraucht habe. Aber ich kanns natürlich mal versuchen.

Grüße aus Berlin

Christoph S.

[Patrick Andrieu]

Hallo Struppi!

Mich würd da mal interessieren, ob du es so geschafft hast mod_perl einzurichten (unter windows XP)?

Da das - soweit das hier im Thread zu erkennen war - mit XAMPP ganz einfach geht und ich schon seit Wochen bei jedem Versuch scheitere.

Dazu zwei Fragen:

Wozu braucht man das?
Warum führt es zu solchen Ausgaben (cwd(), $Bin)?

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Dazu zwei Fragen:

Wozu braucht man das?

Es ist um einiges schneller, ich könnte dir erklären warum aber da gibt es im Netz viele Seite dazu. Es ist übrigens auch üblich mod_php zu nutzen, deshalb denken manchen Leute PHP wäre schneller.

Warum führt es zu solchen Ausgaben (cwd(), $Bin)?

Wenn ich das richtig verstanden habe, weil der Pfad im BEGIN Block ermittelt wird und unter mod_perl dieser nur einmal ausgeführt wird (egal wie oft das Skript aufgerufen wird)

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Wozu braucht man das?
Es ist um einiges schneller, ich könnte dir erklären warum aber da gibt es im Netz viele Seite dazu. Es ist übrigens auch üblich mod_php zu nutzen, deshalb denken manchen Leute PHP wäre schneller.

Warum führt es zu solchen Ausgaben (cwd(), $Bin)?
Wenn ich das richtig verstanden habe, weil der Pfad im BEGIN Block ermittelt wird und unter mod_perl dieser nur einmal ausgeführt wird (egal wie oft das Skript aufgerufen wird)

Thanks!

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Struppi,

Mich würd da mal interessieren, ob du es so geschafft hast mod_perl einzurichten (unter windows XP)?

Da das - soweit das hier im Thread zu erkennen war - mit XAMPP ganz einfach geht und ich schon seit Wochen bei jedem Versuch scheitere.

Welche apache Version verwendest du?

http://www.apachefriends.org/de/xampp-windows.html#629
Mod_Perl funktioniert nicht mit Apache 2.2.6 (XAMPP 1.6.4)!

Da gabs ein Update auf "XAMPP für Windows 1.6.5 vom 24.12.2007".

Grüße,
Engin
 GYRO

[Struppi]

Mich würd da mal interessieren, ob du es so geschafft hast mod_perl einzurichten (unter windows XP)?

Da das - soweit das hier im Thread zu erkennen war - mit XAMPP ganz einfach geht und ich schon seit Wochen bei jedem Versuch scheitere.

Welche apache Version verwendest du?

Mehrere (Aus dem Grund, dass die 1. Version nicht ging))
1.3.27
2.2.4

http://www.apachefriends.org/de/xampp-windows.html#629
Mod_Perl funktioniert nicht mit Apache 2.2.6 (XAMPP 1.6.4)!

Aber 2.2.4

Struppi.

[Engin]

Hi Struppi,

Welche apache Version verwendest du?

Mehrere (Aus dem Grund, dass die 1. Version nicht ging))
1.3.27
2.2.4

Ich hab mir vor 3 tagen die neueste version (1.6.5) runter geladen.
Mit mod_include meinst du doch sowas hier?
Wenn ja, das habe ich mir grade auf meinen Rechner gepackt und läuft Tadellos, so
wie halt auf meinem Webserver.
Ich hab auch da nichts weiter verstellt, fast alles ist noch im default, nur ein Paar Vhosts und deren Verzeichnisse habe ich mir angepasst.

Nur ich muss auf meinem Lokalen Server auf die Dateiendung aufpassen,
da ich Lokal meine .htaccess nicht zum laufen krieg.
Online arbeite ich mit html Dateien, Lokal geht es nur mit shtml Dateien.

Grüße,
Engin
 GYRO

[Struppi]

Mehrere (Aus dem Grund, dass die 1. Version nicht ging))
1.3.27
2.2.4

Ich hab mir vor 3 tagen die neueste version (1.6.5) runter geladen.

Du meinst 2.6.5?

Mit mod_include meinst du doch sowas hier?

Nein, das ist SSI, das ist was anderes.

Nur ich muss auf meinem Lokalen Server auf die Dateiendung aufpassen,
da ich Lokal meine .htaccess nicht zum laufen krieg.

Das sollte wiederrum kein Problem sein

Struppi.

[Engin]

Hi Struppi,

Ich hab mir vor 3 tagen die neueste version (1.6.5) runter geladen.

Du meinst 2.6.5?

Ich weiss nicht, was die da für ein durcheinander betreiben, alles hat irgendwie verschieden Zahlen, ich hab

"XAMPP für Windows 1.6.5" - "Apache HTTPD 2.2.6"

Und neben dem Perl Addon steht
"Mod_Perl funktioniert nicht mit Apache 2.2.6 (XAMPP 1.6.4)!"
Achja, du suchst mod_include fällt mir grade mal auf.

Nein, das ist SSI, das ist was anderes.

Stimmt, hatte dieses Artikel falsch verstanden, mod_include ist ein Modul.
Wie kann ich denn testen, ob mod_include bei mir geht, dann wissen wir es ja ganz genau?

Das sollte wiederrum kein Problem sein

Danke für die aufheiternden Worte.  :)) Irgendwann schaff ich es bestimmt. :)

Grüße,
Engin
 GYRO

[Struppi]

"XAMPP für Windows 1.6.5" - "Apache HTTPD 2.2.6"

Wir reden hier erstmal nur über den Apache.

Achja, du suchst mod_include fällt mir grade mal auf.

nein, mod_perl. und suchen tu ich's auch nicht, es läuft bei mir einfach nicht.

Wie kann ich denn testen, ob mod_include bei mir geht, dann wissen wir es ja ganz genau?

mod_perl. Ich weiß es nicht genau, da es bei mir nicht läuft. Aber in dem von dir schon mal gepostete AddOn für die XAMPP Installation sind ein paar Beispielskripte enthalten und zwar im Verzeichniss xamp/modperl, d.h. du müßte es vermutlich unter localhost/modperl/test.pl das Testskritp aufrufen können, wenn du dein XAMP entsprechend umkonfiguriert hast.

Das sollte wiederrum kein Problem sein

Danke für die aufheiternden Worte.  :)) Irgendwann schaff ich es bestimmt. :)

Ich würd dir ja gern sagen, wie, aber bei mir lief das völlig ohne Probleme und Änderungen.

Struppi.

[Engin]

Hi Struppi,

Wie kann ich denn testen, ob mod_include bei mir geht, dann wissen wir es ja ganz genau?

mod_perl. Ich weiß es nicht genau, da es bei mir nicht läuft. Aber in dem von dir schon mal gepostete AddOn für die XAMPP Installation sind ein paar Beispielskripte enthalten und zwar im Verzeichniss xamp/modperl, d.h. du müßte es vermutlich unter localhost/modperl/test.pl das Testskritp aufrufen können, wenn du dein XAMP entsprechend umkonfiguriert hast.

Also, ich hab ein Paar Scripte aus diesem Addon versucht aufzurufen, musste aber die Verzeichnisse von C:\xampp\perl nach C:\xampp\cgi-bin verschieben.

Mit den shebang, die schon im Script stehen kommt die Fehlermeldung

couldn't create child process: 720003: stubmaker.pl

mit der shebang #!"C:\xampp\perl\bin\perl.exe" kommt
malformed header from script. Bad header=Accessing...: stubmaker.pl

bei einer anderen .pl Datei kommt
mit der shebang #!"C:\xampp\perl\bin\perl.exe"

Premature end of script headers: plexalizer.pl

Ist jetzt auch schon Recht spät, ich geh jetzt erstmal schlafen und schau mir
das Heute Abend nochmal an.

Ich würd dir ja gern sagen, wie, aber bei mir lief das völlig ohne Probleme und Änderungen.

Das ist komisch, ich bekomme einen Serverfehler, wenn ich die .htaccess in meinen Verzeichnissen lass.

Grüße,
Engin
 GYRO

[Engin]

Hi Christoph,

Das ist einer der Gründe, weshalb ich persönlich immer von XAMPP abrate. Man kann sich alles, was man braucht (Apache, PHP, Perl, MySQL) auch gesondert downloaden und installieren. Geht vielleicht ein kleines bißchen langsamer, aber man hat dann eine bessere Übersicht. Ich selber benutze XAMPP nicht, die einzelnen Programme aber schon.

Das will ich demnächst auch machen, hab noch Paar kleinigkeiten zu erledigen, wenn
die fertig sind, werde ich das in Angriff nehmen.

Kannst du mir ein Paar einstiegshilfen geben, welche PHP, Perl und MySQL Module würdest du empfehlen?

Das apache_1.3.35-win32-x86 habe ich mir schon als installer besorgt.

Auf was muss ich bei der einrichtung achten, wenn ich alles selbst installieren möchte?

Grüße,
Engin
 GYRO

[Struppi]

BTW: Die Ausgabe hier zeigt sehr wohl, dass die web-lib.pl gefunden wird:

Das ist ja was ich die ganze Zeit sage. Die Aussage von Silke kann so nicht richtig sein. Entweder sie verschweigt uns wichtige Details oder der Server ist komplett anders konfiguriert.

Wir werden es aber vermutlich nie erfahren, denn mit "nichts ist unmöglich" kann man natürlich alles begründen, wenn etwas falsch ist.

Struppi.

[Silke]

Hallo Struppi,

Wir werden es aber vermutlich nie erfahren, denn mit "nichts ist unmöglich" kann man natürlich alles begründen, wenn etwas falsch ist.

Warum erhitzt Dich so das "nichts ist unmöglich". Es war doch nur die konsequente Antwort auf Deine wiederholten Aussagen "unmöglich".
Ich habe auch nie geschrieben, dass mein Server genau so konfiguriert ist wie Deiner. Ich kann nur nicht im einzelnen nachvollziehen, was geändert wurde. Und was ich aber mit Bestimmtheit sagen kann, ist, dass alle meine Programme nach den Anpassungen problemlos funktionieren.
Gruß
Silke

[Struppi]

Wir werden es aber vermutlich nie erfahren, denn mit "nichts ist unmöglich" kann man natürlich alles begründen, wenn etwas falsch ist.
Warum erhitzt Dich so das "nichts ist unmöglich". Es war doch nur die konsequente Antwort auf Deine wiederholten Aussagen "unmöglich".

Ich bin nicht erhitzt, nur sind deine Angaben, so wie ich sie verstehe nicht möglich.

Das Skript liegt im Verzeichniss:
e:/test/cgi-bin/ugb/
Dein Server ist so konfiguriert:
ScriptAlias /cgi-bin/ "E:/test/cgi-bin/"
Document Root ist:
DocumentRoot "E:/test"

und wenn du das Skript aufrufst und dir cwd() ausgeben läßt kommt:
C:/xampp

Das ist nicht möglich.

Und was ich aber mit Bestimmtheit sagen kann, ist, dass alle meine Programme nach den Anpassungen problemlos funktionieren.

Was für Anpassungen?

Struppi.

[Silke]

Und was ich aber mit Bestimmtheit sagen kann, ist, dass alle meine Programme nach den Anpassungen problemlos funktionieren.

Was für Anpassungen?

Wie schon geschrieben, hat die Änderungen ein Freund von mir gemacht, den ich aber nicht mehr erreichen kann.
Er hat bei sich den Server so installiert, dass er die Programme völlig unverändert ins Internet übernehmen konnte.
Er hat da viel in Selfhtml und anderen Foren "gewühlt".
Diese Basis hat er bei mir auch installiert, wobei meine Programme noch nicht im Internet sind.
Gruß
Silke

[Patrick Andrieu]

Hallo Struppi!

BTW: Die Ausgabe hier zeigt sehr wohl, dass die web-lib.pl gefunden wird:

Das ist ja was ich die ganze Zeit sage.

Heute Morgen habe ich in etwa die Struktur nachgebildet, wie sie mir der eine GB-Nutzer mittels Screenshot vermittelt hat. Er hatte unter htdocs mehrere Projekte laufen, so habe ich es also nachgemacht. Dabei habe ich in der httpd.conf _nichts mehr_ geändert, so das mein Script-Alias immer noch E:\xampp\htdocs\cgi-bin ist. Der Gedanke dahinter ist, da Silke bereits sagte, ein Bekannter habe ihr die Xampp-Installation gemacht, dass der andere Nutzer vermutlich auch nicht viel in der httpd.conf 'rumgepfuscht hat (er hat übrigens eine ältere Xampp-Version als die, die ich mir letztens installiert habe).

So, nun zur Sache, folgende Verzeichnis Struktur:

E:
-cgi-bin                       # von Xampp bei der Installation angelegt, default cgi-bin
-htdocs                        # von Xampp bei der Installation angelegt, DOCUMENT_ROOT
--cgi-bin                      # unterhalb vom Root, mittels Anweisung ScriptAlias nun als default cgi-bin festgelegt
--webone                       # Name für ein Webprojekt unterhalb htdocs
---cgi-bin                     # cgi-bin für dieses »Webprojekt«
----test                       # Unterverzeichnis vom cgi-bin (wie ugb bei meinem GB)

Das Skript require_test.cgi in /webone/cgi-bin/test, fast wie gehabt:

  
#!"E:\xampp\perl\bin\perl.exe"  
  
use Cwd;  
use FindBin qw/$Bin/;  
use CGI qw(header);  
use CGI::Carp qw(fatalsToBrowser);  
  
require '../web-lib.pl';  
  
print "Content-Type: text/html\n\n";  
  
  
print "OK<br>\n";  
print "Root is: ", $ENV{DOCUMENT_ROOT};  
print "<br>", $/;  
print "\@INC contains: \"@INC\"<br>", $/;  
print "CWD is: ", cwd();  
print "<br>", $/;  
print "Datum aus web-lib.pl ermittelt ist: ", $date;  
print "<br>", $/;  
print "\$0 is: ", $0, "<br>", $/;  
print "Perl Version is: ", $], "<br>", $/;  
print "\$FindBin::Bin is: ", $Bin, "<br>", $/;  
print "PATH is: ", $ENV{PATH}, "<br>", $/;  

Ausgabe (Aufruf: http://patrick2/webone/cgi-bin/test/require_test.cgi):

OK
Root is: E:/xampp/htdocs
@INC contains: "E:/xampp/perl/site/lib E:/xampp/perl/lib ."
CWD is: E:/xampp/htdocs/webone/cgi-bin/test
Datum aus web-lib.pl ermittelt ist: Montag, 7. Januar 2008 - 11.47 Uhr
$0 is: E:/xampp/htdocs/webone/cgi-bin/test/require_test.cgi
Perl Version is: 5.008008
$FindBin::Bin is: E:/xampp/htdocs/webone/cgi-bin/test
PATH is: C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\WinSCP3;;C:\PROGRA~1\GEMEIN~1\MUVEET~1\030625

Es kommt also _keine_ Fehlermeldung »Can't locate web-lib.pl ...«, und auch cwd() und $FindBin::Bin »spucken« als Ausgabe das aktuelle Verzeichnis aus (nicht wie bei Silke, wo immer C:\xampp herauskam).

Demnach habe ich wirklich keine Ahnung, was bei ihnen schief läuft, nur klar ist: Die Konfiguration ist sicher nicht ganz korrekt.

Bleibt nur noch das Problem mit dem Apache-Absturz bei ScriptInterpreterSource zu lösen...

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Hallo Patrick!

E:
-cgi-bin                       # von Xampp bei der Installation angelegt, default cgi-bin
-htdocs                        # von Xampp bei der Installation angelegt, DOCUMENT_ROOT
--cgi-bin                      # unterhalb vom Root, mittels Anweisung ScriptAlias nun als default cgi-bin festgelegt
--webone                       # Name für ein Webprojekt unterhalb htdocs
---cgi-bin                     # cgi-bin für dieses »Webprojekt«
----test                       # Unterverzeichnis vom cgi-bin (wie ugb bei meinem GB)

E:
-xampp
--cgi-bin                       # von Xampp bei der Installation angelegt, default cgi-bin
--htdocs                        # von Xampp bei der Installation angelegt, DOCUMENT_ROOT
---cgi-bin                      # unterhalb vom Root, mittels Anweisung ScriptAlias nun als default cgi-bin festgelegt
---webone                       # Name für ein Webprojekt unterhalb htdocs
----cgi-bin                     # cgi-bin für dieses »Webprojekt«
-----test                       # Unterverzeichnis vom cgi-bin (wie ugb bei meinem GB)

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

So, nun zur Sache, folgende Verzeichnis Struktur:

E:
-cgi-bin                       # von Xampp bei der Installation angelegt, default cgi-bin
-htdocs                        # von Xampp bei der Installation angelegt, DOCUMENT_ROOT
--cgi-bin                      # unterhalb vom Root, mittels Anweisung ScriptAlias nun als default cgi-bin festgelegt
--webone                       # Name für ein Webprojekt unterhalb htdocs
---cgi-bin                     # cgi-bin für dieses »Webprojekt«
----test                       # Unterverzeichnis vom cgi-bin (wie ugb bei meinem GB)

Bei mir ist dies ähnlich (von XAMPP angelegt) allerdings auf Laufwerk C:
Meine Programme aber sind im Laufwerk E:/test bzw. E:/test/cgi-bin
bzw. E:/test/cgi-bin/ugb
Gruß
Silke

[Patrick Andrieu]

Hallo Silke!

Bei mir ist dies ähnlich (von XAMPP angelegt) allerdings auf Laufwerk C:
Meine Programme aber sind im Laufwerk E:/test bzw. E:/test/cgi-bin
bzw. E:/test/cgi-bin/ugb

Ja aber, wenn C:\xampp\htdocs Dein Document Root ist, wie denn rufst Du die Skripte/Seiten auf?

Da liegt sicher der Hund begraben!

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick,

mit http://www.test.de
bzw.
    http://www.test.de/cgi-bin/kontakt.pl

wobei neben test weitere Verzeichnisse vorgesehen sind für die geplanten echten Internet-Seiten.
Gruß
Silke

[Patrick Andrieu]

Hallo Silke!

mit http://www.test.de
bzw.
    http://www.test.de/cgi-bin/kontakt.pl

wobei neben test weitere Verzeichnisse vorgesehen sind für die geplanten echten Internet-Seiten.

Hm, sind das Virtual Hosts? Dann befürchte ich, dass was mit deren Konfiguration nicht in Ordnung ist. Am Xampp alleine liegt das, wie ich durch meine eigene Installation gezeigt habe, dann doch nicht - abgesehen vom Problem mit dem Apache-Absturz...

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick!

Hm, sind das Virtual Hosts? Dann befürchte ich, dass was mit deren Konfiguration nicht in Ordnung ist.

Könnte sein, denn damit kann ich mehrere "URLs" testen.
In der Datei c:/windows/system32/drivers/etc/hosts  habe ich auch meine  "URLs" gefunden
127.0.0.2 www.test.de
127.0.0.2 www.test1.de
.....
Viele Grüße
Silke

[Patrick Andrieu]

Hallo Silke!

mit http://www.test.de
bzw.
    http://www.test.de/cgi-bin/kontakt.pl

In der Datei c:/windows/system32/drivers/etc/hosts  habe ich auch meine  "URLs" gefunden
127.0.0.2 www.test.de
127.0.0.2 www.test1.de

Hm, trotz Eintrag in der hosts-Datei, kommst Du beim Testen da nicht manchmal auf http://www.test.de/? Spätestens wenn der Server nicht gestartet ist? Und wenn Du die Seiten der Stiftung Warentest besuchen willst, musst Du vorher den Server ausschalten?... Wenn man hier Smileys einbinden könnte, würde ich hier den Smiley »Kopf gegen Wand« () einsetzen ;)

Für solche Einträge ist der Domainname »test« reserviert. NIEMALS existierende Domainnamen angeben, wer hat Dir denn die Chose so konfiguriert?

Ich habe eben nochmals den Auszug aus Deiner httpd.conf gelesen, als Document Root ist doch E:/test eingegeben... cwd() müsste, wie Struppi angemerkt hat, demnach E:/test/cgi-bin ergeben, wenn Du einen Skript im cgi-bin aufrufst...

Sei so nett und kopiere Dir mein require_test.pl-Skript:

  
#!"E:\xampp\perl\bin\perl.exe"  
  
use Cwd;  
use FindBin qw/$Bin/;  
use CGI qw(header);  
use CGI::Carp qw(fatalsToBrowser);  
  
require 'web-lib.pl';  
  
print "Content-Type: text/html\n\n";  
  
  
print "OK<br>\n";  
print "Root is: ", $ENV{DOCUMENT_ROOT};  
print "<br>", $/;  
print "\@INC contains: \"@INC\"<br>", $/;  
print "CWD is: ", cwd();  
print "<br>", $/;  
print "Datum aus web-lib.pl ermittelt ist: ", $date;  
print "<br>", $/;  
print "\$0 is: ", $0, "<br>", $/;  
print "Perl Version is: ", $], "<br>", $/;  
print "\$FindBin::Bin is: ", $Bin, "<br>", $/;  
print "PATH is: ", $ENV{PATH}, "<br>", $/;  

in E:/test/cgi-bin (da muss auch web-lib.pl sein) und rufe es auf (Vorher Shebang-Zeile anpassen). Wenn wieder die Meldung »Can't locate ...« ausgegeben wird, kommentiere die require-Zeile mit eine Raute-Zeichen aus:

require 'web-lib.pl';

und poste bitte hier die gesamte Ausgabe.

Zusätzlich zur httpd.conf in »/xampp/apache/conf/« gibt es noch eine »httpd-vhosts.conf« in »/xampp/apache/conf/extra/«. Ist diese entsprechend editiert worden?

--------------------

Falls Struppi oder ein Apache-Kenner noch mitliest... Das Problem mit ScriptInterpreterSource und dem Apache-Absturz habe ich immer noch nicht gelöst, dafür bei den Xitami-Manpages herausgefunden, warum da sowohl .cgi als auch .pl-Dateien mit der Unix-Shebang problemlos aufgerufen werden können:

<cite>To provide compatibility with Perl scripts coming from UNIX, Xitami will handle a path like '/usr/bin/perl' by removing '/usr/bin/' and looking for PERL.EXE on the PATH, if /usr/bin/perl does not actually exist as a file.</cite>

Ich werde wohl widerwillig mich im Xampp-Forum registrieren und die Frage dort posten...

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

vorschnelle Vorschau...

Für solche Einträge ist der Domainname »test« reserviert.

Ich meinte natürlich die TLD »test« (nicht den Domainnamen, den benutzt Du ja fälschlischerweise schon).

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick!

Hm, trotz Eintrag in der hosts-Datei, kommst Du beim Testen da nicht manchmal auf http://www.test.de/? Spätestens wenn der Server nicht gestartet ist? Und wenn Du die Seiten der Stiftung Warentest besuchen willst, musst Du vorher den Server ausschalten?...

Der Test-Rechner ist offline, daher habe ich kein Problem mit www.test.de. Die anderen Seiten sind natürlich so wie von mir im Internet reserviert.

Sei so nett und kopiere Dir mein require_test.pl-Skript:

und poste bitte hier die gesamte Ausgabe.

Wird heute noch erledigt.

Zusätzlich zur httpd.conf in »/xampp/apache/conf/« gibt es noch eine »httpd-vhosts.conf« in »/xampp/apache/conf/extra/«. Ist diese entsprechend editiert worden?

»
Keine Änderung in httpd-vhosts.conf
Viele Grüße
Silke

[Silke]

Ging doch schneller als ich dachte:

Sei so nett und kopiere Dir mein require_test.pl-Skript:
Wenn wieder die Meldung »Can't locate ...« ausgegeben wird, kommentiere die require-Zeile mit eine Raute-Zeichen aus:

Ja, wird wieder ausgegebn.

require 'web-lib.pl';

und poste bitte hier die gesamte Ausgabe.

OK
Root is: E:/test
@INC contains: "C:/xampp/perl/site/lib/ e:/test/cgi-bin C:/xampp/perl/site/lib C:/xampp/perl/lib . C:/xampp/apache"
CWD is: C:/xampp
Datum aus web-lib.pl ermittelt ist:
$0 is: E:/test/cgi-bin/test.pl
Perl Version is: 5.008008
$FindBin::Bin is: C:/xampp/apache/bin
PATH is: e:\test\cgi-bin;C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Gruß
Silke

[Patrick Andrieu]

Hallo Silke!

Wenn wieder die Meldung »Can't locate ...« ausgegeben wird,
Ja, wird wieder ausgegebn.

Sorry, wenn ich blöd frage, aber Du hast das Skript wirklich in E:\test\cgi-bin kopiert und dort befindet sich auch web-lib.pl?

Also, wenn sogar das cgi-bin in @INC ausgeführt wird:

@INC contains: "C:/xampp/perl/site/lib/ e:/test/cgi-bin

...........................................^^^^^^^^^^^^^^^

(BTW: wie hast Du das hinbekommen?), _kann das einfach nicht sein_. Denn Module und Libraries werden in @INC gesucht, und hier in »Deinem« @INC ist der Pfad zum cgi-bin ja angegeben.

Entweder ist Dein Apache kaputt oder Deine Perlinstallation ;)

Root is: E:/test

Wenigstens das ist OK.

CWD is: C:/xampp

Das sollte E:/test/cgi-bin sein.

Datum aus web-lib.pl ermittelt ist:

Klar, wenn die Zeile auskommentiert, kommt hier nichts - das ist OK.

$0 is: E:/test/cgi-bin/test.pl

Das ist auch OK.

Perl Version is: 5.008008

Das ist auch OK.

$FindBin::Bin is: C:/xampp/apache/bin

Das ist wiederum falsch und sollte E:/test/cgi-bin sein.

PATH is: e:\test\cgi-bin;

............^^^^^^^^^^^^^^^^

Wie kommt der dahin?

-------

Der Test-Rechner ist offline, daher habe ich kein Problem mit www.test.de. Die anderen Seiten sind natürlich so wie von mir im Internet reserviert.

Dennoch sind die Angabe in Deiner hosts-Datei IMHO nicht richtig (auch wenn es funktioniert).

Keine Änderung in httpd-vhosts.conf

Das würde bedeuten, die ist nie editiert worden (alle Zeilen sind auskommentiert)?  Also keine VirutalHost-Container mit Angabe des jeweiligen DocumentRoot?

Irgendwo muss C:/xampp als DocumentRoot eingetragen sein, in Deinen confs, anders kann ich mir nicht vorstellen, dass da so ein Murks rauskommt...

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick!

Sorry, wenn ich blöd frage, aber Du hast das Skript wirklich in E:\test\cgi-bin kopiert und dort befindet sich auch web-lib.pl?

ganz sicher!

Also, wenn sogar das cgi-bin in @INC ausgeführt wird:

@INC contains: "C:/xampp/perl/site/lib/ e:/test/cgi-bin
...........................................^^^^^^^^^^^^^^^

(BTW: wie hast Du das hinbekommen?), _kann das einfach nicht sein_. Denn Module und Libraries werden in @INC gesucht, und hier in »Deinem« @INC ist der Pfad zum cgi-bin ja angegeben.

In der Registry ist ein Eintrag PERL5LIB mit dem Wert: e:/test/cgi-bin

Entweder ist Dein Apache kaputt oder Deine Perlinstallation ;)

Wie gesagt, sonst läuft alles und da andere ja den gleichen Effekt haben, wäre deren Installation zufällig an der gleichen Stelle kaputt!?

Irgendwo muss C:/xampp als DocumentRoot eingetragen sein, in Deinen confs, anders kann ich mir nicht vorstellen, dass da so ein Murks rauskommt...

Habe es nirgends in documentroot gefunden allerdings an zahlreichen Stellen ServerRoot "c:/xampp/apache".
In den Kommentaren steht aber

ServerRoot: The top of the directory tree under which the server's

configuration, error, and log files are kept.

Gruß
Silke

[Patrick Andrieu]

Hallo Silke!

Wir können LAUT SEIN (kaum einer liest hier noch, anscheinend) ;)

In der Registry ist ein Eintrag PERL5LIB mit dem Wert: e:/test/cgi-bin

Von Deinem Bekannten hinzugefügt?

Entweder ist Dein Apache kaputt oder Deine Perlinstallation ;)
Wie gesagt, sonst läuft alles und da andere ja den gleichen Effekt haben, wäre deren Installation zufällig an der gleichen Stelle kaputt!?

Ich frage deswegen (von Deinem Bekannten hinzugefügt) und auch das, weil... ich kannte mich mit Apache bisher nicht aus, habe Xampp zum ersten Mal installiert, und bis auf das (jetzt gelöste) Generve mit der Handhabung von .pl-Skripten, funktioniert alles _erwartet_, also wie es soll.

Was die anderen gemacht haben, kann ich Dir nicht sagen, ein User hat erst wieder am Donnerstag Zeit, ich bleibe also am Ball ;)

Aber mit so einer Konfiguration wirst Du auf jeden Fall Probleme mit Anwendungen haben, die eigene Module (.pm) mitbringen und diese im cgi-bin oder Unterordner brauchen. Denn wenn Perl can't locate das Modul, dann kommt der 500er wie gehabt...

Habe es nirgends in documentroot gefunden allerdings an zahlreichen Stellen ServerRoot "c:/xampp/apache".
In den Kommentaren steht aber

ServerRoot: The top of the directory tree under which the server's

configuration, error, and log files are kept.

Zumindest in der httpd-conf habe ich das auch so: E:/xampp/apache, daran scheint es also nicht zu liegen.

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick!

In der Registry ist ein Eintrag PERL5LIB mit dem Wert: e:/test/cgi-bin

Von Deinem Bekannten hinzugefügt?

Falls ich mich recht entsinne aufgrund von Forumsdiskussionen.
Ob er es direkt in die Registry eingefügt hat oder über eines der Perl-Installations-bat weiß ich nicht.

Aber mit so einer Konfiguration wirst Du auf jeden Fall Probleme mit Anwendungen haben, die eigene Module (.pm) mitbringen und diese im cgi-bin oder Unterordner brauchen. Denn wenn Perl can't locate das Modul, dann kommt der 500er wie gehabt...

Ich verwende aber problemlos pm-Module, die ich mit use einbinde.
Gruß
Silke

[Struppi]

Aber mit so einer Konfiguration wirst Du auf jeden Fall Probleme mit Anwendungen haben, die eigene Module (.pm) mitbringen und diese im cgi-bin oder Unterordner brauchen. Denn wenn Perl can't locate das Modul, dann kommt der 500er wie gehabt...

Ich verwende aber problemlos pm-Module, die ich mit use einbinde.

Es geht um Programme die eigene Module verwenden.

Kann es sein dass bei dir mod_perl oder sowas läuft?

Das würde den Unterschied hier erklären
ScriptAlias /cgi-bin/ "E:/test/cgi-bin/"
$FindBin::Bin is: C:/xampp/apache/bin

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Ich verwende aber problemlos pm-Module, die ich mit use einbinde.
Es geht um Programme die eigene Module verwenden.

Das meinte ich. Module, die nicht in /perl/lib oder /perl/site/lib abgelegt sind.

Kann es sein dass bei dir mod_perl oder sowas läuft?

Das wäre die letzte meiner Frage gewesen, bevor ich aufgebe... ;)

Silke: Welche Xampp/Apache-Version hast Du? Falls Du die letzte hast, dann die setup_xampp.bat starten, Option 2 wählen (Configuration without MOD_PERL). Vorher natürlich Apache stoppen und Xampp beenden.

Dann nochmals alles starten und require_test.pl aufrufen!

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Patrick

Ich verwende aber problemlos pm-Module, die ich mit use einbinde.
Es geht um Programme die eigene Module verwenden.

Das meinte ich. Module, die nicht in /perl/lib oder /perl/site/lib abgelegt sind.

Verstehe ich nicht. Meine pm-Module sind in e:/test/cgi abgelegt.

Kann es sein dass bei dir mod_perl oder sowas läuft?

Siehe Antwort an Struppi.

Silke: Welche Xampp/Apache-Version hast Du? Falls Du die letzte hast, dann die setup_xampp.bat starten, Option 2 wählen (Configuration without MOD_PERL). Vorher natürlich Apache stoppen und Xampp beenden.

Besteht nicht das Risiko, dass ich damit meine Installation zerschieße?

Bis morgen
Silke

[Patrick Andrieu]

Hallo Silke!

Das meinte ich. Module, die nicht in /perl/lib oder /perl/site/lib abgelegt sind.

Verstehe ich nicht. Meine pm-Module sind in e:/test/cgi abgelegt.

Du meinst E:/test/cgi-bin/? Also zusammen mit web-lib.pl? Dann mach doch daraus ein Modul? Sind das eigene, selbstgeschriebene Module? Dann würde ich mich echt fragen, wozu Du ein Fremdgästebuch brauchst, in weniger Zeit als wir gebraucht haben, diesen Thread zu führen, hättest Du zwei Gästebücher schreiben können!

Silke: Welche Xampp/Apache-Version hast Du? Falls Du die letzte hast, dann die setup_xampp.bat starten, Option 2 wählen (Configuration without MOD_PERL). Vorher natürlich Apache stoppen und Xampp beenden.

Besteht nicht das Risiko, dass ich damit meine Installation zerschieße?

Wenn Du die selbe Install hast wie ich, lässt sich über die setup_xampp.bat mod_perl problemlos aktivieren und deaktivieren. Zumindest habe ich das irgendwo beim Xampp Installieren gesehen, und wenn ich die .bat aufrufe, habe ich diese 2 Möglichkeiten (ich wähle immer ohne mod_perl, weil mir aus vielen Diskussionen hier Probleme bekannt sind).

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo,

Du meinst E:/test/cgi-bin/? Also zusammen mit web-lib.pl? Dann mach doch daraus ein Modul? Sind das eigene, selbstgeschriebene Module? Dann würde ich mich echt fragen, wozu Du ein Fremdgästebuch brauchst, in weniger Zeit als wir gebraucht haben, diesen Thread zu führen, hättest Du zwei Gästebücher schreiben können!

Ja ein selbstgeschriebenes "Hello world". Die andern sind Datumsroutinen aus Beispielprogrammen.

Besteht nicht das Risiko, dass ich damit meine Installation zerschieße?

Wenn Du die selbe Install hast wie ich, lässt sich über die setup_xampp.bat mod_perl problemlos aktivieren und deaktivieren. Zumindest habe ich das irgendwo beim Xampp Installieren gesehen, und wenn ich die .bat aufrufe, habe ich diese 2 Möglichkeiten (ich wähle immer ohne mod_perl, weil mir aus vielen Diskussionen hier Probleme bekannt sind).

Jetzt habe ich das System zerschossen.
Egal wie ich setup_xampp.bat ausführe, ich kann den apache nicht mehr starten. Offensichtlich hat das setup in der httpd.conf (u.a.) etwas verändert.
Ich hoffe, dass ich noch eine Vergleichsversion finde.
Tauche daher vorerst ab!
Gruß
Silke

[Patrick Andrieu]

Hallo Silke!

Jetzt habe ich das System zerschossen.

Oje, oje, hast Du denn vorher kein Backup gemacht? Also, es tut mir echt leid, das ist natürlich alles andere als schön...

Ich hoffe, dass ich noch eine Vergleichsversion finde.

Nimm doch gleich die letzte, installiere die Perl-Module anschließend über das Addon als ZIP.

Tauche daher vorerst ab!

Kann ich verstehen, tut mir leid und Kopf hoch! Wenn wir irgendwie helfen können, einfach wieder fragen!

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hi.

Kann es sein dass bei dir mod_perl oder sowas läuft?

Weiß ich nicht, woran kann ich das erkennen?
Gruß
Silke

[Struppi]

Kann es sein dass bei dir mod_perl oder sowas läuft?

Weiß ich nicht, woran kann ich das erkennen?

Weiß ich auch nicht. Ich nehme an das steht in einer Umgebungsvariabel. Laß sie die mal ausgeben:
env.pl

#!/usr/bin/perl -w  
use strict;  
  
use CGI;  
print CGI::header(), CGI::start_html();  
my @out;  
foreach(sort keys(%ENV)) {  
  push @out, CGI::Tr( CGI::td( [CGI::b($_), $ENV{$_}]));  
}  
print CGI::table( @out);  
print CGI::end_html();  

Struppi.

[Christoph Schnauß]

hallo Struppi,

Kann es sein dass bei dir mod_perl oder sowas läuft?
Weiß ich nicht, woran kann ich das erkennen?
Weiß ich auch nicht. Ich nehme an das steht in einer Umgebungsvariabel.

Nein, das tut es nicht.

Laß sie die mal ausgeben

Das nutzt für diese Frage nichts (ich habs eben mal schnell getestet). Man kann entweder in der Konfigurationsdatei die Liste der geladenen Module durchsuchen, oder (etwas eleganter) die Ausgabe für "server-status" aktivieren. Die zeigt es am deutlichsten an.

Grüße aus Berlin

Christoph S.

[Patrick Andrieu]

Hallo Struppi!

(Thread am Leben halt...) ;)

Kann es sein dass bei dir mod_perl oder sowas läuft?

Das würde den Unterschied hier erklären
ScriptAlias /cgi-bin/ "E:/test/cgi-bin/"
$FindBin::Bin is: C:/xampp/apache/bin

Genau die selbe Ausgabe wie Silke hat der andere User. Er will jetzt, wenn er wieder Zeit hat, die bisherige Installation löschen und wie ich die neueste Version, dann ohne mod_perl, installieren.

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo Silke,

Perl Version is: 5.008008

Das ist ziemlich unmöglich. Perl. 5.0 ist ein paar Jahre alt. Ein aktuelles XAMPP würde dir Perl 5.8 liefern.

Grüße aus Berlin

Christoph S.

[Patrick Andrieu]

Hallo Christoph!

Perl Version is: 5.008008

Das ist ziemlich unmöglich. Perl. 5.0 ist ein paar Jahre alt. Ein aktuelles XAMPP würde dir Perl 5.8 liefern.

Das bedeutet aber Perl 5.8.8 und wird aber so ausgegeben: 5.008008 (bei print $];)

Das habe ich auch, wenn ich auf der Konsole perl aufrufe und:
print $];
ausgeben lasse, nur dass ich dann 5.008007 erhalte, weil meine ActiveState-Perl-Installation auf C: älter ist als die von Xampp auf E: installierte.

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo Patrick,

Perl Version is: 5.008008
Das ist ziemlich unmöglich. Perl. 5.0 ist ein paar Jahre alt. Ein aktuelles XAMPP würde dir Perl 5.8 liefern.
Das bedeutet aber Perl 5.8.8 und wird aber so ausgegeben: 5.008008 (bei print $];)

Hm. Mag sein. Ich habe auf die Schnelle bloß "perl -v" auf der Konsole (Eingabeaufforderung) eingetippt und bekam angezeigt:

This is perl, v5.10.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2007, Larry Wall

Binary build 1001 [283495] provided by ActiveState http://www.ActiveState.com
Built Dec 18 2007 08:46:15

Grüße aus Berlin

Christoph S.

[Patrick Andrieu]

Hallo Christoph!

Hm. Mag sein.

Nichts da »mag sein«. Holunderwein (wie ich Äppelwoi) einschenken, entspannen und testen. Cmd auf, perl -w, print $]; ^Z... Ausgabe: 5.008007 (oder 8 am Ende, je nach dem, was Du hast... die James Bond Version hat mich bisher aber nicht enttäuscht, und, ehrlich gesagt, habe ich keinen Schimmer davon, was an der 008 anders ist)...

Ich habe auf die Schnelle bloß "perl -v" auf der Konsole

Ja, das ist die Auführliche ausgabe. Interessant mit PuTTy auf dem (Webhoster-)Server, da bekommt man einiges mehr zu sehen.

Es gibt eine andere Möglichkeit, sich die Perl-Version ausgeben zu lassen, als das »deprecated« $]... Bin aber zu jetzt zu äbbelig, um danach zu suchen (steht so viel ich weiß aber in SELFHTML).

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo Patrick,

Das Problem mit ScriptInterpreterSource und dem Apache-Absturz habe ich immer noch nicht gelöst

Das ist auch schwer lösbar, da es sich nicht reproduzieren läßt. Du kennst aber den immer wiederkehrenden Hinweis auf die logs: stand/sthet denn da irgendwas, was den Absturz kommentiert/dokumentiert? Wie hat sich der Absturz dargestellt? Sind beide Apache-Prozesse beendet worden (bitte im Taskmanager nachschauen, ob noch einer aktiv ist)?

Fehlermeldungen könnten sein:

• [error] [client xx.xxx.xxx.xxx] (OS 3)Das System kann den angegebenen Pfad nicht finden.  : couldn't create child process: 720003: script.cgi
• [error] [client xxx.xxx.xxx.xxx] (OS 3)Das System kann den angegebenen Pfad nicht finden.  : couldn't spawn child process
• [error] [client xxx.xxx.xxx.xxx] (OS 123)Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch
• [error] [client xxx.xxx.xxx.xxx] (9)Bad file descriptor: don't know how to spawn child process: script.cgi

dafür bei den Xitami-Manpages herausgefunden, warum da sowohl .cgi als auch .pl-Dateien mit der Unix-Shebang problemlos aufgerufen werden können

Xitami funktioniert völlig anders als der Apache. Die manpages haben für den Apache leider keinerlei Aussagekraft. Du hast vermutlich in deiner Konfiguration nicht angegeben, daß du eben auch die Dateinamensendung *.cgi zur Ausführung als CGI-Script zulassen möchtest. Das geht über Script-Alias, wie du bereits weißt.

Nur zum Vergleich: ich habe einen Apache 2.2.6 unter WinXP laufen. Die Konfigurationsdatei(en), die ich benutze, enthalten "ScriptInterpreterSource registry" sowie einen Container

ScriptAlias /cgi-bin/ "G:/cgi-bin/"  
<Directory "G:/cgi-bin">  
    AllowOverride None  
    Options Indexes ExecCGI  
    Order allow,deny  
    Allow from 192.168  
    Deny from all  
</Directory>

Zum Testen benutze ich ein Script

#!/usr/bin/perl -w  
  
use strict;  
use CGI;  
use CGI::Carp qw(fatalsToBrowser);  
  
my $cgi = new CGI;  
  
print $cgi->header().  
      $cgi->start_html('Umgebungsvariablen').  
      $cgi->h1('Umgebungsvariablen')."\n".  
      $cgi->start_table({-border => '1'})."\n".  
        $cgi->Tr($cgi->th({-bgcolor => '#E0E0E0'},'Variablenname')."\n".  
                 $cgi->th({-bgcolor => '#E0E0E0'},'Wert'))."\n";  
foreach(keys(%ENV)) {  
  print $cgi->Tr($cgi->td($cgi->strong($_)).  
                 $cgi->td($ENV{$_}))."\n";  
}  
print $cgi->Tr($cgi->th({-align => 'left', -bgcolor => '#E0E0E0', -colspan => '2'},  
                         'insgesamt '.scalar keys(%ENV).' Umgebungsvariablen'))."\n".  
      $cgi->end_table().  
      $cgi->end_html();

Das ist nur dazu da, die Umgebungsvariablen abzufragen. Es ist nun völlig wurscht, ob ich das "env.pl" oder "env.cgi" nenne, das zeigt so und so jeweils die gewünschte Ausgabe. Auch die shebang darf ruhig so lauten wie angegeben. Wenn ich sie auf _meinen_ Pfad zum Perlinterpreter abändere
   #!D/Perl/bin/perl5.10.0.exe -w
kann ich "ScriptInterpreterSource registry" auskommentieren, und das Script wird trotzdem ausgeführt - ebenfalls unabhängig von der gerade vergebenen Dateinamensendung.

Grüße aus Berlin

Christoph S.

[Patrick Andrieu]

Hallo Christoph!

Das Problem mit ScriptInterpreterSource und dem Apache-Absturz habe ich immer noch nicht gelöst
Das ist auch schwer lösbar, da es sich nicht reproduzieren läßt

Das lag einzig und allein an die fehlende Option ExecCGI für den aliased cgi-bin-Directory.

Das ist nur dazu da, die Umgebungsvariablen abzufragen. Es ist nun völlig wurscht, ob ich das "env.pl" oder "env.cgi"

Bei mir aber nicht. Wenn ich .cgi als Dateiendung nehme, muss die Shebang den vollen Windows-Pfad enthalten, UNIX-Shebang geht da nicht.

Ist die Endung .cgi bei Dir mittels Registry-Schlüssel denn mit Perl verknüpft (shell->command)?

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo Patrick,

Ist die Endung .cgi bei Dir mittels Registry-Schlüssel denn mit Perl verknüpft (shell->command)?

Nein. Es gibt aber einen Schlüssel
   HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts.cgi\OpenWithList
und für diesen Schlüssel den Wert "perl.exe". Das ist die "Ausführungsberechtigung". Du mußt den Eintrag nicht händisch vornehmen; er wird erzeugt, wenn du ein (beliebiges) *.cgi-File über "Eigenschaften" und "öffnen mit" mit der perl.exe verknüpfst. Der ActivePerl-Installer legt solche Ausführungsberechtigungen ausschließlich für *.pl fest - aber Scripts, die der Perl-Interpreter "ausführen" lassen soll, müssen eben dieses "Recht" auch haben. Unter Linux ist das bekanntlich 755, unter Windows ist das eben eine solche "OpenWithList" in der registry.

Grüße aus Berlin

Christoph S.

[Patrick Andrieu]

Hallo Christoph!

Du mußt den Eintrag nicht händisch vornehmen; er wird erzeugt, wenn du ein (beliebiges) *.cgi-File über "Eigenschaften" und "öffnen mit" mit der perl.exe verknüpfst.

Siehste... ich habe .cgi mit meinem Default-Editor auf diese Weise »verknüpft«... Öffnen mit: EditPad.exe. Der Indianer mag das aber nicht, dem Xitami ist es egal, er liest nur die UNIX-Shebang und entfernt »/usr/bin/«. Ich hab's mir einer Datein namens goekgoekgoek.goek probiert (mit UNIX-Shebang)... funzt(TM)! Ich könnte die Datei »christoph.schnauss« nennen, der Xit würde das managen!

Viele Grüße aus Frankfurt/Main,
Patrick

[Christoph Schnauß]

hallo Patrick,

Ich könnte die Datei »christoph.schnauss« nennen, der Xit würde das managen!

Nö. Ich kenne den Typ schließlich ein bißchen. "christoph.schnauss" ist resistent gegenüber allen Management-Bemühungen. Und bisher auch - wie im Threadtitel vorgegeben - nicht reproduzierbar.

;-)

Grüße aus Berlin

Christoph S.

[Christoph Schnauß]

hallo Silke,

mit http://www.test.de

Das ist die Adresse der Stiftung Warentest. Ich kann nicht glauben, daß sie dir "gehört".

Grüße aus Berlin

Christoph S.

[Silke]

Bei mir ist dies ähnlich (von XAMPP angelegt) allerdings auf Laufwerk C:

Genauer:
C:/xampp/
darunter auf gleicher Ebene:
anonymous, apache, cgi-bin, htdocs, ..., perl, ....

Meine Programme aber sind im Laufwerk E:/test bzw. E:/test/cgi-bin
bzw. E:/test/cgi-bin/ugb
Gruß
Silke

[Patrick Andrieu]

Hallo Silke!

Ergebnis ist
C:/xampp

Auch das verstehe ich trotz Struppis Erklärungen nicht. Cwd... das Modul heißt so und der Name steht für »current working directory«.

Wenn ich das bei mir lokal oder auf dem Webspace ausgeben lasse, erhalte ich IMMER cgi-bin, wenn sich das Skript im cgi-bin befindet. Das ist das current working directory, nämlich das, wo sich das Skript befindet.

Entweder stimmt das mit der Definition eines current working directory oder »FindBin - Locate directory of original perl script« nicht, oder Xampp gehört einfach in die Tonne.

Viele Grüße aus Frankfurt/Main,
Patrick

[Silke]

Hallo Ihr!
Ich habe jetzt mal die beiden mit require aufgerufenen Teile direkt ins rufende Programm aufgenommen. Damit läuft das Programm (habe noch nicht alles bis ins Detail getestet).
Es scheint alles zu klappen bis auf das "require", das offensichtlich auch bei anderen Anwendern Probleme machte.
Natürlich wäre es unschön, wenn die config.pl nicht isoliert wäre.
Gibt es vielleicht eine andere Methode, dieses aufzurufen, die funktioniert?

[Struppi]

Es scheint alles zu klappen bis auf das "require", das offensichtlich auch bei anderen Anwendern Probleme machte.

Die machen irgendwas falsch. Man muss aber auch sagen, dass die Struktur nicht unbedingt optimal und übersichtlich ist. In deinem Fall muss die Struktur in etwa so aussehen:
c:\test\cgi-bin\ugb\ugb.pl
c:\test\cgi-bin\ugb\config.pl
c:\test\cgi-bin\web-lib.pl

Der aufruf: http://localhost/cgi-bin/ugb/ugb.pl

Struppi.

[Struppi]

Nutzers meines Gästebuchs sind meistens damit zufrieden und kommen fast alle damit klar, so dass ich keinen Support leisten muß.

Das wundert mich.

Ich hab grad versucht es zu installieren und tu mich sehr schwer. Mal abgesehen von den vielen Pfaden die man ändern muss (ich hab kein cgi-bin Verzeichniss, ich strukturier das anders), krieg ich den Link auf der Startseite (also wenn ich ugb.pl aufrufe) nicht geändert. Das steht nur 'XXXVerlinken%20Sie%20hier%20Ihre%20FormularseiteXXX' - Ja schön, aber wo soll ich das tun? In der config.pl? Das ist kein derartiger Eintrag.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Das wundert mich.

Ist ja auch eher für Perl-Laien, nicht für fortgeschrittene User, die selbst sowas schreiben können ;)

krieg ich den Link auf der Startseite (also wenn ich ugb.pl aufrufe) nicht geändert. Das steht nur 'XXXVerlinken%20Sie%20hier%20Ihre%20FormularseiteXXX' - Ja schön, aber wo soll ich das tun?

In der Datei »header« im Ordner ugb/files. Diese Dateien sind editierbar und in der Demo- und Download-Version neutral (schlicht) gehalten.

Viel Spaß noch beim Testen ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

krieg ich den Link auf der Startseite (also wenn ich ugb.pl aufrufe) nicht geändert. Das steht nur 'XXXVerlinken%20Sie%20hier%20Ihre%20FormularseiteXXX' - Ja schön, aber wo soll ich das tun?

In der Datei »header« im Ordner ugb/files. Diese Dateien sind editierbar und in der Demo- und Download-Version neutral (schlicht) gehalten.

Diese vielen einezlnen Dateien machen die Sache aber unübersichtlich. Aber auf jeden Fall läuft die ugb.pl, die die web-lib.pl (die meines erachtens  komplett überflüssig ist, da der header besser mit CGI::header() ausgegeben wird und Datumsfunktion in einer Datei web-lib?) d.h. das Skript sollte laufen.

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Diese vielen einezlnen Dateien machen die Sache aber unübersichtlich.

Nun ja... Vielleicht hätte nur eine header und eine footer und eine für die »Mitte« gereicht. Ziel war, den Usern ein Anpassen zu ermöglichen, ohne im Skript 'rumzupfuschen. Ganz gelungen ist es mir nicht, das Skript ist ja von 2006, die letzten Versionen sahen nur kleine Korrekturen. Damals war ich in Perl nicht so weit wie heute, hatte aber bisher keine große Lust, das Teil komplett neu zu schreiben - was ja, falls Du im Code 'reingeschaut hast, dringend nötig wäre (bitte daher Kommentare über den Code lieber nicht posten *g*). Aber man kennt es ja, never change a running... ;)

Aber auf jeden Fall läuft die ugb.pl, die die web-lib.pl (die meines erachtens  komplett überflüssig ist

Ja, in der Tat.

d.h. das Skript sollte laufen.

Es läuft ja, sogar wirklich Ahnungslosen habe es geschafft, es zu installieren. Nur das mit der lokalen Xampp-Installation läuft eben nicht. Engin war der erste, der über Probs berichtete, dann ein anderer User vor kurzem und zuletzt Silke. Dass alle an ihrem Apache groß herumkonfiguriert haben, glaube ich daher weniger.

Vielen Dank für die Mühe mit dem Testen! Was machst Du jetzt mit dem Gästebuch? ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Günther]

Hallo Struppi, hallo Patrick,

habe den Thread verfolgt, u.a. weil ich auch auf der Suche nach einem "einigermassen" sicheren Gästebuch bin.
Da bin ich ja auf zwei Cracks gestoßen.
Wäre es nicht eine reizvolle Aufgabe, Euer Wissen zusammenzuwerfen und das Gästebuch auf Euren jetzigen Wissensstand zu bringen?
Die Self-Gemeinde würde Euch sicherlich dankbar sein.
Vielleicht findet sich auch noch eine dritte Person, die das XAMPP-Problem lösen kann.
Dann würde ich mir neben dem Gästebuch vielleicht auch noch den XAMPP-Server anlachen!
Viele Grüße
aus Freiburg

Günther

[Patrick Andrieu]

Hallo Günther!

habe den Thread verfolgt, u.a. weil ich auch auf der Suche nach einem "einigermassen" sicheren Gästebuch bin.
Da bin ich ja auf zwei Cracks gestoßen.

Auf anderthalb. Wobei Struppi der ganze ist, und ich nur die Hälfte ;)

Wäre es nicht eine reizvolle Aufgabe, Euer Wissen zusammenzuwerfen und das Gästebuch auf Euren jetzigen Wissensstand zu bringen?

Ob Struppi dazu Lust hat, weiß ich nicht. Du kannst aber das GB in der jetzigen Fassung testen und berichten, was Dir dabei nicht gefällt.

Dann würde ich mir neben dem Gästebuch vielleicht auch noch den XAMPP-Server anlachen!

Das lässt sich auch sicher lösen! Aber wenn schon Webserver, dann richtig. Zuerst eine ordentliche Perl-Installation ohne Webserver (für Windows: ActivePerl von ActiveState), dann ein richtiger Apache. Und nicht so eine lite-Version, auch noch anscheinend problembehaftet wie Xampp, Ach ja... der eine User hat auch noch Probleme mit PHP und MySQL unter Xampp, allen Anschein nach ist es wieder ein Pfad-Problem ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Ob Struppi dazu Lust hat, weiß ich nicht. Du kannst aber das GB in der jetzigen Fassung testen und berichten, was Dir dabei nicht gefällt.

[1]
Ein möglichkeit fürs inkludieren von HTML Dateien in die Templates wäre nicht schlecht, und
vielleicht noch ein wenig BBCode.
Und eine "Beitrag vom Admin freischalt funktion".
[1]

Grüße und *SCNR*,
Engin
 GYRO

[1] Jaa,     ich weiß,      hatten wir schon  :-)

[Patrick Andrieu]

Hallo Engin!

Ein möglichkeit fürs inkludieren von HTML Dateien in die Templates wäre nicht schlecht, und

Siehe Antwort an Pe.Mu...

vielleicht noch ein wenig BBCode.

Damit würde man das unmögliche Gästebuch wieder zu einem möglichen machen - nein, das war nicht die Absicht, die hinter »unmöglich« stand. Und kotzende Smileys sind was für Teenies, die können sich unter den vielen anderen freien Gästebüchern einen passenden suchen, mit laolas und Keulen und würg und so... ;)

Und eine "Beitrag vom Admin freischalt funktion".

Das verstehe ich nicht (oder hab's vergessen -> wir mailen ja schon seit langem mittlerweile, ich bin älter als Du und kann mir nicht alles merken. Frische also das Gedächtnis auf eines älteren Mitmenschen, der sich nicht alles merkeln kann.)!

[1] Jaa,     ich weiß,      hatten wir schon  :-)

Eben!

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Ein möglichkeit fürs inkludieren von HTML Dateien in die Templates wäre nicht schlecht, und

Siehe Antwort an Pe.Mu...

 sub BookHeader  
 {  
         print '<div id="Navi">', "\n";  
         open (INCFILE, "/m1.inc") || Error($Why."Datei m1.inc nicht gefunden");  

Das muss ich mal testen, wenn ich Zeit finde, ist gebookmarkt.

Damit würde man das unmögliche Gästebuch wieder zu einem möglichen machen - nein, das war nicht die Absicht, die hinter »unmöglich« stand.

Wie darf ich das verstehen?

Und eine "Beitrag vom Admin freischalt funktion".

Das verstehe ich nicht (oder hab's vergessen -> wir mailen ja schon seit langem mittlerweile, ich bin älter als Du und kann mir nicht alles merken. Frische also das Gedächtnis auf eines älteren Mitmenschen, der sich nicht alles merkeln kann.)!

Immer schön auf´s alter abwinden. :)

Eine "Beitrag vom Admin freischalt funktion" soll heissen, das neue Einträge
nicht sofort ins GB eingetragen werden sondern vom Admin erst frei gegeben werden müssen.
Also Admin sieht die Einträge zuerst und bei nicht gefallen werden die erst garnicht veröffentlicht.

Und vielleicht eine Vorschau Funktion, ein geeignetes Background img ist ja schon da, Copyrights haste auch.  :)

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

Damit würde man das unmögliche Gästebuch wieder zu einem möglichen machen - nein, das war nicht die Absicht, die hinter »unmöglich« stand.
Wie darf ich das verstehen?

Wenn man z.B. [url]...[/url] möglich macht, hat man es sehr schnell wieder mit allen möglichen URL-Spammern zu tun, die ellenlange Linklisten zu zweifelhaften Seiten posten.

Eine "Beitrag vom Admin freischalt funktion" soll heissen, das neue Einträge
nicht sofort ins GB eingetragen werden sondern vom Admin erst frei gegeben werden müssen.
Also Admin sieht die Einträge zuerst und bei nicht gefallen werden die erst garnicht veröffentlicht.

Ja, ok... dafür wirst Du aber nach jedem erfolgreichen Post per Mail informiert und kannst also fast in Echtzeit löschen oder kommentieren.

Und vielleicht eine Vorschau Funktion,

Ja, das ist eine Idee.

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Wenn man z.B. [url]...[/url] möglich macht, hat man es sehr schnell wieder mit allen möglichen URL-Spammern zu tun, die ellenlange Linklisten zu zweifelhaften Seiten posten.

Und genau an dieser Stelle würde die "Beitrag muss vom Admin freigegeben funktion" ihre volle Macht demonstrieren. :)
Und man könnte es dem Nutzer, der das GB bei sich einsetzt überlassen, ob er
BBCode möchte oder nicht, also im Admin Panel eine abfrage, "möchten sie BBCode aktivieren?", wäre auch noch ne Idee.

Ja, ok... dafür wirst Du aber nach jedem erfolgreichen Post per Mail informiert und kannst also fast in Echtzeit löschen oder kommentieren.

Ich weiss, es scheint manchmal, als würde ich 24 Stunden vorm Rechner hocken, dem ist aber nicht so.  ;-)
Auch _Engine muss von Zeit zu Zeit tanken ehh schlafen.

Grüße,
Engin
 GYRO

[Patrick Andrieu]

Hallo Engin!

Wenn man z.B. [url]...[/url] möglich macht, hat man es sehr schnell wieder mit allen möglichen URL-Spammern zu tun, die ellenlange Linklisten zu zweifelhaften Seiten posten.
Und genau an dieser Stelle würde die "Beitrag muss vom Admin freigegeben funktion" ihre volle Macht demonstrieren. :)

Du kennst ja meine tägliche Logauswertung... Die POST-Requests sind ja rot vermerkt. Nur werfe mal einen Blick drauf, und entscheide mal, ob du bis zu 50 sinnlose Beiträge am Tag durchlesen willst, um vielleicht einen davon zu »genehmigen«...

Das GB blockt alle diese Versuche bisher erfolgreich ab. Nur manuelle Spammer kommen durch, wenn sie trotz Stinkefinger-Seite hartnäckig das GB suchen.

Viele Grüße aus Frankfurt/Main,
Patrick

[Engin]

Hi Patrick,

Du kennst ja meine tägliche Logauswertung... Die POST-Requests sind ja rot vermerkt. Nur werfe mal einen Blick drauf, und entscheide mal, ob du bis zu 50 sinnlose Beiträge am Tag durchlesen willst, um vielleicht einen davon zu »genehmigen«...

Deine Seite ist ja auch eine ausnahme erscheinung. :)
Die robots können ja weiterhin vom Script geblockt werden, ein Manueller Spammer überlegt
es sich 2 mal, bevor er postet, wenn über dem GB steht,
"Neu einträge werden vor der veröffentlichung durch einen Admin geprüft".
Nicht alle haben diese immensen Spam-attacken. Es sollte ja auch eine funktion sein, die man einschalten kann oder nicht,
da würde dann ein kleiner vermerk neben der Funktion ja vollkommen reichen.
Das heisst, jeder, der es aktiviert und nutzt, weiss, worauf er sich einlässt.

Das GB blockt alle diese Versuche bisher erfolgreich ab. Nur manuelle Spammer kommen durch, wenn sie trotz Stinkefinger-Seite hartnäckig das GB suchen.

Spammer sind halt unmenschen, die machen sich nichts aus beleidigungen. :)
Die kriegen ja schliesslich ein Backlink auf ihre Seite. ;-)

Grüße,
Engin
 GYRO

[Struppi]

Es läuft ja, sogar wirklich Ahnungslosen habe es geschafft, es zu installieren. Nur das mit der lokalen Xampp-Installation läuft eben nicht. Engin war der erste, der über Probs berichtete, dann ein anderer User vor kurzem und zuletzt Silke. Dass alle an ihrem Apache groß herumkonfiguriert haben, glaube ich daher weniger.

Ach, was was mir grad einfällt, der Apache installiert per default ein separates cgi-bin Verzeichniss. D.h. wenn du auf http://localhost/cgi-bin/ zugreifst wird eine Skript in LW://Apache/cgi-bin (Beispiel) aufgerufen, während http://localhost z.b. unter LW:User/web/ liegt. D.h. das cgi-bin kann auf einem komplett anderem Laufwerk sein in einem komplett anderem Verzeichniss.

Vielen Dank für die Mühe mit dem Testen! Was machst Du jetzt mit dem Gästebuch? ;)

Gar nichts, ich wollte mich nur ein wenig gruseln ;-)
Nee, ich wollte sehen ob im Skript dir Ursache für den Fehler ist.

Als Tipp für eine potentielle neue Version:

use strict;!!!!  
use CGI (aber richtig)  
use HTML::Template;  
use Fcntl; qw(:FLOCK)  

Struppi.

[Patrick Andrieu]

Hallo Struppi!

Ach, was was mir grad einfällt, der Apache installiert per default ein separates cgi-bin Verzeichniss. D.h. wenn du auf http://localhost/cgi-bin/ zugreifst wird eine Skript in LW://Apache/cgi-bin (Beispiel) aufgerufen, während http://localhost z.b. unter LW:User/web/ liegt. D.h. das cgi-bin kann auf einem komplett anderem Laufwerk sein in einem komplett anderem Verzeichniss.

Das verstehe ich jetzt nicht (liegt vielleicht am Glas Rotwein auf leerem Magen als Aperitif - die zusammengewürfelte »Familie« ißt gleich)...

Gar nichts, ich wollte mich nur ein wenig gruseln ;-)

Dachte ich mir ;)

Als Tipp für eine potentielle neue Version:
use strict;!!!!

Das ist klar.

use CGI (aber richtig)

Da habe ich noch meine Probleme (XHTML wird als transitional ausgeliefert, da muss man herumdoktern, und der Output - naja - auch das Pretty-Teil ist da nichts besonders... ich hab's nun mal gern straight, auch wenn ich »wie Christoph« bin *g*)...

use HTML::Template;

Habe mich damit noch nicht beschäftigt - ist eher Siechfreds Liebling ;)

use Fcntl; qw(:FLOCK)

Das auf jeden Fall.

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

Das verstehe ich jetzt nicht (liegt vielleicht am Glas Rotwein auf leerem Magen als Aperitif - die zusammengewürfelte »Familie« ißt gleich)...

Guck dir mal die Ausgabe von @INC von Silke an:
Vor der obigen Änderung:
@INC contains:
C:/xampp/perl/site/lib/
E:/test/cgi-bin                   <= hier liegt web-lib.pl und ugb

Hier liegt das cgi-Verzeichniss, dass rufst du auf, wenn du http::localhost/cgi-bin aufrufst.

Das home Verzeichniss, also das das über http::localhost erreichbar ist, ist vermutlich dort: C:/xampp/web

d.h. die pl Dateien müssen alle in den cgi-bin Ordner, vermutlich machen da "deine" Problemfälle etwas falsch.

Als Tipp für eine potentielle neue Version:
use CGI (aber richtig)

Da habe ich noch meine Probleme (XHTML wird als transitional ausgeliefert, da muss man herumdoktern, und der Output - naja - auch das Pretty-Teil ist da nichts besonders... ich hab's nun mal gern straight, auch wenn ich »wie Christoph« bin *g*)...

Du bist wie Christoph, der output interessiert dich doch nicht, aber das du sowieso

use HTML::Template;

verwendest spielt das keine Rolle.

Herumdoktern ist auch relativ, du musst nur beim einbinden ein entsprechenden Schalter setzen um XHTML zu vermeiden (der erstaunlicherweise -no_xhtml heißt), ansonsten sparst du dir viel Tipparbeit und eingebunden ist sie sowieso.

Habe mich damit noch nicht beschäftigt - ist eher Siechfreds Liebling ;)

Mittlerweile auch meiner, man muss sich erstmal dran gewöhnen aber dann...

Struppi.

[Patrick Andrieu]

Hallo Struppi!

d.h. die pl Dateien müssen alle in den cgi-bin Ordner, vermutlich machen da "deine" Problemfälle etwas falsch.

Wie gesagt (siehe Antwort an Silke), fällt mir schwer zu glauben...

[CGI-Modul]
Du bist wie Christoph, der output interessiert dich doch nicht

Doch, ich will well formed (X)HTML und nicht alles in einer Zeile und nicht alles so, wie ich es halt nicht haben will ;)

Herumdoktern ist auch relativ, du musst nur beim einbinden ein entsprechenden Schalter setzen um XHTML zu vermeiden (der erstaunlicherweise -no_xhtml heißt)

Hm, ich wollte schon XHTML als DOCTYPE, aber nicht transitional sondern strict. Und ohne Herumdoktoren schafft es (wohlgemerkt nach meinem bisherigen Kenntnis- und Studierstand des Moduls) nicht.

Erstens: Warum ist die XHTML-DOCTYPE-Variable eine Konstante?

Zweitens: So geht's dann doch, aber -sorry-, das ist mir zuviel Aufwand:

use CGI::Pretty;
use CGI::Carp qw(fatalsToBrowser);
 CGI::XHTML_DTD->[0] =~ s/Transitional/Strict/;
 CGI::XHTML_DTD->[1] =~ s/transitional/strict/;
print CGI::header();

Ich binde das CGI-Modul mittlerweile in fast jedem Skript ein, aber nicht für die HTML-Ausgabe. Da mache ich lieber, was ich weiß, was dabei rauskommt.

Mittlerweile auch meiner, man muss sich erstmal dran gewöhnen aber dann...

Wobei eigene Templates auch so sind, wie ich sie will (ätsch). Aber OK, das Teil hört sich schon sehr interessant an ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Struppi]

[CGI-Modul]
Du bist wie Christoph, der output interessiert dich doch nicht

Doch, ich will well formed (X)HTML und nicht alles in einer Zeile und nicht alles so, wie ich es halt nicht haben will ;)

Naja, well formed fällt leichter wenn es ein erprobtes Skript macht und alles in einer Zeile ist ja auch nicht.

Herumdoktern ist auch relativ, du musst nur beim einbinden ein entsprechenden Schalter setzen um XHTML zu vermeiden (der erstaunlicherweise -no_xhtml heißt)

Hm, ich wollte schon XHTML als DOCTYPE, aber nicht transitional sondern strict. Und ohne Herumdoktoren schafft es (wohlgemerkt nach meinem bisherigen Kenntnis- und Studierstand des Moduls) nicht.

use strict;  
use CGI;  
my $cgi = new CGI(-no_xhtml);  
  
  
my $HTML_BODY = {  
    -dtd    => '-//W3C//DTD HTML 4.01 Strict//EN" "http://www.w3.org/TR/html4/strict.dtd',  
    -lang   => 'de-de',  
    -title  =>'Titel',  
    -meta   =>  
    {  
        keywords       => '',  
        copyright      => '',  
        'content-type' => "text/html; charset=iso-8859-1"  
    }  
    };  
print $cgi->header(), $cgi->start_html($HTML_BODY), $cgi->end_html();

Das hab ich grad bei mir gefunden, es ist zwar HTML strict, sollte aber leicht anzupassen sein (wobei XHTML strict ja nicht undebingt empfehlenswert ist, soweit ich das mitbekommen hab)

Erstens: Warum ist die XHTML-DOCTYPE-Variable eine Konstante?

Ist es nicht, es ist einfach nur ein Parameter, der beim einbinden des Moduls der Funktion import() übergeben wird.

Zweitens: So geht's dann doch, aber -sorry-, das ist mir zuviel Aufwand:

use CGI::Pretty;
use CGI::Carp qw(fatalsToBrowser);
CGI::XHTML_DTD->[0] =~ s/Transitional/Strict/;
CGI::XHTML_DTD->[1] =~ s/transitional/strict/;
print CGI::header();

Das würde ich nicht machen, das ist ein Eingriff in den Modulcode. Aber was ist daran Aufwand?

Ich binde das CGI-Modul mittlerweile in fast jedem Skript ein, aber nicht für die HTML-Ausgabe. Da mache ich lieber, was ich weiß, was dabei rauskommt.

Das Modul ist >200KB gross und das meiste sind Funktionen für die Ausgabe von HTML (vor allem für Formulare und Tabellen ist das Modul super) und du verwendest sie nicht? Vor allem du machst deinen Perlcode unübersichtlich und mischt was nicht zusammen gehört, deshalb ist ein Template System auf jeden Fall sinnvoll.

Mittlerweile auch meiner, man muss sich erstmal dran gewöhnen aber dann...

Wobei eigene Templates auch so sind, wie ich sie will (ätsch). Aber OK, das Teil hört sich schon sehr interessant an ;)

Hatte ich auch lange, aber ein Templatesystem sollte schon mehr können als nur einen Text ersetzten.

Struppi.

[Christoph Schnauß]

hallo Struppi,

Du bist wie Christoph

Das wage ich stark zu bezweifeln.

der output interessiert dich doch nicht

Es ist unmöglich, herauszufinden, worauf du diese Annahme stützt.

Grüße aus Berlin

Christoph S.

[Struppi]

der output interessiert dich doch nicht

Es ist unmöglich, herauszufinden, worauf du diese Annahme stützt.

Darauf, dass die HTML Ausgabe eines CGI Skriptes in der Regel für den Browser bestimmt ist. Da du sowieso Schwierigkeiten zu haben scheinst irgendwelche Hintergründe deiner Thesen zu vermitteln, kann ich die Annahme nur auf den Regelfall stützten.

Es ist es also sehr fragwürdig seinen Perl Code mit (für das Ergebnis) unnötigen Sachen zu verschmutzen und für den Programmierer unleserlicher zu machen oder auf nützliche Funktionen deshalb zu verzichten, nur weil man glaubt, die  HTML Ausgabe müßte aus irgendeinem nicht nachvollziehbaren Grund mit Newlinezeichen verziert sein.

Und falls es dir (ja, ich bin durchaus in der Lage auch über den Tellerrand zu blicken und mir Gedanken zu machen, welch obskuren Dinge du vielleicht unter Umständen hier mit deinen Geheimnissvollen Äußerungen meinen könntest.) darum geht u.U. den HTML Quelltext zu bearbeiten oder zu modifizieren, empfiehlt es sich sowieso von vorneherein ein Auge auf HTML::Template zu werfen, da dieses Modul für diesen Zweck weitaus besser geeignet ist.

Struppi.