Eigene Perl-Modulbibliothek im XAMPP/Apache unter Windows

[Perry]

Hallo,
nachdem ich in den Apache-Foren keine Lösung gefunden habe, hoffe ich hier einen Spezialisten für Apache unter Windows zu finden.
Ich habe mehrere Domains, die im Internet funktionieren. Dort sind die Perl-Module in der jeweiligen cgi-bin abgelegt und sie werden dort auch gefunden.
In meiner lokalen Testversion funktioniert dies nicht so. Ich habe dort die VHosts definiert und unter diesen die zugehörige cgi-bin. Die Perl-Programme werden gefunden und ausgeführt, nicht aber die Perl-Module.
Leider habe ich in den Conf-Dateien nirgendwo gefunden, wie ich meine eigene Modulbibliothek zuordnen kann.
Please help me!

[hotti]

hi,

In meiner lokalen Testversion funktioniert dies nicht so. Ich habe dort die VHosts definiert und unter diesen die zugehörige cgi-bin. Die Perl-Programme werden gefunden und ausgeführt, nicht aber die Perl-Module.

Wie bindest Du denn die Module ein? Nutzt Du 'use lib'? Hast Du mehrere Perl-Versionen auf Deiner Kiste?

Hotti

[Perry]

Hallo

Wie bindest Du denn die Module ein? Nutzt Du 'use lib'?

Ja

Hast Du mehrere Perl-Versionen auf Deiner Kiste?

Frag mich bitte etwas einfacheres ;-)
Ich habe das Paket von Apachefriends installiert.
Lt. Beschreibung enthält das Paket Perl und Mod_perl.
Bei der Installation gab es aber keine Anfrage, welches verwendet werden soll.
Perry

[hotti]

hi,

Lt. Beschreibung enthält das Paket Perl und Mod_perl.

Aha, mod_perl ;)

Hier musst Du ran. Brief: mod_perl ist im Apache-Webserver so integriert, dass Perl-Scripts nicht selbst den Interpreter rufen, es ist dann so, dass quasi der Webserver selbst der Interpreter ist und die Scripts ausführt. Da dürfte auch der Suchpfad zu Libs, also der Inhalt von @INC ein Anderer sein, als mit dem Perl was auf der Platte drauf ist.

Hierzu müsste ich auch erst ein bischen nachlesen, aber probier mal ein

use lib '/wo/du/wolle/cgi-bin'; # path absolute

vielleicht reicht das schon.

Hotti

[Perry]

Re-Hi,

Hierzu müsste ich auch erst ein bischen nachlesen, aber probier mal ein

use lib '/wo/du/wolle/cgi-bin'; # path absolute

Da komme ich zwar weiter (aber Fehler s.u.), doch diese Änderung müsste ich dann in allen Perl-Programmen vornehmen und zurücknehmen, wenn ich das Programm ins Internet stelle. Das möchte ich möglichst vermeiden.

Zu dem weiteren Fehler:
In dem jetzt gefundenen Modul werden alle Variablen im log angezeigt mit dem Text:
$variablexy will not stay sharedat .....

[hotti]

hi,

Da komme ich zwar weiter (aber Fehler s.u.), doch diese Änderung müsste ich dann in allen Perl-Programmen vornehmen und zurücknehmen, wenn ich das Programm ins Internet stelle. Das möchte ich möglichst vermeiden.

ein
use lib '/foo';

erweitert das @INC-Array. Die Pfade, die bis dahin drinstehen, werden damit nicht verändert.

Zu dem weiteren Fehler:
In dem jetzt gefundenen Modul werden alle Variablen im log angezeigt mit dem Text:
$variablexy will not stay sharedat .....

Schöne 'Suchbegriffe' ;-)
Must Du selber machen.

Hotti

[Perry]

Hi,

In dem jetzt gefundenen Modul werden alle Variablen im log angezeigt mit dem Text:
$variablexy will not stay shared at .....

Schöne 'Suchbegriffe' ;-)
Must Du selber machen.

Habe ich schon, bin aber immer wieder gestoßen auf "Don't write a named subroutine within another named subroutine" bzw. "nested subroutines".
Beides sagt mir nichts und es kann doch auch nicht an meinen Programmen liegen, die ja im Internet anstandslos laufen.

