Hallo,
Wird die Ausgabe eines CGI-Skripts nach PHP-Befehlen geparst?
Was muß ich da beachten (Stichwort (Non)Parsed-Header)?
cu, holli
Hallo,
Wird die Ausgabe eines CGI-Skripts nach PHP-Befehlen geparst?
Was muß ich da beachten (Stichwort (Non)Parsed-Header)?
cu, holli
Wird die Ausgabe eines CGI-Skripts nach
PHP-Befehlen geparst?
AFAIK geht das nicht. Standardmäßig kommt es auf keinen Fall vor.
al
Wird die Ausgabe eines CGI-Skripts nach
PHP-Befehlen geparst?
Geht nicht!
PHP wird innerhalb von HTML-Dokumenten verwendet. Diese Dokumente bekommen die Endung .PHP(3).
Dieses Skript wird dann vom PHP-Interpreter bearbeitet und der Server schickt den Output an den Browser.
Perl wird in eigenen Dateien gespeichtert (nicht innerhalb von HTML!) und bekommt die Endung .pl.
Dieses Script wird dann dem Perl-Interpreter gereicht und der Server schickt den Output wiederum an den Browser.
Auf Grund der Tatsache das die Server den aufzurufenden Interpreter an Hand der Dateiendung identifizieren kann also ein Skript niemals von beiden Interpretern gleichzeitig interpretiert werden, wie sollte denn sonst die Dateiendung lauten?
Was muß ich da beachten (Stichwort
(Non)Parsed-Header)?
In diesem Zusammenhang irrelevant!
P.S.: Sollte es Dir trotzdem gelingen, den Server so zu konfigurieren, daß er erst Perl dann PHP, oder umgekehrt, interpretiert, so schick mir umgehend die Conf-Dateien. Die würden mich interessieren.
Gruß
Heiko
Wird die Ausgabe eines CGI-Skripts nach
PHP-Befehlen geparst?
Geht nicht!
PHP wird innerhalb von HTML-Dokumenten
verwendet. Diese Dokumente bekommen die
Endung .PHP(3).
stimmt.
Dieses Skript wird dann vom
PHP-Interpreter bearbeitet und der Server
schickt den Output an den Browser.
stimmt auch.
Perl wird in eigenen Dateien gespeichtert
(nicht innerhalb von HTML!) und bekommt
die Endung .pl.
stimmt nur bedingt.
Die Endung eines Perl oder Shell-Skripts ist bei den meisten Servern irrelevant.
Sie kann .pl .cgi .xyz oder .garnichts lauten. Der Server erkennt lediglich, daß die aufgerufene Datei ausführbar ist und schleift dann die Ausgabe des Skripts an den Browser durch.
Dieses Script wird dann dem
Perl-Interpreter gereicht und der Server
schickt den Output wiederum an den
Browser.Auf Grund der Tatsache das die Server den
aufzurufenden Interpreter an Hand der
Dateiendung identifizieren kann also ein
Skript niemals von beiden Interpretern
gleichzeitig interpretiert werden, wie
sollte denn sonst die Dateiendung lauten?
s.o.
Was muß ich da beachten (Stichwort
(Non)Parsed-Header)?In diesem Zusammenhang irrelevant!
P.S.: Sollte es Dir trotzdem gelingen,
den Server so zu konfigurieren, daß er
erst Perl dann PHP, oder umgekehrt,
interpretiert, so schick mir umgehend die
Conf-Dateien. Die würden mich
interessieren.
An die conf´s komme ich leider nicht ran.
Gruß
Heiko
Also das ganze war so gedacht, daß ein perl-skript html mit php-code ausgibt. Der Server soll die Ausgabe dann parsen und die php-anteile bearbeiten.
Irgendwie geht das bestimmt.
Danke für deine Antwort, holli
Perl wird in eigenen Dateien gespeichtert
(nicht innerhalb von HTML!) und bekommt
die Endung .pl.stimmt nur bedingt.
Ok, ich ging hier vom allg. Windows aus. Unter Linux hast Du natürlich Recht, aber Windows braucht auch für Perl die Zuordnung zw. Endung und Perl-Interpreter.
Von Dingen wie Perl-Skripting innerhalb von HTML mal abgesehen!
Also das ganze war so gedacht, daß ein
perl-skript html mit php-code ausgibt.
Der Server soll die Ausgabe dann parsen
und die php-anteile bearbeiten.
Das ist doch recht einfach:
Bau Dir ein Perl-Skript, welches das gewünchte PHP-Dokument erstellt und unter einem Namen auf dem Server abspeichert. Nachdem dieses Dokument vom Perl-Skript erstellt wurde schickst Du via Perl dem Client noch einen Location-Header mit der URL des, vom Perl-Skript erstellten PHP-Dokuments.
Daraufhin fordert der Client das nun existierende PHP-Dokument an welches dann ganz normal vom PHP-Interpreter geparst wird.
Wobei es mich nun doch interessiert, was Du damit überhaupt basteln willst? Reicht nicht entweder Perl oder PHP? Irgendwie ist das doch von hinten durch die Brust ins Auge, oder???
Gruß
Heiko
Perl wird in eigenen Dateien gespeichtert
(nicht innerhalb von HTML!) und bekommt
die Endung .pl.stimmt nur bedingt.
Ok, ich ging hier vom allg. Windows aus.
Unter Linux hast Du natürlich Recht, aber
Windows braucht auch für Perl die
Zuordnung zw. Endung und
Perl-Interpreter.
Von Dingen wie Perl-Skripting innerhalb
von HTML mal abgesehen!Also das ganze war so gedacht, daß ein
perl-skript html mit php-code ausgibt.
Der Server soll die Ausgabe dann parsen
und die php-anteile bearbeiten.Das ist doch recht einfach:
Bau Dir ein Perl-Skript, welches das
gewünchte PHP-Dokument erstellt und unter
einem Namen auf dem Server abspeichert.
Nachdem dieses Dokument vom Perl-Skript
erstellt wurde schickst Du via Perl dem
Client noch einen Location-Header mit der
URL des, vom Perl-Skript erstellten
PHP-Dokuments.
Daraufhin fordert der Client das nun
existierende PHP-Dokument an welches dann
ganz normal vom PHP-Interpreter geparst
wird.
Das kostet mich einen ganzen request. aber die idee ist gar nicht schlecht.
Wobei es mich nun doch interessiert, was
Du damit überhaupt basteln willst? Reicht
nicht entweder Perl oder PHP? Irgendwie
ist das doch von hinten durch die Brust
ins Auge, oder???
Schöner Ausdruck. Ich bin eigentlich mehr perl-orientiert. Da es um einfache DB-Zugriffe geht wollte ich einfach die PHP-DB Funktionen des Servers nutzen. Dann spare ich mir das Laden des DBI-Moduls für Perl DB-Anbindung. Der PHP-Interpreter ist ja sowieso aktiv.
cu, holli