Der Martin: AuthUserFile

Beitrag lesen

Hallo Joe,

#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}

Theoretisch nach deiner Auffassung müßte auf der Konsole des Rechners(stdout), wo der Apache läuft die Umgebungsvariablen des Perlscriptes ausgegeben werden.
Richtig?

falsch. Sie werden dorthin ausgegeben, worauf STDOUT verweist. Und die Standard-Handles STDIN, STDOUT, STDERR etc. "erbt" ein Prozess nunmal von dem, der ihn aufruft.
Heißt im Klartext:
Wird der Perl-Interpreter von der Shell aus aufgerufen, erbt er deren STDxxx-Handles; eine Ausgabe auf STDOUT wird daher _in der Regel_ auf der Konsole erscheinen.
Wird der Perl-Interpreter dagegen vom Apachen aufgerufen, erbt er dessen STDOUT. Und das hat der Apache schon so zurechtgebogen, dass Ausgaben an dieses Handle direkt zum anfragenden Client gehen. Gibt ein Perl-Script in *dieser* Konstellation etwas auf STDOUT aus, geht das also am Apachen vorbei direkt zum Client.

Tatsache aber ist, das die Ausgabe letzten Endes im Browserfenster des Client-Rechners dargestellt wird.

Eben.

Das kann eigentlich nur passieren, wenn das Programm, das den Interpreter aufruft den Standard output "abfängt" und an den Client-Rechner überträgt wie auch immer.

Nein. Wenn Kollege A mich anruft und sagt, er bräuchte die Unterlagen über Projekt xyz, die ich aber selbst nicht habe, dann kann ich mir diese Unterlagen vom Kollegen B holen und eigenhändig an den Kollegen A durchreichen. Das ist deine Denkweise. Ich kann aber auch B Bescheid geben und ihn bitten, die Sachen gleich dem Kollegen A zu geben. Dann hab ich nichts mehr damit zu tun und sehe auch nicht, was die beiden *wirklich* untereinander austauschen.

Anscheinend besteht hier wieder so ein sprachliches Mißverständniss, Denn du überließt anscheinend glatt den Header, gut ich habe nicht HTTP-Header oder wie das Ding heißt geschrieben...

Aber hoffentlich *gemeint*. Ich wüsste nicht, was du sonst für einen Header meinen könntest. Und den braucht ja auch nicht der Apache, sondern der anfragende Client.

For example, if the URL http://www.example.com/cgi-bin/test.pl  is requested, Apache will attempt to execute the file /usr/local/apache2/cgi-bin/test.pl  and return the output.
Ich kann zwar nicht gut Englisch, aber steht da nicht "Apache....and return the Output"?

Ja, aber das ist sehr salopp formuliert und technisch nicht ganz korrekt.

Also bitte wo du doch wie lese sovielprobiert hast, Wie anders kommt der Apache an die Daten des Outputs des Perscriptes ran in obigen Beispiel?

Gar nicht. Das interessiert ihn nicht.

Mit anderen Worten welche Art der Interprozess-Kommunikation kann verwendet werden, wenn Perl kein Child von Apache ist und auch nicht integriert ist.

Der Perl-Interpreter *ist* ein Child-Prozess des Apachen, wenn er in dessen Kontext als CGI aufgerufen wird. Die Kommunikation der beiden beschränkt sich aber darauf, dass der Indianer aufpasst, wann Perl beendet ist, und dann die verbleibenden Pfützen des Requests aufwischt.

Du raubst mir _deine_ Zeit!!!

Christoph versucht verzweifelt, dir die Zusammenarbeit von Apache und Perl klarzumachen, aber du scheinst das nicht zu verstehen. Es wirkt auf mich so, als wärst du in deiner Vorstellung so festgefahren, dass du andere Darstellungen nicht einmal als Möglichkeit überdenkst.

So long & good night,
 Martin

--
Denken ist wohl die schwerste Arbeit, die es gibt. Deshalb beschäftigen sich auch nur wenige damit.
  (Henry Ford, amerikanischer Industriepionier)