[hotti]

hi,

Habe ich schon, bin aber immer wieder gestoßen auf "Don't write a named subroutine within another named subroutine" bzw. "nested subroutines".
Beides sagt mir nichts und es kann doch auch nicht an meinen Programmen liegen, die ja im Internet anstandslos laufen.

Hmm, nested subroutines, sowas:

  
sub foo{  
  sub bar{}  
}  

Da meckert perl -w aber das lässt sich mit ein bischen Arbeit umschreiben. Wie auch immer, ein bischen Studium mal so zwischendurch

perldoc perlsub

tut immer gut ;)

Hotti

[Perry]

Hi,

Da meckert perl -w aber das lässt sich mit ein bischen Arbeit umschreiben. Wie auch immer, ein bischen Studium mal so zwischendurch

perldoc perlsub

tut immer gut ;)

Das ist zwar richtig, aber in diesem Falle wohl sinnlos, denn diese Konstruktionen habe ich nicht in meinen Programmen - und Internet laufen sie ja korrekt.
Es muss also etwas mit der Umgebung zu tun haben - aber wo da anfangen zu suchen?

[hotti]

hi,

Es muss also etwas mit der Umgebung zu tun haben - aber wo da anfangen zu suchen?

use Config; #  Config - access Perl configuration information

Hotti

[Perry]

hi,

Es muss also etwas mit der Umgebung zu tun haben - aber wo da anfangen zu suchen?

use Config; #  Config - access Perl configuration information

Meintest Du damit die Config Testrechner mit Internet vergleichen?
Ich habe tatsächlich ein Programm gefunden, das die Parameter anlistet (ca. 900 an der Zahl!)

[CPAN]

Das ist zwar richtig, aber in diesem Falle wohl sinnlos, denn diese Konstruktionen habe ich nicht in meinen Programmen

Doch, hast du. Dein Programm ist so schlecht aufgebaut, dass es nicht nur den Experten die Tränen in die Augen treiben würde, sähen sie den Quelltext.

Abhilfe: Stelle alle Subroutinen in den Quelltext nach oben. Schreibe deine Subroutinen so um, dass sie mit Parameterübergabe funktionieren und nicht auf Variablen eines übergeordneten Gültigkeitsbereichs zugreifen. Damit vermeidest du die unbeabsichtigten Closures.

Negativbeispiel:

  
    my $foo = 42; # scoped to end of package!  
    sub bar {  
        $foo = 23;  
    }  

Positivbeispiel:

  
    sub bar {  
        my ($param) = @_;  
        $param = 23;  
        return $param;  
    }  
  
    {  
        my $foo = bar(42); # tightened lexical scope  
    }  

und Internet laufen sie ja korrekt.

Das ist kein Ausschlusskriterium. Dieses Argument kannst du getrost knicken.

PS: Dieses Forum produziert im Allgemeinen keine brauchbare Antworten im Themenbereich Perl, außer ich lese mal wieder Tage später mit. Dieser Thread ist ein Musterbeispiel. Bessere Qualität gibt's bei: http://perl-community.de http://perlmonks.org http://stackoverflow.com

[Alexander (HH)]

Moin Moin!

In dem jetzt gefundenen Modul werden alle Variablen im log angezeigt mit dem Text:
$variablexy will not stay sharedat .....

http://perldoc.perl.org/perldiag.html#Variable-"%25s"-will-not-stay-shared

Wenn Du Apache::Registry benutzt, passieren mit ehemaligen CGI-Scripten seltsame Dinge -- RTFM.

Entweder mod_perl richtig, oder CGI pur. Apache::Registry ist nur eine Krücke.

Noch eleganter: FastCGI -- schnell und trotzdem außerhalb des Webserver-Prozesses. Wenn man mal Mist baut, raucht nicht gleich der ganze Webserver ab.

Oder wenn Du ganz flexibel sein willst, PSGI.

Alexander

[Perry]

Hallo,

Noch eleganter: FastCGI -- schnell und trotzdem außerhalb des Webserver-Prozesses. Wenn man mal Mist baut, raucht nicht gleich der ganze Webserver ab.

Oder wenn Du ganz flexibel sein willst, PSGI.

