CGI ohne Perl-Interpreter

[Norbert]

gibt es eine Möglichkeit ein CGI-Script zu schreiben und aufzurufen, welches direkt im apache übersetzt wird und nicht mit den normalen perl-interpreter?

mfg

Norbert

[Struppi]

gibt es eine Möglichkeit ein CGI-Script zu schreiben und aufzurufen, welches direkt im apache übersetzt wird und nicht mit den normalen perl-interpreter?

Ja, du musst nur eine auf dem Betriebsystem funktionierende Anwendung schreiben, die von STDION liest und auf STDOUT schreibt.

Struppi.

[Michael Schröpl]

Hi Norbert,

gibt es eine Möglichkeit ein CGI-Script zu schreiben und aufzurufen,
welches direkt im apache übersetzt wird und nicht mit den normalen perl-interpreter?

Du vermengst da ein paar Dinge und scheinst Dir über bestimmte Vorgänge nicht wirklich im Klaren zu sein.

CGI ist eine Schnittstelle, keine Sprache. Du kannst in diversen Sprachen CGI-Anwendungen schreiben; diese Anwendungen vom Apache aktivieren zu lassen ist eine Frage der CGI-Konfiguration sowohl des Apache als auch ggf. der Anwendung selbst ("#!"-Zeile im Perl-Skript etc.).

Der Apache "übersetzt" aber keine CGI-Anwendung. Dafür wäre der Übersetzer der jeweiligen Sprache zuständig. Was dieser Übersetzer genau kann, hängt wiederum sowohl von der Sprache als auch vom konkret verwendeten Übersetzer ab.

Bei Perl macht es wenig Sinn, etwas anderes als einen Interpreter anzubieten (wegen "eval" etc.), deshalb wird die Übersetzung des Programms normalerweise bei jedem Aufruf erfolgen (es gibt aber auch da wieder Variationsmöglichkeiten). Dasselbe gilt für andere Interpretersprachen, die ihre eigenen Interpreter mitbringen (PHP oder UNIX-Shell, um nur zwei Beispiele zu nennen).

Bei vielen anderen Sprachen, beispielsweise C oder PASCAL, ist dagegen die Übersetzung sehr wohl zu einem beliebigen Zeitpunkt einmalig möglich. Das fertig übersetzte (und gebundene) ausführbare Programm kann danach über die CGI-Schnittstelle vom Apache direkt ausgeführt werden (ohne daß nun noch ein Interpreter erforderlich wäre).
Diese Methode ist meistens performanter, aber dafür weniger komfortabel in der Behandlung durch den Programmierer, der das Programm immer wieder neu übersetzen und binden lassen muß, wenn er etwas darin geändert hat. Und zudem ist das Übersetzungsergebnis normalerweise plattformabhängig.

Reicht das, oder möchtest Du Deine Frage anders formulieren?

Viele Grüße
      Michael

[Christian Kruse]

Hallo Michael,

Bei Perl macht es wenig Sinn, etwas anderes als einen
Interpreter anzubieten (wegen "eval" etc.), deshalb wird
die Übersetzung des Programms normalerweise bei jedem
Aufruf erfolgen (es gibt aber auch da wieder
Variationsmöglichkeiten). Dasselbe gilt für andere
Interpretersprachen, die ihre eigenen Interpreter
mitbringen (PHP oder UNIX-Shell, um nur zwei Beispiele zu
nennen).

Korrekt. Was man aber durchaus machen kann, ist, nur eine
Instanz des Interpreters (pro Apache-Child) laufen zu lassen.
Und genau das machen z. B. mod_perl und mod_php.

Bei vielen anderen Sprachen, beispielsweise C oder PASCAL,
ist dagegen die Übersetzung sehr wohl zu einem beliebigen
Zeitpunkt einmalig möglich.

Siehe dieses Forum :)

Gruesse,
 CK

[Michael Schröpl]

Hi Christian,

Bei Perl macht es wenig Sinn, etwas anderes als einen
Interpreter anzubieten (wegen "eval" etc.), deshalb wird
die Übersetzung des Programms normalerweise bei jedem
Aufruf erfolgen (es gibt aber auch da wieder
Variationsmöglichkeiten).
Korrekt. Was man aber durchaus machen kann, ist, nur eine
Instanz des Interpreters (pro Apache-Child) laufen zu lassen.
Und genau das machen z. B. mod_perl und mod_php.

dafür habe ich das "normalerweise" und die "Variationsmöglichkeiten" spendiert. ;-)

Ob dann die Skripte ggf. sogar in kompilierter Form im Modul gespeichert werden können, weiß ich beispielsweise auch nicht.

Viele Grüße
      Michael

[Christian Kruse]

Hallo Michael,

Ob dann die Skripte ggf. sogar in kompilierter Form im Modul
gespeichert werden können, weiß ich beispielsweise auch
nicht.

Bei mod_php werden sie jedesmal neu geparsed. Bei Perl liegen
sie in Form von optimierten Syntax-Baeumen vor.

Gruesse,
 CK