Hallo Sosum,
ich versuche es noch zu begreifen:
ModPerl initialisiert globale Variablen LEDIGLICH beim ersten Aufruf. Das scheint auch für INC zu gelten. Daraus habe ich abgeleitet, keine globalen Variablen mehr zu erstellen.
Letzteres ist klar (ich tue es übrigens - m.E. - auch nicht); wieso heißt das aber für @INC, dass "." nur während dieser 'solitären' Initialisierung auf den Pfad des aufrufenden Scripts gesetzt wird und dann aber keineswegs da bleibt (sondern mysteriöser Weise auf "[Lw:]/wampp2" [zurück?] gesetzt wird)?
Ist der Child-Prozess vielleicht 'schon da', wenn man - wie ich - wegen der langen Erstinitialisierung von Wampp2 morgens erst mal die "Hurra-es-hat-geklappt"-Seite anguckt? - Dann wäre mein 1. Aufruf des Scripts mit dem später scheiternden "require" eigentlich der 2. Thread für den Child-Prozess; und weiter spekuliert: dann müsste ich nur warten, bis die in der httpd.conf eingestellte Anzahl der ThreadsProChild 'abgearbeitet' ist, bis mein "require" wieder arbeitet? (auch keine gute Lösung übrigens.)
Vielleicht habe ich aber auch die "Selbstbezogenheit" von "." falsch eingeschätzt, indem ich meinte, es liefere verlässlich den Ausführungsort. Wenn mod_perl das tatsächlich zu allererst ausgeführte Script als "wahres ." ansetzt, ist das vielleicht "/apache/.../start.pl" (?!).
...beachten, dass die Einbindung von Modulen durch "use" unter MODPERL das Modul nur einmal (pro Kindprozess) tatsächlich lädt. Beim nächsten Aufruf wird das Modul also direkt aus dem Hauptspeicher geholt...
(das ist ja, was man von mod_perl erwartet)
...und NICHT initialisiert. Alle Inline-Anweisungen, also Anweisungen ohne Funktionsrumpf, werden deswegen auch NICHT mehr ausgeführt
Wenn ich's recht verstehe, beträfe das nur (Bibliotheks-/Modul-) Funktionen - es sind bei mir nur "sub MyFunction{...}"-Konstrukte -, die mit $_ arbeiten (statt explizit übergebenen Argumenten: "print &MyFunction($MyValue);" etc.)?!
Wenn ich Dich richtig verstehe, dann möchtest Du eigentlich nur zuverlässig Module (unter MODPERL) einbinden.
Ja/Jein - Ich versuche z.Zt., eine bestehende Anwendung so umzuschreiben, dass sie möglichst auf jede L/Wampp-Umgebung portierbar ist. Deshalb würde ich es gern vermeiden, dass man bei jeder Installation in jede der mehrere Dutzend Script-Dateien die gerade gültigen absoluten Pfade eintragen muss; und was an solchen unabdingbar ist, stand bisher auch einfach in einer via "require './config.pl'" eingebundenen "Bibliothek". Dass das unter Apache-2/Perl-5.8/..., wie Wampp2 sie bereitstellt, nicht klappt, liegt also offenbar an mod_perl (ich hatte ja eine Wampp-spezifische httpd.conf-Einstellung in Verdacht [nun, das halbe Apache-Lehrbuch durchgeackert zu haben, ist ja auch was für's Leben :-\
Jedenfalls heißt das, dass mein Versuch, den aktuellen absoluten Pfad dynamisch zu bestimmen + dann in die "require"-Anforderungen einzutragen, letztlich unvermeidlich ist - zumindest, solange ich auf mod_perl 'vorbereitet' sein will. Und 'was Besseres als den letztes Mal skizzierten Code habe ich dafür noch nicht gefunden.
Deshalb nach allem lauten Denken doch noch eine Frage:
...meine Vermutung, dass MODPERL bei den meisten mietbaren Web-Server nicht (ausschliesslich) zum Zuge kommen wird
Heißt das vorsichtig eingeklammerte "ausschliesslich", dass ich als "User" eine Chance oder Möglichkeit hätte, zu bestimmen, ob mein Script über mod_perl 'abgearbeitet' wird (oder vielleicht über einen alternativen Standalone-Interpreter [so es den denn gibt...])? Und/oder: kann ich per Script bestimmen, ob das Programm gerade unter mod_perl läuft oder nicht?
#####
Hallo Nemesis,
...nur, die meisten Anleitungen/Dokumentationen sind wohl doch noch auf englisch und nicht jeder versteht das unbedingt
Stimmt. Und auch ich ziehe, faul wie ich bin, eine gute Übersetzung in jedem Fall vor. Allerdings wäre das letztlich ein Argument, z.B. die Wampp-Apache-httpd.conf künftig in deutscher Übersetzung einzubinden. Es muss ja nicht "FädenFürKind=126" sein, aber wenigstens die Kommentare. Könnte ja sein, dass man darin was ändern muss oder will. Will man, soll man das nicht? Hm, kann sein. Aber wozu will jemand, der nicht in den 'Interna' rumwühlen will, einen Serv.... Ah, nein. Ich frage nicht weiter. Wir begeben uns da auf ein heikles Terrain, nicht wahr?
(Um nicht zu sarkastisch zu klingen: Ich bin, wie sicherlich viele hier, der Xampp-Group dankbar für die tolle Vorarbeit. Wie weit die Leute von da aus gehen wollen - und, wenn's sein muss, Englisch lernen -, sollte man m.E. ihnen überlassen. Usability Labs können auch den Horizont verbauen.)
Besten Dank + Gruß
Claus-Volker