Bei beiden Vorschlägen muss ich ja wohl die Perl-Programm ändern
(1. FastCGI: use FCGI;
 2. PSGI: In addition to this, the PSGI environment MUST include these PSGI-specific variables:...)
Gruß
Perry

[Alexander (HH)]

Moin Moin!

Noch eleganter: FastCGI -- schnell und trotzdem außerhalb des Webserver-Prozesses. Wenn man mal Mist baut, raucht nicht gleich der ganze Webserver ab.

Oder wenn Du ganz flexibel sein willst, PSGI.

Bei beiden Vorschlägen muss ich ja wohl die Perl-Programm ändern

Richtig. Dafür laufen sie dann aber auch schneller als konventionelle CGIs.

(1. FastCGI: use FCGI;

Richtig, und das ist nicht alles. Siehe auch CGI::Fast.

2. PSGI: In addition to this, the PSGI environment MUST include these PSGI-specific variables:...)

Die Variablen kommen von der jeweiligen Umgebung, die mußt Du nicht selbst setzen. Genauso wenig, wie Du QUERY_STRING oder PATH_INFO selbst setzt.

Siehe auch I have a CGI or mod_perl application that I want to run on PSGI/Plack. What should I do?

Alexander

[Perry]

Ebenfalls Moin Moin!
Das Ganze klingt ja interessant, aber laufen die Programme dann auch im Internet? Oder kann es sein, dass der eine oder andere Provider diese Features nicht unterstützt.
Gruß
Perry

[Alexander (HH)]

Moin Moin!

Das Ganze klingt ja interessant, aber laufen die Programme dann auch im Internet?

Natürlich. Keines der Protokolle ist auf einzelne Maschinen oder lokale Netze beschränkt.

Oder kann es sein, dass der eine oder andere Provider diese Features nicht unterstützt.

Das hängt vom jeweiligen Provider ab, und vom Vertrag. Auf einem (realen oder virtuellen) Rootserver kannst Du treiben, was Du willst, d.h. ALLE Protokolle nutzen. Bei Managed Servern sieht es ähnlich aus. Bei Billist- oder Gratishostern kannst Du froh sein, wenn Du CGIs mit irgendeiner prähistorischen Version von Perl bekommst, da ist der Standard eher "HTML only", mit viel Glück gibt's Server Side Includes oder ein altes PHP.

Der Rest variiert sehr stark. Mein Webhosting-Paket bietet ein altes Perl für Pseudo-CGIs (irgendeine selbst gestrickte "CGI-Beschleunigung" ist da aktiv), PHP und eine winzige MySQL-DB. Von mod_perl oder FastCGI kann man da nur träumen. Andere Hoster nutzen FastCGI, um parallel verschiedene PHP-Versionen anzubieten. Ob man da auch eigene FastCGIs nutzen kann, hängt wiederum vom Hoster ab, und sicherlich auch vom Vertrag.

Alexander

[Jean-Max]

Bounjoun Perry,

Apache unter Windows
Leider habe ich in den Conf-Dateien nirgendwo gefunden, wie ich meine eigene Modulbibliothek zuordnen kann.
Please help me!

Das beste ist, eine eigene Perl-Installation für Windows (z.B. Active State) zu betreiben, und den ganzen XAMPP-Perl-Mitbringsel zu ignorieren.

So betreibe ich es seit Jahren ohne Probleme.

Stichwort: Scriptinterpretersource Registry

Adiou.

[Perry]

Hi,

Apache unter Windows
Leider habe ich in den Conf-Dateien nirgendwo gefunden, wie ich meine eigene Modulbibliothek zuordnen kann.

Das beste ist, eine eigene Perl-Installation für Windows (z.B. Active State) zu betreiben, und den ganzen XAMPP-Perl-Mitbringsel zu ignorieren.

So betreibe ich es seit Jahren ohne Probleme.

Kannst Du dort mehrere Domains definieren mit jeweils eigenen Perl-Verzeichnis und Modul-Bibliotheken?
Kann man dann die Programme unverändert in das Internet übernehmen?
Gruß
Perry

[Jean-Max]

Bounjoun Perry,

Das beste ist, eine eigene Perl-Installation für Windows (z.B. Active State) zu betreiben, und den ganzen XAMPP-Perl-Mitbringsel zu ignorieren.
Kannst Du dort mehrere Domains definieren mit jeweils eigenen Perl-Verzeichnis und Modul-Bibliotheken?

