nicht angemeldet
Perl, Tcl,
Hallo,
Enschuldigung, dass ich die gleiche nochmal schreibe, aber ich hab meine eigentliche Frage in dem ersten Beitrag vergessen. Also hier nochmal:
Ich habe habe Apache 1.3.20 auf meinen Windows 9x- Sytem (Windows ME)
installiert nun möchte ich Perl 5.x und Tcl 8.x auf meinen lokalen Server bzw. System intallieren. Den Apache- Server betreibe natürlich nur als Testserver. Wie mache ich das. Wo gibt es eine Anleitung am besten auf Deutsch (Englisch ginge aber auch)? Bei www.activestate.com blicke ich nicht ganz durch.
Danke,
MFG
Christopher Morris
-
Hallo,
Enschuldigung, dass ich die gleiche nochmal schreibe, aber ich hab meine eigentliche Frage in dem ersten Beitrag vergessen.
Es spricht nichts dagegen, im ersten Thread nochmals zu posten. Bedenke, daß in diesem Forum alle Postings archiviert werden. Wenn Du Deine zusätzlichen Fragen im Ausgangsthread postest, dann wird es für Andere, die dann diesen Thread im Archiv lesen, leichter, die Zusammenhänge zu erkennen.
Vielleicht wirfst Du einmal einen Blick in die FAQ's.
Ich habe habe Apache 1.3.20 auf meinen Windows 9x- Sytem (Windows ME)
Auch wenn es sich um ein Testsystem handelt, solltest Du mind VErsion 1.3.26 verwenden. bei den älteren Versionen hat es ein Sicherheitsloch gegeben.
installiert nun möchte ich Perl 5.x und Tcl 8.x auf meinen lokalen Server bzw. System intallieren. Den Apache- Server betreibe natürlich nur als Testserver. Wie mache ich das. Wo gibt es eine Anleitung am besten auf Deutsch (Englisch ginge aber auch)? Bei www.activestate.com blicke ich nicht ganz durch.
Die Software (Perl und TCL) für Windows findest Du bei Activestate. Normalerweise sollte es kein Problem sein, Perl und TCL auf Deinem Rechner zu installieren, sofern Du den Windows Installer schon auf Deinem Rechner hast. Wenn nicht, dann findest Du auf der genannten Website einen Link zu einer Downloadmöglichkeit.
Wie Du Perl und einen Webserver zusammenarbeiten lassen kannst, findest Du beispielsweise unter http://selfhtml.teamone.de/cgiperl/intro/index.htm.
Aber auch die Dokumentation von ActivePerl (wird standardmäßig mit installiert) enthält u.a. eine ausführliche Beschreibung, wie man den Webserver dazu bewegt, CGI-Scripts auszuführen (Stichwort: Webserver Config).
TCL kenne ich nicht wirklich, allerdings nehme ich an, daß sich die Inbetriebnahme eines TCL-Scripst analog zu Perl vornehmen läßt. Wenn der Scriptalias gesetzt ist (und das ist er normalerweise), dann brauchst Du in den TCL-Scripts nur mehr
#!c:\wirklicher\pfad\zu\tclsh
in der ersten Zeile eintragen und schon gehts los.Grüße
Klaus-
hi Klaus ;-)
TCL kenne ich nicht wirklich
aber ich kenne es inzwischen ganz gut und bin in manchen Tagen regelrecht versessen darauf, in meine TLC-Scripts Ordnung hineinzubringen
allerdings nehme ich an, daß sich die Inbetriebnahme eines TCL-Scripst analog zu Perl vornehmen läßt. Wenn der Scriptalias gesetzt ist (und das ist er normalerweise), dann brauchst Du in den TCL-Scripts nur mehr
#!c:\wirklicher\pfad\zu\tclsh
in der ersten Zeile eintragen und schon gehts los.NEIN.
Bei PERL stimmt das so, weil PERL eben diese CGI-Funktionalität hat. TCL hat diese Funktionalität (bisher) nicht und kann sie eigentlich vom Konzept her auch nicht erwerben. Man kann mit TCL/Tk ganze Webserver konfigurieren und "schreiben" (was man mit PERL nicht im gleichen Maß kann), aber keine cgi-Scripts. Dennoch haben beide Sprachen Gemeinsamkeiten: sie kommen beide aus der UNIX-Welt der Shell-Scripts und möchten gerne eine shebang haben.
Die Ursprünge von TCL liegen übrigens bei einem seit Jahren nicht mehr weiterentwickelten Konzept, das man sich unter http://www.cs.berkeley.edu/projects/sprite/sprite.html immer noch anschauen kann.Bisweilen (hier im Forum sehr selten angesprochen) gibt es etwas Verwirrung, weil es für PERL ja ein sehr reizvolles Tk-Modul gibt. Leider steht in der Doku zu diesem Modul nirgends, daß es übers "Netz" - und damit auch über den Apache - nicht verteilbar und ausführbar ist. Und um die Verwirrung noch weiterzutreiben: bei apache.org gibts unter http://tcl.apache.org/ seit geraumer Zeit ein hochinteressantes TCL-Projekt. Bloß hat selbst dieses Teil nix mit cgi zu tun. Man kann mit TCL/Tk ganze Webserver "schreiben", siehe http://dev.scriptics.com/software/tclhttpd/, man kann mit Hilfe von TCL/Tk Webseiten in einem TCL-Programm öffnen (geht immer noch nicht ganz fehlerfrei), man kann sogar aus TCL-Code in *.tml-Dateien Webseiten erstellen - aber man kann (bisher) TCL-Scripts nicht für cgi-Aufgaben einsetzen.
Und auch das, was man mit dem inzwischen ziemlich weit ausgereiften PERL/Tk-Modul anstellen kann, ist zwar sehr ansehenswert, transportiert aber noch immer nix an einen Rechner, auf dem nicht selbst PERL und/oder TCL installiert ist.
Kurz: TCL/Tk-Scripts werden von einem Interpreter gelesen und befolgt, der auf dem "ausführenden" Rechenr installiert sein muß, ob das ein Server-Rechner oder ein Client-Rechner ist, ist egal.grüßchens ;-)
Christoph S.
-
Hallo,
TCL kenne ich nicht wirklich
aber ich kenne es inzwischen ganz gut und bin in manchen Tagen regelrecht versessen darauf, in meine TLC-Scripts Ordnung hineinzubringenDamit wird tatsächlich noch produktiv gearbeitet?
Aber gut, das letzte Mal mußte es so portabel wie möglich sein und so ging nur Version 7.4. Und darin einen Parser bauen, ich sag Dir ... ;-)Seit 8.x geht's ja einigermaßen.
Aber Tk ist wirklich gut, insbesondere die Kombination mit Perl als "Maschine".
Das führt mich dann auch endlich zu meiner Frage:Und auch das, was man mit dem inzwischen ziemlich weit ausgereiften PERL/Tk-Modul anstellen kann, ist zwar sehr ansehenswert, transportiert aber noch immer nix an einen Rechner, auf dem nicht selbst PERL und/oder TCL installiert ist.
Das wundert mich doch arg. Ist evt bekannt woran es genau liegt?
Au, jetzt habe ich zu sehr gekürzt, sorry.
Das Tk auf dem Client nicht funktioniert, wenn kein Interpreter installiert ist, ist schon klar, aber TCL will auch nicht als CGI werkeln?Normalerweise könnte man die Funktion ja einbauen, aber IMHO ist die Lizenz von TCL dazu nicht geeignet, oder?
Kurz: TCL/Tk-Scripts werden von einem Interpreter gelesen und befolgt, der auf dem "ausführenden" Rechenr installiert sein muß, ob das ein Server-Rechner oder ein Client-Rechner ist, ist egal.
Es scheint das die alten Linux (Unix allgemein?) Netscape Versionen (über die Neuen kann ich nichts sagen, hier sitzt nur ein 4.51 in einem chroot Knast um mich bei den CSS Workarounds für die NN 4er regelmäßig zur Verzweiflung zu treiben ;-) per Default ein TCL und ein Tk Interpreter als Plugin installiert wurden. Es existieren somit zumindest Plugins für Netscape. Ob die weiterentwickelt wurden bzw werden und auch für andere Browser/OS zur Verfügung stehen, kann ich leider nichts sagen.
Ist für's Internet wohl kaum zu gebrauchen, aber für's Intranet könnte ich mir mancherlei Anwendung vorstellen.
so short
Christoph Zurnieden
-
hi,
Das Tk auf dem Client nicht funktioniert, wenn kein Interpreter installiert ist, ist schon klar, aber TCL will auch nicht als CGI werkeln?
Nein. Ist mir zumindest nicht bekannt (jedenfalls nicht ohne installierten Interpreter)
Normalerweise könnte man die Funktion ja einbauen, aber IMHO ist die Lizenz von TCL dazu nicht geeignet, oder?
Das hängt nicht an der "Lizenz", sondern an der Gesamtstruktur der Bibliotheken, so weit ich das einschätzen kann.
Es existieren somit zumindest Plugins für Netscape.
Auch für den IE - aber nur bis 5.5. Die NASA hatte das am weitesten entwickelt: http://heasarc.gsfc.nasa.gov/Tools/maki/plugin/ hat aber die Weiterarbeit inzwischen aus irgendwelchen Gründen aufgegeben.
Ist für's Internet wohl kaum zu gebrauchen, aber für's Intranet könnte ich mir mancherlei Anwendung vorstellen.
hm, kann ich mir auch vorstellen ;-)
Grüße
Christoph S.
-
Hallo,
Das Tk auf dem Client nicht funktioniert, wenn kein Interpreter installiert ist, ist schon klar, aber TCL will auch nicht als CGI werkeln?
Nein. Ist mir zumindest nicht bekannt (jedenfalls nicht ohne installierten Interpreter)Da der Kollege Klaus Mock da etwas präziser war, möchte ich da auch nicht nachstehen. (Das Paket ncgi ist im Paket tcllibs. Aktuell scheint 1.3.0 zu sein: http://belnet.dl.sourceforge.net/sourceforge/tcllib/tcllib-1.3.tar.gz (1113 kb) braucht mindestens TCL 8.2.
So wie es aussieht, ist sonst nichts nötig. Es wird zumindest nichts anderes eingebunden.
Da die Lizenz es zuläßt, könnte ich es Dir gesondert schicken. (Als tar.bz2 wären es rund 19kb + base64)
So wie es aussieht, ist es genau das, was Du bräuchtest. Ist allerdings nur auf stdin ausgerichtet, stdout müßtest Du dann selber zusammenbauen (Header usw)mod_tcl http://tcl.apache.org/mod_tcl/mod_tcl.html
und
mod_dtcl http://tcl.apache.org/mod_dtcl/dürften Dich da auch interessieren.
Normalerweise könnte man die Funktion ja einbauen, aber IMHO ist die Lizenz von TCL dazu nicht geeignet, oder?
Das hängt nicht an der "Lizenz", sondern an der Gesamtstruktur der Bibliotheken, so weit ich das einschätzen kann.Es gibt nichts, was man nicht ändern könnte ;-)
Die Lizenz ist meist das Hindernis. (Der wichtigste Grund, warum ich PHP4 nicht benutze. Ich kann da nicht so ohne weiteres und legal etwas ändern. Aber PHP3 wird ja auch noch weiterentwickelt ;-)Es existieren somit zumindest Plugins für Netscape.
Auch für den IE - aber nur bis 5.5. Die NASA hatte das am weitesten entwickelt: http://heasarc.gsfc.nasa.gov/Tools/maki/plugin/Oh, interessant, den kannte ich noch gar nicht.
hat aber die Weiterarbeit inzwischen aus irgendwelchen Gründen aufgegeben.
Es liegt wahrscheinlich, wie so oft, am liebem Geld *sigh*
Ist für's Internet wohl kaum zu gebrauchen, aber für's Intranet könnte ich mir mancherlei Anwendung vorstellen.
hm, kann ich mir auch vorstellen ;-)Die Rechner sind ja jetzt auch schnell genug. (Wenn ich mir vorstelle, was ich mir da abgebrochen habe, nur weil switch() erst kürzlich richtig eingebaut wurde und ich wg Kompatibilität nur 7.4 nehmen konnte. Und in einem Parser kommt sowas hin und wieder schon mal vor ;-)
so short
Christoph Zurnieden
-
hi,
Da der Kollege Klaus Mock da etwas präziser war, möchte ich da auch nicht nachstehen. (Das Paket ncgi ist im Paket tcllibs. Aktuell scheint 1.3.0 zu sein: http://belnet.dl.sourceforge.net/sourceforge/tcllib/tcllib-1.3.tar.gz (1113 kb) braucht mindestens TCL 8.2.
Danke. Richtig, Klaus Mock ist ziemlich genau gewesen, ich versuch da auch noch eine Erwiderung, weil ich mich zwar korrekt, aber offenbar nicht präzise genug geäußert hatte.
Richtig im Zusammenhang "CGI und TCL" ist folgendes: Wenn der Server über die CGI-Schnittstelle irgendeinen Datenstrom an den Client schickt, muß auf Client-Seite "etwas" vorhanden sein, was diese Schnittstelle überhaupt versteht und den Datenstrom in eine menschenlesbare Darstellung umwandelt. _Das_ kann TCL (auch ohne Tk, bloß mit Tk siehts besser aus), vorausgesetzt, es ist auf dem Client installiert. Dazu ist nicht einmal die tcllib (die ich auf allen meinen Systemen zur Verfügung habe, danke für dein Angebot, sie zu schicken) zwingend nötig, man könnte sich mit etwas Arbeit eine entsprechende Bibliothek selber zusammenschrauben. Wie das prinzipiell geht, steht in "Practical Programming in Tcl and Tk" von Brent Welch (siehe http://www.beedub.com/book/), das ich auch in gedruckter Form habe. Und es gibt noch einige weitere auch online verfügbare manuals, siehe http://resource.tcl.tk/resource/doc/books/.
Alle diese klugen und teils sehr ausführlichen Darstellungen betreffen aber lediglich die "Auflösung" eines über CGI vermittelten Datenstroms auf einem Rechner, auf dem TCL installiert ist.
Bei der "CGI-Funktionalität" von PERL gibt es einen entscheidenden Unterschied: du kannst von Clientseite aus über ein CGI-Script den _Server_ veranlassen, die Scriptbefehle an den auf dem Server-Rechner installierten Interpreter weiterzureichen - der Apache macht das unter anderem, indem er die "script-alias"-Angaben befolgt. Der Client _braucht dazu nicht_ PERLL installiert zu haben. Der Interpreter auf dem Server-Rechner macht das, was im Script steht, und liefert das Ergebnis beispielsweise als generierten HTML-Code an den Server zurück, der das dann brav an den Client weiterreicht. Der Client braucht dazu bei PERL keinen installierten Interpreter. Und _dieser_ Mechanismus funktioniert nach meinen bisherigen Kenntnissen mit TCL nicht. Jedenfalls nicht _ohne installierten TCL-Interpreter_. Ist TCL sowohl auf dem Server wie auf dem Client installiert, geht es. Meine Frage, mein Problem, mein Hinweis (wie auch immer du es nennen möchtest) bezog sich einzig darauf, daß bei PERL die "CGI-Funktionalität" auch dann in vollem Umfang erreicht werden kann, wen _nur_ der Server-Rechner, aber _nicht_ der Clíent-Rechner über eine voll funktionsfähige und per %PATH% ansprechbare Installation verfügt. Willst du dieselbe "CGI-Funktionalität" mit TCL erreichen, muß auf beiden Rechnern (wenn denn Client und Server zwei physikalisch unterschiedliche Rechner sind) TCL installiert sein, und leider auch noch in der dem Script entsprechenden Version.
<schüchterne Anfrage>
hab ich mein "Problem" jetzt genauer beschrieben?
</schüchterne Anfrage>mod_tcl http://tcl.apache.org/mod_tcl/mod_tcl.html und
mod_dtcl http://tcl.apache.org/mod_dtcl/ dürften Dich da auch interessieren.Ja. Tun sie. Hab ich zwar auch schon mehrfach draufgekuckt, aber möglicherweise noch nicht in Gänze kapiert. Ziel der beiden Module ist (wenn ich sie richtig verstanden habe), für TCL-Scripts die Möglichkeit zu eröffnen, daß als "embedded Code" vermittelt werden können - ähnlich wie das mit dem interessanten Projekt EMBPERL auch für PERL-Code versucht wird. Aber _gerade_ diese Module setzen selbstverständlich voraus, daß der (Client-)Rechner, der solche HTML-Dokumente mit eingebettetem TCL entgegennimmt, die Interpretation des TCL-Codes an einen TCL-Interpreter weiterreichen kann. Damit hätten wir uns im Kreis gedreht.
Es gibt nichts, was man nicht ändern könnte ;-)
da stimme ich dir gerne zu, prinzipiell.
Vielleicht hab ich ja bisher immer nur nen Komma oder nen Semikolon übersehen, ist ja alles mit weitreichenden Folgen möglich.
Grüße aus Berlin
Christoph S.
-
Hallo,
Da der Kollege Klaus Mock da etwas präziser war, möchte ich da auch nicht nachstehen. (Das Paket ncgi ist im Paket tcllibs. Aktuell scheint 1.3.0 zu sein: http://belnet.dl.sourceforge.net/sourceforge/tcllib/tcllib-1.3.tar.gz (1113 kb) braucht mindestens TCL 8.2.
Danke. Richtig, Klaus Mock ist ziemlich genau gewesen, ich versuch da auch noch eine Erwiderung, weil ich mich zwar korrekt, aber offenbar nicht präzise genug geäußert hatte.Richtig im Zusammenhang "CGI und TCL" ist folgendes: Wenn der Server über die CGI-Schnittstelle irgendeinen Datenstrom an den Client schickt, muß auf Client-Seite "etwas" vorhanden sein, was diese Schnittstelle überhaupt versteht und den Datenstrom in eine menschenlesbare Darstellung umwandelt.
Achso, Du meinst den Direktkontakt. Wir waren bei HTTP.
Das ändert natürlich so einiges._Das_ kann TCL (auch ohne Tk, bloß mit Tk siehts besser aus), vorausgesetzt, es ist auf dem Client installiert. Dazu ist nicht einmal die tcllib (die ich auf allen meinen Systemen zur Verfügung habe, danke für dein Angebot, sie zu schicken) zwingend nötig, man könnte sich mit etwas Arbeit eine entsprechende Bibliothek selber zusammenschrauben.
"Etwas Arbeit" ist gut, das ist 'ne Menge. Ich weiß das, denn ich mußte das machen, da ich aus Abwärtskompatibilitätszwängen die Lib leider nicht benutzen konnte. Brauchte zwar nur einen geringen Teil, aaber das hat schon gereicht ;-)
Wie das prinzipiell geht, steht in "Practical Programming in Tcl and Tk" von Brent Welch (siehe http://www.beedub.com/book/),
Und das erfahr ich jetzt erst?
Alles Schweine, alles! ;-)das ich auch in gedruckter Form habe. Und es gibt noch einige weitere auch online verfügbare manuals, siehe http://resource.tcl.tk/resource/doc/books/.
Oh, da hat sich ja doch einiges getan.
Alle diese klugen und teils sehr ausführlichen Darstellungen betreffen aber lediglich die "Auflösung" eines über CGI vermittelten Datenstroms auf einem Rechner, auf dem TCL installiert ist.
Ja, denn es ging ja nur darum. In diesem Beispiel um TCL Scripte als CGI in Zusammenarbeit mit einem Apacheserver. Alles auf dem Server.
Oder habe ich da etwas mißverstanden?Bei der "CGI-Funktionalität" von PERL gibt es einen entscheidenden Unterschied: du kannst von Clientseite aus über ein CGI-Script den _Server_ veranlassen, die Scriptbefehle an den auf dem Server-Rechner installierten Interpreter weiterzureichen - der Apache macht das unter anderem, indem er die "script-alias"-Angaben befolgt. Der Client _braucht dazu nicht_ PERLL installiert zu haben. Der Interpreter auf dem Server-Rechner macht das, was im Script steht, und liefert das Ergebnis beispielsweise als generierten HTML-Code an den Server zurück, der das dann brav an den Client weiterreicht. Der Client braucht dazu bei PERL keinen installierten Interpreter. Und _dieser_ Mechanismus funktioniert nach meinen bisherigen Kenntnissen mit TCL nicht. Jedenfalls nicht _ohne installierten TCL-Interpreter_. Ist TCL sowohl auf dem Server wie auf dem Client installiert, geht es.
Das verwirrt mich jetzt völlig. Das Packet ncgi scheint doch genau das anzubieten?
Meine Frage, mein Problem, mein Hinweis (wie auch immer du es nennen möchtest) bezog sich einzig darauf, daß bei PERL die "CGI-Funktionalität" auch dann in vollem Umfang erreicht werden kann, wen _nur_ der Server-Rechner, aber _nicht_ der Clíent-Rechner über eine voll funktionsfähige und per %PATH% ansprechbare Installation verfügt. Willst du dieselbe "CGI-Funktionalität" mit TCL erreichen, muß auf beiden Rechnern (wenn denn Client und Server zwei physikalisch unterschiedliche Rechner sind) TCL installiert sein, und leider auch noch in der dem Script entsprechenden Version.
<schüchterne Anfrage>
hab ich mein "Problem" jetzt genauer beschrieben?
</schüchterne Anfrage>Nein, es ist eher schlimmer geworden.
Bitte um kurzes Beispiel(script)BTW: in diesem Forum sollte kein schlechtes XML vorkommen:
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<!DOCTYPE Anfrage [
<!ENTITY quot """ >
<!ELEMENT Anfrage (#PCDATA) >
<!ATTLIST Anfrage
atype (shy|normal|bugging) "normal" >
]>
<Anfrage atype="shy">
hab ich mein "Problem" jetzt genauer beschrieben?
</Anfrage>bash-2.02$ xmllint --noout --postvalid Anfrage.xml
bash-2.02$Aaaah, schon besser! ;-)
mod_tcl http://tcl.apache.org/mod_tcl/mod_tcl.html und
mod_dtcl http://tcl.apache.org/mod_dtcl/ dürften Dich da auch interessieren.
Ja. Tun sie. Hab ich zwar auch schon mehrfach draufgekuckt, aber möglicherweise noch nicht in Gänze kapiert. Ziel der beiden Module ist (wenn ich sie richtig verstanden habe), für TCL-Scripts die Möglichkeit zu eröffnen, daß als "embedded Code" vermittelt werden können - ähnlich wie das mit dem interessanten Projekt EMBPERL auch für PERL-Code versucht wird. Aber _gerade_ diese Module setzen selbstverständlich voraus, daß der (Client-)Rechner, der solche HTML-Dokumente mit eingebettetem TCL entgegennimmt, die Interpretation des TCL-Codes an einen TCL-Interpreter weiterreichen kann. Damit hätten wir uns im Kreis gedreht.Nein, das scheint mir doch eher wie PHP u.ä. vom Server ausgeführt zu werden.
Aber das müßte einfach mal ausgetestet werden. Sich durch die Quellen zu wühlen scheint mir müßig.Es gibt nichts, was man nicht ändern könnte ;-)
da stimme ich dir gerne zu, prinzipiell.Vielleicht hab ich ja bisher immer nur nen Komma oder nen Semikolon übersehen, ist ja alles mit weitreichenden Folgen möglich.
TCL ist eigentlich recht strikt, was die Form angeht. Würde ich also fast schon ausschließen wollen.
so short
Christoph Zurnieden
-
Hallo,
Ich hänge mich einfach hier an, und beantworte auch einige Sachen aus dem anderen Teilthread.
------------------------------------------
Was ist 'diese CGI-Funktionalität'? Meines Erachtens nur die Fähigkeiten auf STDIN,STDOUT und Environment zugreifen zu können. Und diese Fähigkeiten wird TCL sicherlich auch haben.
Hat es, und STDERR hast du jetzt nicht aufgezählt (weil das auf WINDOWS nicht existiert?)STDERR habe ich ausgelassen, da er für die CGI-Funktionalität nicht unbedingt notwendig ist.
hihi ;-) das geht auf einem Windows-Rechner noch um eine Zeile kürzer:
button .hallo -text hallo \ -command {puts stdout "hallo welt!"}
pack .hallo -padx 20 -pady 10Aber dann sind wir wieder bei TK und das wollen wir ja nicht, da es für CGI-Scripts ungeeignet ist.
------------------------------------------
Richtig im Zusammenhang "CGI und TCL" ist folgendes: Wenn der Server über die CGI-Schnittstelle irgendeinen Datenstrom an den Client schickt, muß auf Client-Seite "etwas" vorhanden sein, was diese Schnittstelle überhaupt versteht und den Datenstrom in eine menschenlesbare Darstellung umwandelt.
Die Schnittstelle zum Client heißt HTTP. Das einzige, was am Client laufen sollte, ist ein User-Agent, der HTTP versteht. Nichts anderes ist (vorerst) zusätzlich notwendig.[1]
CGI ist dem HTTP-Request nachgeschaltet und hat mit der eigentlichen HTTP-Anfrage nichts zu tun. Der HTTP-Client 'weiß' ja nicht einmal, _wie_ der Server seinen Request abarbeitet und ob er CGI überhaupt einsetzt.
Somit ist es die Sache des Webserveres, ob und wie er eine CGI-Anwendung startet. CGI ist eben nur ein Schnittstellenprotokoll zwischen Webserver und einer auf dem Server laufenden Anwendung.Was muß den eine CGI-Anwendung können?
Sie muß aufgrund einer Environment-Variable entscheiden, ob die allfälligen CGI-Parameter aus dem Environment oder von STDIN gelesen werden sollen (GET oder POST).[2]
Sie muß in der Lage sein, diese Parameter analysieren zu können.
Sie muß in der Lage sein, aufgrund der internen Programmlogik, Informationen dem HTTP-Protokoll entsprechend per STDOUT ausgeben zu können. Dabei können die ermittlten Parameter zu Hilfe genommen werden, um die internen Abläufe zu steuern.
Und dafür kannst Du jede Sprache verwenden, so lange sie nur die von mir genannten Mindestvoraussetzungen erfüllt.
Das alles muß sie nur auf dem Server können.[3] Der HTTP-Client wird von all dem nichts mit bekommen.
TCL (ohne TK) ist also durchaus geeignet, für CGI-Anwendungen benutzt zu werden.
Und wenn TCL Netzwerkfähigkeiten hat, die es ermöglichen, verteilte Anwendungen zu schreiben, so ist das auch gut, genauso wie es schön ist, wenn man, unter Zuhilfenahme der TK-Erweiterungen, daß man damit auch GUI-Programme schrieben kann.Nur ist beides für das aktuelle Problem nicht von Belang.
Grüße
Klaus[1] Wenn die Daten, die dann per HTTP übertragen worden sind, dann auch noch interpretiert werden sollen, dann ist clientseitig natürlich zusätzliche Logik notwendig, un dies zu erledigen. Das hängt aber wiederum von der Art der Daten ab. In vielen Fällen wird es aber HTML sein, was ein halbwegs brauchbarer Browser ohne Fremdhilfe erledigen kann. Aber auch das ist IMHO nicht das Thema
[2] Wobei anzumerken ist, daß es auch durchaus andereArten von Requests gibt, welche eventuell andere Handlungsweisen bedingen.
-
Wenn schon durcheinander, dann richtig ;-)
Aber erstmal: Hallo,
Was ist 'diese CGI-Funktionalität'? Meines Erachtens nur die Fähigkeiten auf STDIN,STDOUT und Environment zugreifen zu können. Und diese Fähigkeiten wird TCL sicherlich auch haben.
Hat es, und STDERR hast du jetzt nicht aufgezählt (weil das auf WINDOWS nicht existiert?)Existiert auch auf Windows. Muß schon alleine deshalb, weil es einen guten Teil der Grundfunktionalität von MS-Produkten umfaßt.
(kann nie wiederstehen, wenn ich gutgelaunt bin ;-)STDERR habe ich ausgelassen, da er für die CGI-Funktionalität nicht unbedingt notwendig ist.
STDERR ist manchmal die einzige Möglichkeit, etwas über den Zustand des Servers zu erfahren, so wie manche, für teures Geld angemietete Accounts, eingeschränkt sind. (Es grenzt ja schon mitunter an Betrug, was da abgeht: auf der einen Seite offen wie ein Scheunentor, auf der anderen Seite wird der User ohne Ende und vor allem Sinn und Verstand beschnitten. Wie in einem Posting weiter oben schön gezeigt, wo 1&1 einen Kunden, der seinen Transfer komplett bezahlt, nichts umsonst wollte, recht willkürlich rausschmeißt.)
hihi ;-) das geht auf einem Windows-Rechner noch um eine Zeile kürzer:
button .hallo -text hallo \ -command {puts stdout "hallo welt!"}
pack .hallo -padx 20 -pady 10Aber dann sind wir wieder bei TK und das wollen wir ja nicht, da es für CGI-Scripts ungeeignet ist.
Na, ungeeignet nicht unbedingt, da sich die Darstellung der Elemente unterdrücken läßt. Ich selber habe schon mal eine Textfeld mißbraucht, da bei Tk der Inhalt eines solchen in einem Binary Tree gespeichert wird und deshalb sehr gut durchsuchbar ist. Aber gut, das war nicht für eine CGI-Anwendung und fällt auch eher unter die Rubrik "kreativer Umgang mit Technik" ;-)
Richtig im Zusammenhang "CGI und TCL" ist folgendes: Wenn der Server über die CGI-Schnittstelle irgendeinen Datenstrom an den Client schickt, muß auf Client-Seite "etwas" vorhanden sein, was diese Schnittstelle überhaupt versteht und den Datenstrom in eine menschenlesbare Darstellung umwandelt.
Die Schnittstelle zum Client heißt HTTP. Das einzige, was am Client laufen sollte, ist ein User-Agent, der HTTP versteht. Nichts anderes ist (vorerst) zusätzlich notwendig.[1]
Aha, mal schauen, ob er Dir glaubt ;-)
CGI ist dem HTTP-Request nachgeschaltet und hat mit der eigentlichen HTTP-Anfrage nichts zu tun. Der HTTP-Client 'weiß' ja nicht einmal, _wie_ der Server seinen Request abarbeitet und ob er CGI überhaupt einsetzt.
Geht ihn ja auch schließlich gaaar nix an! ;-)
Somit ist es die Sache des Webserveres, ob und wie er eine CGI-Anwendung startet. CGI ist eben nur ein Schnittstellenprotokoll zwischen Webserver und einer auf dem Server laufenden Anwendung.
Ach, noch viel weniger. Das ist eigentlich nur eine Lib in der die gängigsten Methoden versammelt sind, die man sonst alle mühsam selber coden müßte.
Die Schnittstelle hat eigentlich gar kein Protokoll, da sie nur die Dateien STDIN, STDOUT und STDERR scharf schaltet und ein paar Environment Variablen belegt, auf das die Daten mit Begründung da durchpfeifen können.
"Ceci n'est pas un pipe"
Ja, ich weiß, 2 EUR in die Wortwitzkasse ;-)TCL (ohne TK) ist also durchaus geeignet, für CGI-Anwendungen benutzt zu werden.
Und wenn TCL Netzwerkfähigkeiten hat, die es ermöglichen, verteilte Anwendungen zu schreiben, so ist das auch gut, genauso wie es schön ist, wenn man, unter Zuhilfenahme der TK-Erweiterungen, daß man damit auch GUI-Programme schrieben kann.War das nicht einmal das ursprüngliche Ziel von TCL? >;->
so short
Christoph Zurnieden
-
Hallo Christoph,
(Irgendwie fühle ich mich in diesem Thread als Minderheit. Woran das wohl liegt? *g*)
STDERR habe ich ausgelassen, da er für die CGI-Funktionalität nicht unbedingt notwendig ist.
STDERR ist manchmal die einzige Möglichkeit, etwas über den Zustand des Servers zu erfahren, so wie manche, für teures Geld angemietete Accounts, eingeschränkt sind.
Ja, natürlich ist STDERR hilfreich, aber nicht _undbedingt_ notwendig.
Aber gut, das war nicht für eine CGI-Anwendung und fällt auch eher unter die Rubrik "kreativer Umgang mit Technik" ;-)
Was glaubst, welche Sachen _ich_ schon vergenusswurzelt habe? Oft wissen die Leute gar nicht, was man alles mit ihren Entwicklungen anstellen kann;-)
Somit ist es die Sache des Webserveres, ob und wie er eine CGI-Anwendung startet. CGI ist eben nur ein Schnittstellenprotokoll zwischen Webserver und einer auf dem Server laufenden Anwendung.
Ach, noch viel weniger. Das ist eigentlich nur eine Lib in der die gängigsten Methoden versammelt sind, die man sonst alle mühsam selber coden müßte.
Eine Bibliothek wie CGI.pm oder, um beim Thema zu bleiben, ncgi, ist nur dazu da, einem Programmierer etwas Komfort zu bescheren. Notwenig ist sie nicht, um mit einer Schnittstelle oder Protokoll umzugehen.
Die Schnittstelle hat eigentlich gar kein Protokoll, da sie nur die Dateien STDIN, STDOUT und STDERR scharf schaltet und ein paar Environment Variablen belegt, auf das die Daten mit Begründung da durchpfeifen können.
Ui, jetzt wird's akademisch *g*. Na gut, ich glaub's Dir, es ist eine Schnittstelle und kein Protokoll. Aber nur weil es simpel ist, ist es nicht auch gleichzeitig minderwertig. Im Gegenteil, je einfacher, desto besser. Kompliziert wird's meist von selbst;-)
"Ceci n'est pas un pipe"
Wenn ich doch nur verstehen würde, was das heißt *seufz* ...
Ja, ich weiß, 2 EUR in die Wortwitzkasse ;-)
Und wo der Witz ist, aber dafür müßte man auch die Sprache verstehen, doch ... na ja, irgendwer wird's schon wissen.
TCL (ohne TK) ist also durchaus geeignet, für CGI-Anwendungen benutzt zu werden.
Und wenn TCL Netzwerkfähigkeiten hat, die es ermöglichen, verteilte Anwendungen zu schreiben, so ist das auch gut, genauso wie es schön ist, wenn man, unter Zuhilfenahme der TK-Erweiterungen, daß man damit auch GUI-Programme schrieben kann.War das nicht einmal das ursprüngliche Ziel von TCL? >;->
Keine Ahnung, aber wie war das doch noch mit "kreativer Umgang mit Technik" ?
Grüße
Klaus-
Hallo,
(Irgendwie fühle ich mich in diesem Thread als Minderheit. Woran das wohl liegt? *g*)
Wahrscheinlich, weil Du der Einzige bist, der den Überblick behält.
Aber die Frage war wohl nicht so ganz ernst gemeint, oder? ;-)STDERR habe ich ausgelassen, da er für die CGI-Funktionalität nicht unbedingt notwendig ist.
STDERR ist manchmal die einzige Möglichkeit, etwas über den Zustand des Servers zu erfahren, so wie manche, für teures Geld angemietete Accounts, eingeschränkt sind.
Ja, natürlich ist STDERR hilfreich, aber nicht _undbedingt_ notwendig.
Und wo sollen sonst die Meldungen all der sorgfältig und mühsam eingebauten Fehlerabfangroutinen hin? ;-)
Aber gut, das war nicht für eine CGI-Anwendung und fällt auch eher unter die Rubrik "kreativer Umgang mit Technik" ;-)
Was glaubst, welche Sachen _ich_ schon vergenusswurzelt habe? Oft wissen die Leute gar nicht, was man alles mit ihren Entwicklungen anstellen kann;-)
Naja, wenn DRM/Palladium weltweit raus ist, ist's sowieso vorbei.
Somit ist es die Sache des Webserveres, ob und wie er eine CGI-Anwendung startet. CGI ist eben nur ein Schnittstellenprotokoll zwischen Webserver und einer auf dem Server laufenden Anwendung.
Die Schnittstelle hat eigentlich gar kein Protokoll, da sie nur die Dateien STDIN, STDOUT und STDERR scharf schaltet und ein paar Environment Variablen belegt, auf das die Daten mit Begründung da durchpfeifen können.
Ui, jetzt wird's akademisch *g*.
Oh, da entschuldige ich mich, das lag nicht in meiner Absicht.
(Obwohl so ewas in diesem Forum durchaus nichts Ungewöhnliches darstellt ;-)Na gut, ich glaub's Dir, es ist eine Schnittstelle und kein Protokoll. Aber nur weil es simpel ist, ist es nicht auch gleichzeitig minderwertig. Im Gegenteil, je einfacher, desto besser. Kompliziert wird's meist von selbst;-)
"Keep it simple, Dude!" [Quelle verlorengegangen] ;-)
"Ceci n'est pas un pipe"
Wenn ich doch nur verstehen würde, was das heißt *seufz* ...
Ich kann auch kein Französisch, aber der Spruch ist eigentlich bekannt. Steht unter einem Bild einer Tabakspfeife von Rene Magritte (Der hat auch noch Accents, ich weiß aber nie wo ;-) und heißt soviel wie: "Das ist keine Pfeife" (Ist es ja auch nicht, ist ja schließlich nur gemalt)
Ja, ich weiß, 2 EUR in die Wortwitzkasse ;-)
Und wo der Witz ist, aber dafür müßte man auch die Sprache verstehen, doch ... na ja, irgendwer wird's schon wissen.
Das Verbum "durchpfeifen" im Satz davor ist allerdings deutsch. Ich bezog mich da auf Unix-Pipes.
Womit ich dem Wortwitz aber nun vollständig den Witz entzogen habe und ich die 2 EUR wieder ruhigen Gewissens aus der Wortwitzkasse entnehmen kann. ;-)
Das ich eine etwas höhere Bildung vorraussetze entbehrt natürlich nicht einer gewissen Arroganz. Aber in Zeiten von Google kann ich mit diesem Vorwurf gut leben:
http://www.google.de/search?q="Ceci+n'est+pas+un+pipe"&ie=ISO-8859-1&hl=de&meta=
Ein paar Bilder von ihm, leider nicht das angesprochene darunter:
http://btr0xw.rz.uni-bayreuth.de/cjackson/magritte/index.html
http://btr0xw.rz.uni-bayreuth.de/cjackson/magritte/magritte2.htmAh, hier ist doch einer:
http://www.asta.uni-sb.de/~lynx/magritte/so short
Christoph Zurnieden
-
-
-
-
-
-
-
-
Hallo Christoph,
Bei PERL stimmt das so, weil PERL eben diese CGI-Funktionalität hat. TCL hat diese Funktionalität (bisher) nicht und kann sie eigentlich vom Konzept her auch nicht erwerben.
Was ist 'diese CGI-Funktionalität'? Meines Erachtens nur die Fähigkeiten auf STDIN,STDOUT und Environment zugreifen zu können.
Und diese Fähigkeiten wird TCL sicherlich auch haben.Also gut, ich habe mir jetzt gerade einmal einen Crashkurs in TCL verordnet....
(15 min später)
Hier mein erstest TCL-Web-Script (eigentlich auch mein erstes TCL Script überhaupt *g*):
-- schnipp --------
#!tclshputs stdout "Content-type: text/plain"
puts stdout ""
puts stdout "Hallo welt"
-- schnapp --------Und weil ich gerade dabei war, fand ich auch ein Package namens ncgi, welches anscheinend Funktionen im CGI-Umfeld bereitstellt.
Also ganz so schlecht kann es um die CGI-Fähigkleit nicht bestellt sein.
Man kann mit TCL/Tk ganze Webserver konfigurieren und "schreiben" (was man mit PERL nicht im gleichen Maß kann)
Das mußt Du mir jetzt einmal genauer erklären.
Übrigens dachte ich bisher, wir reden über TCL und nicht TK. Soweit ich das verstanden habe, ist TK nur eine Widget-Bibliothek zu TCL (und auch Perl, aber das ist eine andere Geschichte). TCL an sich ist doch auch nur eine Scriptsprache, ohne zwingend GUI-Elemente vorzuschreiben (siehe Beispiel oben).
Bisweilen (hier im Forum sehr selten angesprochen) gibt es etwas Verwirrung, weil es für PERL ja ein sehr reizvolles Tk-Modul gibt. Leider steht in der Doku zu diesem Modul nirgends, daß es übers "Netz" - und damit auch über den Apache - nicht verteilbar und ausführbar ist.
Weil TCL/TK bzw Perl/TK für lokal laufende GUI-Anwendungen gedacht ist, und nicht um dynamische Webseiten über einen HTTP-Server bereitzustellen.
Und um die Verwirrung noch weiterzutreiben: bei apache.org gibts unter http://tcl.apache.org/ seit geraumer Zeit ein hochinteressantes TCL-Projekt. Bloß hat selbst dieses Teil nix mit cgi zu tun.
Kann es nicht sein, daß dieses Projekt ähnliche Ziele verfolgt, wie es auch mod_perl tut? Beim kurzen Reinlesen habe ich irgendwie das gefühl gehabt, daß dem so ist.
Kurz: TCL/Tk-Scripts werden von einem Interpreter gelesen und befolgt, der auf dem "ausführenden" Rechenr installiert sein muß, ob das ein Server-Rechner oder ein Client-Rechner ist, ist egal.
Und wo ist der Unterschied zu Perl, die Syntax ausgenommen?
Grüße
Klaus-
hallo Klaus,
Was ist 'diese CGI-Funktionalität'? Meines Erachtens nur die Fähigkeiten auf STDIN,STDOUT und Environment zugreifen zu können. Und diese Fähigkeiten wird TCL sicherlich auch haben.
Hat es, und STDERR hast du jetzt nicht aufgezählt (weil das auf WINDOWS nicht existiert?)
Also gut, ich habe mir jetzt gerade einmal einen Crashkurs in TCL verordnet....
#!tclsh
puts stdout "Content-type: text/plain"
puts stdout ""
puts stdout "Hallo welt"hihi ;-) das geht auf einem Windows-Rechner noch um eine Zeile kürzer:
button .hallo -text hallo \ -command {puts stdout "hallo welt!"}
pack .hallo -padx 20 -pady 10
... das Ganze "hallo.tcl" nennen, fertig. Kriegst du allerding auf einer UNIX-Kiste nicht realisiert, weil die shebang fehlt. Is aber wursch ;-)Und weil ich gerade dabei war, fand ich auch ein Package namens ncgi, welches anscheinend Funktionen im CGI-Umfeld bereitstellt. Also ganz so schlecht kann es um die CGI-Fähigkleit nicht bestellt sein.
Das Package hab ich auch - auf WinXP wie auf FreeBSD. Was ich mit CGI-Funktionalität" gemeint habe, habe ich vier Ebenen tiefer im aktuellen Thread als Antwort an Christoph Zurnieden wortreich darzulegen versucht.
Übrigens dachte ich bisher, wir reden über TCL und nicht TK. Soweit ich das verstanden habe, ist TK nur eine Widget-Bibliothek zu TCL (und auch Perl, aber das ist eine andere Geschichte). TCL an sich ist doch auch nur eine Scriptsprache, ohne zwingend GUI-Elemente vorzuschreiben (siehe Beispiel oben).
Da hast du prinzipiell recht. "Tk" heißt nix anderes als "T"ool"k"it, und ist vom Ansatz her lediglich eine "grafische Erweiterung" für TCL. Mit GUI-Elementen wird jede Scriptsprache etwas "gefälliger", und Tk tut im Prinzip nix andres, als eine solche "Gefälligkeit" anzubieten.
Weil TCL/TK bzw Perl/TK für lokal laufende GUI-Anwendungen gedacht ist, und nicht um dynamische Webseiten über einen HTTP-Server bereitzustellen.
Bummmmmm ;-)
Da haben wir "eigentlich" das ganze Problem. Für das PERL-Tk-Modul hast du vollkommen recht. TCL/Tk, als durchaus eigenständige Scriptsprache, ist aber ausdrücklich mal als "Netzwerkanwendung" konzipiert worden und soll eben nicht nur "lokal", sondern "netzweit" einsetzbar sein.bei apache.org gibts unter http://tcl.apache.org/ seit geraumer Zeit ein hochinteressantes TCL-Projekt
Kann es nicht sein, daß dieses Projekt ähnliche Ziele verfolgt, wie es auch mod_perl tut?Stimmt. Jedenfalls hab ich das bisher auch immer so gelesen.
Und wo ist der Unterschied zu Perl, die Syntax ausgenommen?
wie ich weiter unten gesagt habe: der Unterschied besteht darin, daß du PERL nur auf dem Server-Rechner installieren mußt. Sobald Server und Client physikalisch zwei unterschiedliche Rechner sind (muß zwar nicht zwingend so sein, ist es aber in der Regel) muß für die Ausführung von TCL-Scripts auf beiden ein TCL-Interpreter vorhanden sein.
Grüße aus Berlin
Christoph S.
PS: Irrtümer oder Kenntnislücken sind nicht ausgeschlossen. Vielleicht kannst du mir helfen, sie zu verringern, falls tatsächlich vorhanden
Grüße
Klaus
-
-
-
-
Hallo,
Enschuldigung, dass ich die gleiche nochmal schreibe, aber ich hab meine eigentliche Frage in dem ersten Beitrag vergessen. Also hier nochmal:
Ich habe habe Apache 1.3.20 auf meinen Windows 9x- Sytem (Windows ME)
installiert nun möchte ich Perl 5.x und Tcl 8.x auf meinen lokalen Server bzw. System intallieren. Den Apache- Server betreibe natürlich nur als Testserver. Wie mache ich das. Wo gibt es eine Anleitung am besten auf Deutsch (Englisch ginge aber auch)? Bei www.activestate.com blicke ich nicht ganz durch.Danke,
MFG
Christopher Morris
Hallo,
vielen Dank für die Hilfe. Jetzt habe ich mir jetzt ActivePerl und ActiveTcl von Activestate heruntergeladen (Windows Versionen). Nun habe ich beiden Zip- Ariche entpackt, aber nun weiß ich nicht mehr weiter.
Ich möchte Perl und Tcl so installieren, dass ich mit der cgi-bin- Schnittstelle von Apache zugreifen kann! Ich benutze Windows ME als Betriebsystem.MFG
Christopher Morris
-
hi Christopher ;-)
ähm, jetzt haben wir mindestens drei "Christoph's in diesem Thread, das ist auch ein Novum *g*
Jetzt habe ich mir jetzt ActivePerl und ActiveTcl von Activestate heruntergeladen (Windows Versionen). Nun habe ich beiden Zip- Ariche
ups? Was hast du dir da für "Windows-Archive" geholt? Es gibt bei ActiveState sowohl für "ActivePerl" wie auch für "ActiveTCL" Installer-Pakete mit der Endung MSI. _Diese_ Dateien solltest du dir downloaden. Die ZIP's bringen dir nix.
Ich möchte Perl und Tcl so installieren, dass ich mit der cgi-bin- Schnittstelle von Apache zugreifen kann!
Was du da für PERL vorhast, geht völlig problemlos (vorausgesetzt, du hast das über den MSI-Instsller gemacht). Mit TCL gehts nicht im gleichen Maß problemlos - siehe die Doskussion im Thread zum "TCL-Thema". Nicht ganz unwichtig ist auch noch, welche Apache-Version du installiert hast.
Ich benutze Windows ME als Betriebsystem.
Oh. Wenn du auf Win2000 oder WinXP aufrüsten kannst, solltest du das aber so schnell wie möglich tun. WinMe ist ein "Zwitterwesen", das von Microsoft einzig zum Geldverdienen auf den Markt gebracht wurde. Wenn du ME fahren kannst, sollte die Leistungsfähigkeit deines Rechners auch für XP ausreichen. Das hat zwar auch eine Reihe von problematischen Einstellungen und Vorgaben, kann aber alles das, wovon dir ME nur vorgaukelt, daß ers "in Zukunft" mal kommen würde.
Grüße aus Berlin
Christoph S.
-