nicht angemeldet
Hallo Martin,
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.
Natürlich falsch,aber richtig, wenn ich dem Wortlaut von Christoph folge,
Sie werden dorthin ausgegeben, worauf STDOUT verweist.
Mein reden!
Und die Standard-Handles STDIN, STDOUT, STDERR etc. "erbt" ein Prozess nunmal von dem, der ihn aufruft.
Wie ich es beschrieb oder zumindest gemeint habe!
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.
Das demonstrierte/bewies ich mit den Ausgaben des Test-Scriptes.
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. ...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.
Ok, darum habe ich nach einer anderen Prozesskommunikation gefragt die das leisten soll!
Ich stecke ja nicht in den Sourcen und kenne daher nicht wie dasder Apache macht, sondern betrachte von Außen und von den Kenntnissen welche Systemaufrufe es auf allen UNIX-Systemen gibt.
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.
Er hätte mich mißverstehen können, weil html ja auch ein HEAD-Element kennt. :-)
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.
Dafür kann ich nichts.:-)
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.
invisible steht da noch (wenn er laut der Doku die Sache Returned (zurück gibt)) :-)
Und dann kam die oben bereits erwähnte Frage nach dem, was ich bisher mit "wie auch immer" bezeichnete. Eigentlich hätte ich noch präziser Fragen können, aber Christoph hätte längst einräumen können, das ein Child-Prozess _immer_ zu seinem Parent zurückkehrt (Wait-Befehl)
Aber er wollte es ja nicht anders, denn er behauptete ja das das Environment des Test.pl gleich wäre egal ob über Shell oder Apache aufgerufen.
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.
Moment. Wie wird der Interpreter aufgerufen! (oder wird zuerst ein anderes Programm aufgerufen das den rest managed?)
Ich hatte bisher drei Möglichkeiten im Kopf:
1. Das was bei perl exec heißt - da würde sich der Apache beenden und Perl übernimmt, ohne das der Apache wieder ans Ruder kommt (scheidet aus wenn ich die Doku ernst nehme)
2. Das was man bei perl system nennt (unterscheidet sich von exec weil zuerstein fork ausgeführt wird) aber da bekommt man nur _einen_ Rückgabewert.
3. Das was man bei perl Backticks oder qx// nennt. Dabei bekommt man endlich auch den STDOUT zurück.
Also,ich kann ja nur spekulieren, wenn Apache will, das nach dem Aufruf Apache weitermachen kann, und wenn es Pfützen aufräumen ist, dann wird er nicht "Exec" nehmen und wenn der STDOUT irgend wie von Interesse ist, wird das Standardhandle vor dem perl aufruf verbogen, um die Daten zu erhalten. Selbst wenn Apache selbst nichts mit den Daten anfangen will und sie gleich weiterreicht.
Um aber auch deiner Argumentation gerecht zu werden überlege ich folgendes:
Was, wenn Apache zuerst sich selbst als Child aufruft, dann könnte der Zweite Apache über exec gehen. Doch dann würde Perl immer noch child vom ersten Apache sein. Egal wie ich es wende der Apache startet den Perl-Prozess als Child und bekommt zuerst die Daten zurück.
Es ist auch gleich gültig, ob dann für den Tranfer oder Filterung der Ausgabe wiederum Child-Prozesse gestartet werden würden, Wo soll denn da der Denkfehler sein?
Christoph versucht verzweifelt, dir die Zusammenarbeit von Apache und Perl klarzumachen, aber du scheinst das nicht zu verstehen.
Zwischen uns ist ein Medium. Wir haben nur unsere Argumente, Ob ihr mir nun Quatsch erzählt oder ich euch kann keiner genau wissen. Nur Argumente können zählen. (und Beweise)
Es wirkt auf mich so, als wärst du in deiner Vorstellung so festgefahren, dass du andere Darstellungen nicht einmal als Möglichkeit überdenkst.
0 und 1 ist nunmal 0 und 1 :-)
Das kannst du mir nicht vorwerfen. (s.o.) Du hast mit einem Zitat begonnen, wo ich mich genau auf die Worte Christoffs eingelassen habe.
Und auch in diesem Beitrag kann ich doch nur über "mein" Modell der Wirklichkeit schreiben, sonst würde ich doch nur Nachplappern. Ich bin doch nicht bekloppt, Habe in der 68030 Schiene Assembling gecodet und einige Erfahrung mit Betriebssystemen. Zwar sind Hardcoderzeiten bei mir längst vorbei, aber ein x für ein u vormachen lasse ich mir noch lange nicht. Ich will es wissen, nicht glauben. Und solange sich eine neue Information nicht einordnet in das bisherige, ist was faul dran. Also muß ich fragen und dabei mein Modell zeigen damit der andere darin die Fehler entdecken kann, wenn er recht hat und einsehen kann, wenn er unrecht hat.
Ist doch ganz einfach!
Das nervt zwar, aber wer nicht fragt bleibt dumm. :-)
Jeder spricht eine eigene Sprache und lebt in einer eigenen Welt. Das gemeinsame ist harte Arbeit.
Joe
Der Martin