Ich verstehe hier nicht ganz, was Du meinst... ich habe mehrere Virtual Hosts, die entsprechenden Dokumente rufe ich im Browser über beispielsweise: atomic-eggs.test (da ist meine lokale Kopie von Atomic Eggs). Es erfordert natürlich entsprechende Einträge in die hosts-Datei.

Aber alle Perl-Skripte, egal bei welchem Virtual Host, nutzen die Ressourcen meiner Active State Perl-Installation, eigene Module kopiere ich auch dorthin: C:/perl/site/lib oder C:/perl/lib

Kann man dann die Programme unverändert in das Internet übernehmen?

Ja. Dank des Eintrags:

ScriptInterpreterSource registry

in der httpd.conf kann ich unter Windows die übliche Shebang benutzen und brauche vor dem Hochladen auf dem entfernten Server nichts zu ändern - außer vielleicht ein use lib '...', damit eigene Module, die ich bei meinem Hoster nicht unter site/lib kopieren kann, sondern meistens anderswo kopiere, gefunden werden.

Adiou.

[Perry]

Hallo!
Bis hier =>

in der httpd.conf kann ich unter Windows die übliche Shebang benutzen und brauche vor dem Hochladen auf dem entfernten Server nichts zu ändern - außer vielleicht ein use lib '...', damit eigene Module, die ich bei meinem Hoster nicht unter site/lib kopieren kann, sondern meistens anderswo kopiere, gefunden werden.

... läuft es bei Dir genau so wie ich es wünsche.
Nun aber möchte ich keine use lib verwenden, sondern dies in der config bei dem entsprechenden VHost angeben.
Dann brauche ich auch auf dem Testrechner die Perl-Module nicht in die zentrale lib kopieren. Dies insbesondere deshalb, da die Module mit gleichem Namen sich unterscheiden können.

[Jean-Max]

Bounjoun Perry,

Nun aber möchte ich keine use lib verwenden, sondern dies in der config bei dem entsprechenden VHost angeben.
Dann brauche ich auch auf dem Testrechner die Perl-Module nicht in die zentrale lib kopieren. Dies insbesondere deshalb, da die Module mit gleichem Namen sich unterscheiden können.

Mit use lib '...'; erweiterst Du lediglich @INC um die angegebenen Pfade, das heißt, dass zusätzlich zu den default-Ordner perl/lib und perl/site/lib Module in den Verzeichnissen gesucht werden, die Du bei use lib angegeben hast.

Bei meiner lokalen Installation brauche ich nicht (ich kann aber) use lib 'sonstwas'; anzugeben, weil ich meine eigenen Module in die Perl-Verzeichnisse kopiere (vom CPAN heruntergeladenen werden auch dort abgelegt). Da ich allerdings keinen Zugang zu der Perl-Installation bei meinem Hoster, kopiere ich die benötigten Module, die nicht zur Perl-Core-Distro gehören, in einem Verzeichnis namens pm. Und da, und nur da, brauche ich zwingend die Angabe mit use lib '/pm';

Insofern kann ich die Skripte, die ich lokal einsetzte, eins zu eins auf dem entfernten Rechner kopieren - oder erweitere sie mit use lib '/pm';. Diese Zeile habe ich auch in manchem lokalen Skript, auch wenn im Verzeichnis /pm auf dem lokalen Computer keine eigenen Module sind.

Ich hoffe, Du weißt jetzt, was ich meine, ansonsten weiß ich wirklich nicht, was Du meinst... :( ... :)

Adiou.

[Perry]

