fb18.de
/ Off-Topic
/ Hard- und Softwarefragen
Perl - Shebang und Portabilität
Moep. Bis eben hatte ich noch voller Hoffnung verstanden, dass an folgender Stelle in der httpd.conf ein Standard-Shebang verwendet wird und so für Portabilität sorgt.
# Apache parses all CGI scripts for the shebang line by default.
# This comment line, the first line of the script, consists of the symbols
# pound (#) and exclamation (!) followed by the path of the program that
# can execute this specific script. For a perl script, with perl.exe in
# the C:\Program Files\Perl directory, the shebang line should be:
#!C:/Programme/APerl/perl/bin/Perl.exe
# Note you _must_not_ indent the actual shebang line, and it must be the
# first line of the file. Of course, CGI processing must be enabled by
# the appropriate ScriptAlias or Options ExecCGI directives for the files
# or directory in question.
#
Es scheint dann aber doch mehr ein Hinweis zu sein. Aber gibt es so eine Eintragungsmöglichkeit, wie ich sie mir erhofft hatte, vielleicht trotzdem?
Was genau erhoffst du dir denn?
Das Shebang ist ein Standard-Shebang (wobei ich nicht glaube, das windows jenes parst, aber der Apache vermutlich). Vielleicht hast du noch irgendwas vor dem Shebang stehen? Es muss wirklich das allererste in der Datei (ab dem ersten Byte quasi) sein. Und dem Kommentar nach funktioniert es auch nur in als solchen ausgezeichneten CGI-Verzeichnissen, also jene die per ScriptAlias deklariert wurden.
Ansonsten wäre mal der Fehler (im Errorlog?) oder das Fehlverhalten interessant.
Ich erhoffe mir, dass ich halt ein Skript habe, dass ich auf jeden PC ausführen kann, ohne diese Zeile anzupassen, da diese vom Apache übernommen wird.
Na ja. Also in der httpd.conf steht noch eine Menge vor der Zeile. [28] Also es geht nicht um die Zeile im Perl-Skript. Das ist ja gerade der Portabilitätsblocker, den ich nicht will. Wenngleich ich ihn parallel auch schon drin gelassen habe, in der Hoffnung, dass er dann vom Apache überschrieben wird. Fehlanzeige.
Die Deklaration per ScriptAlias würde mich auch nicht glücklicher machen. Ich habe es jetzt trotzdem mal probiert und das Verzeichnis explizit angegeben. Ebenfalls Fehlanzeige.
Das Errorlog zeigt eine Meldung an, wie wenn halt die Zeile falsch oder fehlend ist:
[Sun Jun 10 13:08:09 2007] [error] [client 127.0.0.1] E:/Web-Sites/dynamic_e/userdata/perl/a.cgi is not executable; ensure interpreted scripts have "#!" first line
[Sun Jun 10 13:08:09 2007] [error] [client 127.0.0.1] (9)Bad file descriptor: don't know how to spawn child process: E:/Web-Sites/dynamic_e/userdata/perl/a.cgi
Hm das ist schwierig. EIn Shebang hilft dir so nichts, was Portabilitäüt angeht, weil der Pfad ja auf jeder Maschine wieder anders sein kann. Du könntest dein Apache auf mod_perl trimmen oder darauf, die ENdung .pl als Perl-Skript zu interpretieren. Das könnte zumindest etwas portabler sein. Oder aber du legst deiner Distribution ein Perlskript bei, was die erste Zeile aller Skripte ersetzt, quasi ein install-skript.
Ja, ich weiß doch dass der Pfad auf jeder Maschine anders ist. Darum geht es mir doch hier. Dass dieser Shebang dynamisch aus dem Apache gezogen wird.
Die Skripte werden ansonsten vom Apache auch schon automatisch als Perl-Skript erkannt. Das ist ja alles nicht mein Problem.
Das mit dem Skript wäre fein. Denn die Perlskripte die ich nutze, werden von meinem Programm ohnehin erst generiert. Das gibt allerdings zwei Probleme. Unter nicht Windows-Systemen ist die Frage, ob mein Skript dann überhaupt auf die Konfigurationsdatei des Apaches zugreifen kann, um den Wert auszulesen. Das viel größere Problem ist aber, dass wenn diese Zeile in der Apachekonfig nur als Hinweis und nicht als Konfiguration gedacht ist, sie niemand entsprechend nutzen wird. Von daher klappt das auch nicht. :(
#!/usr/bin/env perl
Funktioniert ueberall, sogar unter dem besten OS aller Zeiten… also nicht so ohne weiteres, aber was funktioniert da schon ohne weiteres [22]… aber es gibt apache{,2} und perl als Cygwin-Packete, dass laesst hoffen…
#!Perl.exe funktioniert mit entsprechender Umgebungsvariable unter Windows auch. Nur klappt es dann halt nicht bei den 5%, die Linux nutzen. Und ich habe halt auch ein Herz für Minderheiten. ;)
#!/usr/bin/env perl
Ist auf WIndows auch nur so mittelmäßig portabel. Also es erfordert wieder eine speziell eingerichtete Umgebung.
Ja, ich weiß doch dass der Pfad auf jeder Maschine anders ist. Darum geht es mir doch hier. Dass dieser Shebang dynamisch aus dem Apache gezogen wird.
Das wird definitiv nicht passieren, der Apache manipuliert die Skripte nicht.
Das mit dem Skript wäre fein. Denn die Perlskripte die ich nutze, werden von meinem Programm ohnehin erst generiert. Das gibt allerdings zwei Probleme. Unter nicht Windows-Systemen ist die Frage, ob mein Skript dann überhaupt auf die Konfigurationsdatei des Apaches zugreifen kann, um den Wert auszulesen. Das viel größere Problem ist aber, dass wenn diese Zeile in der Apachekonfig nur als Hinweis und nicht als Konfiguration gedacht ist, sie niemand entsprechend nutzen wird. Von daher klappt das auch nicht. :(
Auf Unixsystemen weiß der Apache meist nichtmal ob und wo Perl liegt, da ist schon angesprochenes /usr/bin/env perl wiederum das Ding der Wahl um den Perl-Interpreter zu finden. Kann ein Perlskript nicht eventuell erfragen, was "sein" aktueller Interpreter ist? Ansonsten köntne man noch was Systemabhängiges machen, ala
1. Probieren, ob /usr/bin/env perl was zurückgibt
2. Ansonsten per Windows-Modul (dieser Activeperlkram hat doch ne WIndowsmodulanbindung) die Anwendung, die mit .pl-Dateien evrknüpft ist finden
3. … ?
X. Den User Fragen
oder so.
Die Shebang Zeile wird doch von Unix Kernel ausgewertet, und nicht etwa vom Apache oder so.
So einen Mechanismus gibt es doch unter Windows (ohne Cygwin) gar nicht, hier sollte doch das richtige Programm über Dateiendung und Registry gefunden werden, und die Shebang Zeile als Kommentar ignoriert werden.
So einen Mechanismus gibt es doch unter Windows (ohne Cygwin) gar nicht, hier sollte doch das richtige Programm über Dateiendung und Registry gefunden werden, und die Shebang Zeile als Kommentar ignoriert werden.
Halt ich auch für den sinnvollsten Weg. Mir widerstrebts auch, ausgerechnet für Perlscripts Cygwin zu benutzen, versucht doch Perl selbst von den betriebssystemspezifischen APIs zu abstrahieren.
Das wird definitiv nicht passieren, der Apache manipuliert die Skripte nicht.
Optimalerweise soll er das auch nicht. Die Shebang-Anweisung kann ja in der Datei stehen bleiben. Das Skript wird halt einfach nur mit dem Perl aufgerufen, dass in der Apache-Config steht. Meinetwegen mit perl -ignore_shebang_from_script. Geht nicht, gut weiß ich jetzt auch, hätte aber eigentlich nichts gegen gesprochen, denn die Config des Webservers wäre ja ein schöner Ort für die Systemunabhängigkeit gewesen.
Kann ein Perlskript nicht eventuell erfragen, was "sein" aktueller Interpreter ist? Ansonsten köntne man noch was Systemabhängiges machen, ala
Das wäre natürlich auch noch eine schicke Idee, ein Script laufen zu lassen, dass gar nicht über den Webserver aufgerufen wird. Dem gehe ich mal nach. Danke!
X. Den User Fragen
Das wäre dann die Notfall-Lösung, dass der Nutzer das beim Setup angeben muss. Aber das wäre ja extra Arbeit. %)
Die Shebang Zeile wird doch von Unix Kernel ausgewertet, und nicht etwa vom Apache oder so.
Ja, in diesem Fall ganz schön unpraktisch. :)
So einen Mechanismus gibt es doch unter Windows (ohne Cygwin) gar nicht, hier sollte doch das richtige Programm über Dateiendung und Registry gefunden werden, und die Shebang Zeile als Kommentar ignoriert werden.
Hö? Wie meinen? Registry? Nein, eigentlich nicht. Lokal über die Umgebungsvariable, per Webserver halt auch über die Shebang-Zeile. Oder wie meinen?
So einen Mechanismus gibt es doch unter Windows (ohne Cygwin) gar nicht, hier sollte doch das richtige Programm über Dateiendung und Registry gefunden werden, und die Shebang Zeile als Kommentar ignoriert werden.
Hö? Wie meinen? Registry? Nein, eigentlich nicht. Lokal über die Umgebungsvariable, per Webserver halt auch über die Shebang-Zeile. Oder wie meinen?
Wenn du unter Windows auf ne Datei clickst, dann schaut das Teil sich die Endung an, schaut in der Registry nach welches Programm zuständig ist, und Ruft das entsprechende Programm auf.
Ich hab wohl aber den Thread nicht komplett gelesen, offensichtlich macht Apache unter Windows was anderes …
Ja, es geht hier um eine Webanwendung, da wird nichts geklickt. Diese Verknüpfung von der Du sprichst, ist nur für die GUIs interessant. Der Apache gibt das an die Shell weiter und dort läuft es halt wie geschrieben, über die Umgebungsvariable path, sofern der Aufruf nicht im aktuellen Verzeichnis funktioniert. Die Verknüpfung von Extension und Perl läuft über die Config des Apache.
Ja, es geht hier um eine Webanwendung, da wird nichts geklickt. Diese Verknüpfung von der Du sprichst, ist nur für die GUIs interessant. Der Apache gibt das an die Shell weiter und dort läuft es halt wie geschrieben, über die Umgebungsvariable path, sofern der Aufruf nicht im aktuellen Verzeichnis funktioniert. Die Verknüpfung von Extension und Perl läuft über die Config des Apache.
Nö, nicht nur über die GUI, wenn ich mich richtig erinnere (aucht, ist wirklich lange her, und war Windows 3.1 oder so) dann gibt einen Windows Systemaufruf, zum ausführen einer Datei (irgendwas mit "run" oder so), und der greift auch auf diesen Meschanismus zurück.
Aber der Apache hat offenbar seinen eigenen Mechanismus.
Yip, das sind auch wieder Systemaufrufe von der GUI. Die Shell selbst nutzt die Registry nicht und an diese übergibt der Apache das. Und dort wird einfach nach der Perl.exe im aktuellen Verzeichnis gesucht und wenn sie dort nicht vorhanden ist, wird die Umgebungsvariable 'path' benutzt, um weitere Verzeichnisse zu durchsuchen. Mehr ist da gar nicht.
Ja, das passiert aber nur, weil man seine Unix-Vorgehensweisen mittels Apache ins Boot holt. Wie gesagt, wenn man schon nen mingw32/msvc-Apache benutzt, was spricht dagegen, cgis via run zu starten? Und das ganze funktioniert trotzdem weiter mit mod_perl, juhu :)=
Ich muss noch mal betonen, dass es nicht um das Laufen lassen bei mir, sondern bei einem unbekannten Nutzer geht. Da ist es keine Hilfe, ihm für das Ersparen des einmaligen Eintippens des Interpreterpfades, eine manuelle Konfigurationsaufgabe in die Hand zu drücken.
Ja, das passiert aber nur, weil man seine Unix-Vorgehensweisen mittels Apache ins Boot holt. Wie gesagt, wenn man schon nen mingw32/msvc-Apache benutzt, was spricht dagegen, cgis via run zu starten? Und das ganze funktioniert trotzdem weiter mit mod_perl, juhu :)=
Ja, du musst dann ja aber irgendwie entscheiden, was nun ein CGI Script ist, und was nicht. Unter Unix gibt es dafür das execute bit, was ja unter Windows nicht da ist. Und wenn dann jpegs mit run gestartet werden und Photoshop auf dem Webserver aufgeht, ist das ja auch nicht Sinn der Sache.
Klar, man kann das pro Verzeichniss festlegen, oder eine Liste mit CGI Dateiendung in der Apache Config haben oder so.
Hübsch, wieder was gelernt (auch wenn ich hoffe nie nen Windows-Apache administrieren zu müssen) :)=