Ich habe Dich so verstanden, dass Du lokal alle von Dir benötigten Module in die perl/lib oder perl/site/lib kopierst, dann benötigst Du kein use lib. Allerdings benötigst Du es in einigen Fällen in der Internet-Version und es stört aber auch nicht, wenn diese Angabe auch in der lokalen Version vorhanden ist.
Nun, mein Problem ist das umgekehrte. Im Internet kopiere ich die Module jeweils in ein Verzeichnis pm auf dem Server dom1.test, dom2.test,.....
Dort werden sie ohne Angabe von use lib gefunden.
Am lokalen Rechner benötige ich ebenfalls für jede Domain dom1.test, dom2.test ... eine eigene lib, denn die verwendeten Module mit gleichem Namen unterscheiden sich in einzelnen Fällen leicht inhaltlich. Wenn ich die in die perl/lib oder perl/site/lib kopieren würde, würden sie sich ja gegenseitig überschreiben.
Was ich daher nicht verstehe ist folgendes:
Für jeden VirtuellenHost kann ich eine Perl-Lib (cgi-bin) angeben, also müsste es doch auch eine Möglichkeit geben, jeweils eine eigene Modulbibliothek anzugeben.
Schönen Palmsonntag
(ich war der Palmesel, falls Du den Brauch kennst)!

[Jean-Max]

Bounjoun Perry,

Ich habe Dich so verstanden, dass Du lokal alle von Dir benötigten Module in die perl/lib oder perl/site/lib kopierst, dann benötigst Du kein use lib. Allerdings benötigst Du es in einigen Fällen in der Internet-Version und es stört aber auch nicht, wenn diese Angabe auch in der lokalen Version vorhanden ist.

Ja... :)

Im Internet kopiere ich die Module jeweils in ein Verzeichnis pm auf dem Server dom1.test, dom2.test,... Dort werden sie ohne Angabe von use lib gefunden.

Wie dann? @INC entählt - ohne Erweiterung durch use lib '...' - lib und site/lib und das Working Directory (.), also das Verzeichnis, in welchem das Skript selbst liegt. Wie sagst Du Perl dann, dass Module in einem Verzeichnis pm zu finden sind, bzw. von welchem Verzeichnis ist pm ein Unterverzeichnis?

denn die verwendeten Module mit gleichem Namen unterscheiden sich in einzelnen Fällen leicht inhaltlich.

Warum gibts Du ihnen den gleichen Namen, wenn sie doch unterschiedlich sind? Warum nicht nur ein Modul, das so ergänzt ist, dass es allen Anforderungen entspricht?

Was ich daher nicht verstehe ist folgendes:
Für jeden VirtuellenHost kann ich eine Perl-Lib (cgi-bin) angeben, also müsste es doch auch eine Möglichkeit geben, jeweils eine eigene Modulbibliothek anzugeben.

Ich betreue einen Kunden, der bei 1&1 mehrere Domains verwaltet. Alle Domains sind als Virtual Hosts angelegt, deren Verzeichnisse befinden sich derzeit auf der obersten Ebene (wenn man beispielsweise mit FTP auf den Server »geht«). Alle Verzeichnisse enthalten ein eigenes cgi-bin. Und für die Module habe ich ein Verzeichnis auf der obersten Ebene angelegt, also auf der selben Ebene wie die Verzeichnisse für die Virtual Hosts, und auf die alle Skripte, die diese Extra-Module benötigen, mit use lib 'absoluterLinuxPfad' zugreifen:

• pm
• virtual host 1
• • cgi-bin
• • • skript.pl (benötigt meinmodul.pm aus /pm)
• virtual host 2
• • cgi-bin
• • • skript.pl (benötigt anderesmodul.pm aus /pm)
      .
      .
      . usw.

Und was meinst Du mit »Modulbibliothek«? Das Wort »library« bezeichnete in frühreren Perl-Versionen in einer anderen Datei ausgelagerte Funktionen, die mit require eingebunden waren. Was verstehst Du also unter »Bibliothek«? Eine Modulsammlung?

[Palmesel]

Welcher von den Bräuchen? ;)

Adiou.

[Perry]

Hi,

Im Internet kopiere ich die Module jeweils in ein Verzeichnis pm auf dem Server dom1.test, dom2.test,... Dort werden sie ohne Angabe von use lib gefunden.

Wie dann? @INC entählt - ohne Erweiterung durch use lib '...' - lib und site/lib und das Working Directory (.), also das Verzeichnis, in welchem das Skript selbst liegt. Wie sagst Du Perl dann, dass Module in einem Verzeichnis pm zu finden sind, bzw. von welchem Verzeichnis ist pm ein Unterverzeichnis?

Die *.pm befinden sich im gleichen Verzeichnis (cgi-bin) wie Perl-Programme *.pl

denn die verwendeten Module mit gleichem Namen unterscheiden sich in einzelnen Fällen leicht inhaltlich.

Warum gibts Du ihnen den gleichen Namen, wenn sie doch unterschiedlich sind? Warum nicht nur ein Modul, das so ergänzt ist, dass es allen Anforderungen entspricht?

Weil die Auftraggeber "IHRE" Version haben möchten, d.h. ein Unterprogramm, das nur das enthält, was auch für sie notwendig ist

Ich betreue einen Kunden, der bei 1&1 mehrere Domains verwaltet. Alle Domains sind als Virtual Hosts angelegt, deren Verzeichnisse befinden sich derzeit auf der obersten Ebene (wenn man beispielsweise mit FTP auf den Server »geht«). Alle Verzeichnisse enthalten ein eigenes cgi-bin. Und für die Module habe ich ein Verzeichnis auf der obersten Ebene angelegt, also auf der selben Ebene wie die Verzeichnisse für die Virtual Hosts, und auf die alle Skripte, die diese Extra-Module benötigen, mit use lib 'absoluterLinuxPfad' zugreifen:

• pm
• virtual host 1
• • cgi-bin
• • • skript.pl (benötigt meinmodul.pm aus /pm)
• virtual host 2
• • cgi-bin
• • • skript.pl (benötigt anderesmodul.pm aus /pm)
      .
      .
      . usw.

Das geht bei mir nicht. Die virtual hosts sind völlig voneinander isoliert.
Ich kann also keine gemeinsame pm anlegen.

Und was meinst Du mit »Modulbibliothek«?

Damit meinte ich pm

Welcher von den Bräuchen? ;)

Wer in unserer Familie am Palmsonntag als letzter aufsteht, ist der Palmesel.
Es soll schon Leute gegeben haben, die extra den Wecker gestellt hatten, um dies zu vermeiden!

[Jean-Max]

Bounjoun Perry,

Weil die Auftraggeber "IHRE" Version haben möchten, d.h. ein Unterprogramm, das nur das enthält, was auch für sie notwendig ist

Du musst den Auftraggebern nicht immer alles haarklein erzählen, was Deine Programme bzw. Module machen ;)

Das geht bei mir nicht. Die virtual hosts sind völlig voneinander isoliert.

Was heißt das schon wieder?

Ich kann also keine gemeinsame pm anlegen.

Und das?

Fühl Dich nicht auf den Schlips getreten, aber bevor Du weiter an Perl denkst, solltest Du vielleicht Deine Terminologie revidieren, so dass wir alle hier mit den selben Termini von den selben Sachen sprechen.

Perl-Skripte haben die Endung *.pl, *.cgi, aber auch *.husseldiguggel wenn die hppd.conf oder eine .htaccess es so will.

Module (man benutzt das Wort »Bibliothek«, bzw. »Library« nicht mehr) haben die Endung *.pm.

Ich sprach von einem ***VERZEICHNIS*** namens pm (hätte ich nennen können: mymoduls), auf dem die Module liegen, die meine Skripte benötigen. Warum sollte das bei Dir nicht möglich sein? Virtual Hosts (ich hoffe, wir sprechen davon, was man unter Virtual Hosts versteht), liegen auf dem selben Server. Also kannst Du jedes x-beliebige Verzeichnis für Deine Module erstellen und Deine Skripte mit use lib 'absoluterPfad'; bestücken!

Und was meinst Du mit »Modulbibliothek«?
Damit meinte ich pm

Wir halten fest: Du meintest ein Modul.

Wer in unserer Familie am Palmsonntag als letzter aufsteht, ist der Palmesel.

Naja, solange Du nur an Palmsonntag den Esel gibst ;) *SCNR*

Adiou.

[Perry]

Moin,

Das geht bei mir nicht. Die virtual hosts sind völlig voneinander isoliert.
Was heißt das schon wieder?

Auf meinem lokalen Rechner sind die unterschiedlichen Domains t1.test, t2.test,.... als Virtual hosts abgebildet. Ich hätte vielleicht schreiben sollen, meine lokalen virtuellen Hosts entsprechen im Internet verschiedenen Domains bei unterschiedlichen Hostern.

Ich kann also keine gemeinsame pm anlegen.

Und das?

Da habe ich mich auf Deinen Satz bezogen:

Wie sagst Du Perl dann, dass Module in einem Verzeichnis pm zu finden sind, bzw. von welchem Verzeichnis ist pm ein Unterverzeichnis?

Ich sprach von einem ***VERZEICHNIS*** namens pm (hätte ich nennen können: mymoduls), auf dem die Module liegen, die meine Skripte benötigen.

Deshalb hatte ich oben auch von pm geschrieben.

Warum sollte das bei Dir nicht möglich sein? Virtual Hosts (ich hoffe, wir sprechen davon, was man unter Virtual Hosts versteht)

Nicht möglich, weil es im Internet (wie oben kleinlaut zugegeben) keine solchen sind.
Da mein Problem am lokalen Rechner (mit Virtual Hosts) liegt, habe ich das etwas durcheinandergebracht.
Vielleicht jetzt noch einmal mein Problem zusammengefasst:
Ich möchte auf meinem lokalen Rechner die Domains so testen, dass jede sein eigenes Verzeichnis (cgi-bin) für die Perl-Programme hat und auch sein eigenes Verzeichnis für die Perl-Module, wobei diese beiden Verzeichnisse identisch sein dürfen. Das cgi-bin kann ich jeweils in den Conf-Dateien definieren, nicht aber die Modulverzeichnisse.
Ich hoffe, dass ich mich jetzt etwas klarer ausgedrückt habe.
Gruß
Perry

[Jean-Max]

Bounjoun Perry,

Sorry, mein Transportgewerbe hat mich wieder quer durch die Gegenden gejagt... nach dem Motto, heute morgen noch in Paris, heute abend wieder hier... :)

Ich hätte vielleicht schreiben sollen, meine lokalen virtuellen Hosts entsprechen im Internet verschiedenen Domains bei unterschiedlichen Hostern.

Ja, das hättest Du auf jeden Fall schreiben sollen!
Denn das ändert alles, wie Du selbst einsiehst:

Nicht möglich, weil es im Internet (wie oben kleinlaut zugegeben) keine solchen sind.

Vielleicht jetzt noch einmal mein Problem zusammengefasst:
Ich möchte auf meinem lokalen Rechner die Domains so testen, dass jede sein eigenes Verzeichnis (cgi-bin) für die Perl-Programme hat und auch sein eigenes Verzeichnis für die Perl-Module, wobei diese beiden Verzeichnisse identisch sein dürfen. Das cgi-bin kann ich jeweils in den Conf-Dateien definieren, nicht aber die Modulverzeichnisse.
Ich hoffe, dass ich mich jetzt etwas klarer ausgedrückt habe.

Hast Du. Und das stimmt: Du kannst in den Konfigurationsdateien des Apache den Pfad des cgi-bin festlegen. Das kann man sowohl in der httpd.conf sozusagen global machen, als auch (wie ich) die httpd-vhosts.conf (unter /xampp/apache/conf/extra) eintragen:

<VirtualHost *:80>
    ServerName atomic-eggs.test
    ServerAlias www.atomic-eggs.test
    ServerAdmin [e-mail]
    DocumentRoot "//Rechner2/webs/owner/aec"
  <Directory "//Rechner2/webs/webs/owner/aec/">
    Order allow,deny
    Allow from all
    AllowOverride All
    Options +Includes +Indexes
  </Directory>
    ScriptAlias /cgi-bin/ "//Rechner2/webs/owner/aec/cgi-bin/"
</VirtualHost>

<Anmerkung an die andere Forumleser und Entwicklungsansichtnutzer>War da nicht früher ein Button für's Syntax-Highlighting der Apache-Syntax?</Anmerkung>

Die Verzeichnisse, wo die Module liegen kannst Du dann als Unterverzeichnisse vom cgi-bin erstellen. Am Beispiel eines Moduls: Mein::Modul:

-vh xy
--cgi-bin
---Mein
----modul.pm

Es ist m.E. immer gut, sich lokal die gleiche Konfiguration nachzubilden, wie man sie beim Hoster vorfindet. Da Du in Deinem Fall verschiedene Hoster hast, mußt Du andere Wege gehen. Der Weg des geringen Widerstands praktiziere ich seit eh und je ;)

Adiou.