cgi-bin.... (noch) notwendig?

[WauWau]

Hallo,

nun, WauWau hat gestern __endlich__ Mal ActivePerl für Windows runtergeladen (oder war das heute...?). So, wird soweit kein Problem sein, ich wollte mir heute abend mal was in Perl zusammenbasteln :) - mal sehen.

Nun mein Gedanke über "cgi-bin". Diese sonderbaren Verzeichnisse, die unzertrennlich mit Perl in Verbindung gebracht werden (zumindest in jedem Zusammenhang, den ich bis jetzt gehört habe), scheinen ja was ganz tolles zu sein. Oder gewesen zu sein. Oder wie jetzt?

Als ich vor ein paar Tagen mal hier im Self-Raum rumgelungert bin, bin ich auch mal über eine Apache-Beispielkonfiguration (für unterschiedliche OS) gestoßen... Es war die für einen Apache 1.3, ich benutze schon Apache2 (hmm.. Apache 1.3 muss sehr alt sein, nicht wahr?). Demnach, was ich da gelesen habe, würde ich sagen, dass Dateien in cgi-bin-verzeichnissen grundsätzlich als "ausführbare" Dateien behandelt werden. Mit welcher Datei der Apache sie dann ausführt, dass soll in der ersten Zeile stehen, diesem... wie hieß das gleich nochmal? Naja, sieht auf jeden fall z.B. so aus:

#!/user/bin/..../perl.exe -w

oder vergleichbares ;). Nunja, das scheint wohl der Verwendungszweck von cgi-bin-verzeichnissen zu sein [1] - oder gewesen zu sein...!?

Immerhin haben alle Perl-Dateien, die bei dem Installationszip dabei waren, die Endung .pl. Genauso wie die, die bei Apache dabei waren, und die, die bei meinem MySQL dabei waren. Allgemein üblich habe ich überall perl-dateien mit der Endung .pl gesehen. wieso also Perl-Dateien lediglich als keine-endung-dateien in einem cgi-bin-verzeichnis speichern, um sie anschließend mit diesem #!-schnörkel (der name liegt mir auf der zunge....) auszuführen? Ich würde sie in meinen Apachen genauso wie PHP-Dateien einbinden. Dann könnten sie überall liegen. Nur seltsamerweise sieht man sowas heutzutage recht selten. Wieso? Warum? Grund...!?

Ich fände es auf jeden fall extrem ... komisch, wenn ich meine webpräsenzen - (nur) weil sie in Perl geschrieben sind - in cgi-bin-verzeichnissen speichern würde...

Übrigens sind Perl-Dokumente recht unkomportabel, denn dieses schnörkel, auf dessen name ich nicht komme, beschreibt ja den Pfad zu dem Perl.exe-Programm, der ja von System zu System unterschiedlich ist - obwohl es bei Linux da höchstwahrscheinlich überall gleich ist...

'Freue mich natürlich über jede Antwort ;),

WauWau

[1] => Apache2 bietet afaik nicht mehr diese Funktion...

[Christoph Schnauß]

n'abends WauWau,

nun, WauWau hat gestern __endlich__ Mal ActivePerl für Windows runtergeladen

Wurde aber auch Zeit :o)
Hast es denn nach dem Runterladen auch installiert?

Nun mein Gedanke über "cgi-bin". Diese sonderbaren Verzeichnisse, die unzertrennlich mit Perl in Verbindung gebracht werden

Ups? Das tun sie nicht. Die "Unzertrennlichkeit" hat was mit CGI zu tun. Natürlich ist PERL dafür nicht ganz unwichtig, aber bei weitem nicht der einzige "Teilhaber".

(zumindest in jedem Zusammenhang, den ich bis jetzt gehört habe), scheinen ja was ganz tolles zu sein. Oder gewesen zu sein. Oder wie jetzt?

Demnach, was ich da gelesen habe, würde ich sagen, dass Dateien in cgi-bin-verzeichnissen grundsätzlich als "ausführbare" Dateien behandelt werden

grrrmpf ... jaein. Du kannst in ein solches Verzeichnis auch eine HTML-Datei legen, und was würdest du von der "ausführen" lassen wollen?
Richtig ist allerdings, daß ein solches Verzeichnis _in der Regel_ ausführbare Dateien enthält.

Mit welcher Datei der Apache sie dann ausführt, dass soll in der ersten Zeile stehen

Du meinst die shebang. Es gibt dort eine Pfadangabe, die korrekt sein muß, falls es sich bei deiner CGI-Datei tatsächlich um ein PERL-Script handelt. Ich habe in meinem CGI-BIN-Verzeichnis auch noch allerhand BAT- und EXE- und ein paar andere ausführbare Dateien liegen, und die benötigen keine shebang.

Immerhin haben alle Perl-Dateien, die bei dem Installationszip dabei waren, die Endung .pl

Öhm, was für ein "Installationszip" war das denn? Bei ActivePerl gibts sowas nicht.

Allgemein üblich habe ich überall perl-dateien mit der Endung .pl gesehen

Das ist mehr oder weniger durch Gewohnheit geheiligter "Standard". Sie könnten aber genausogut ".alfons" heißen, sofern dein Webserver und dein Interpreter was damit anfangen kann.

Übrigens sind Perl-Dokumente recht unkomportabel, denn dieses schnörkel, auf dessen name ich nicht komme, beschreibt ja den Pfad zu dem Perl.exe-Programm, der ja von System zu System unterschiedlich ist - obwohl es bei Linux da höchstwahrscheinlich überall gleich ist...

[1] => Apache2 bietet afaik nicht mehr diese Funktion...

Selbstverständlich hält auch Apache2 die Einrichtung von cgi-bin-Verzeichnissen vor, einschließlich der zugehörigen Script-Aliase. Wer erzählt dir da was anderes?

Grüße aus Berlin

Christoph S.

[WauWau]

Hola Christoph,

nun, WauWau hat gestern __endlich__ Mal ActivePerl für Windows runtergeladen
Wurde aber auch Zeit :o)

ganz genau - hatte ich schon seit ein paar Tagchen vor ;-)

Hast es denn nach dem Runterladen auch installiert?

[dabei ziehe ich jetzt mal was vor:]

Immerhin haben alle Perl-Dateien, die bei dem Installationszip dabei waren, die Endung .pl
Öhm, was für ein "Installationszip" war das denn? Bei ActivePerl gibts sowas nicht.

Also, es gab das Ding als zip und als msi. Ich wollte mir eigentlich das MSI-Teil holen.. keine ahnung, in geistesabwesenheit muss ich wohl irgendwie auf das zip gekommen sein ;-) Das hatte ich dann auf der Platte, habe es mal extrahiert (alleine das hat schon 10 Minuten gedauert ;-), und dann wundervolle Dateien auf der Platte. Da war auch gleich eine nette .bat dabei, die auf der Konsole auch das gemacht hat, was sie machen sollte, und zwar Perl richtig "installieren"... ooeehmm, was hat das eigentlich gemacht? Ich bemerke gerade, dass die Endung "pl" gar nicht mit dem Perl-Interpreter "verbunden" wurde 8[
Na gut, es hat das gesamte ding einmal in ein anderes verzeichnis kopiert (das hat ungefähr eine halbe stunde gedauert ;) und das sowieso schon hässliche startmenü mit ein paar weiteren einträgen verschmutzt *g* ;) Ansonsten nix... ;)
Na gut, fehlendes, wie z.B. der Eintrag in die httpd.conf sowie der Eintrag der "pl"-Endung in Registry hat es nicht gemacht - sei's drum, ist ne sache von 50 sekunden ;)

Ach ja, bezüglich CGI/SAPI: Ich habe PHP als SAPI beim Apachen drin, afaik heißt das, dass alle "Module", die SAPI-dll sowie die php.exe im arbeitsspeicher "geladen" sind, nicht wahr? Jo, wenn ich Perl dann per einfachem CGI einbinde, dann ist das da nicht so, oder? Will ich nämlich hoffen, denn _noch_ mehr Ressourcen kann ich meinem armen kleinen PCchen hier wirklich nicht zumuten, er hat jetzt schon zuwenig 8[

Nun mein Gedanke über "cgi-bin". Diese sonderbaren Verzeichnisse, die unzertrennlich mit Perl in Verbindung gebracht werden
Ups? Das tun sie nicht.

Richtig, tun sie auch nicht. Dasda:

(zumindest in jedem Zusammenhang, den ich bis jetzt gehört habe), scheinen ja was ganz tolles zu sein. Oder gewesen zu sein. Oder wie jetzt?

stammt übrigens von mir, und gehört zu dem da oben dazu. Wenn du das in der Klammer noch dazu "bappst", dann gibt's wieder einen imho richtigeren Sinn.

Die "Unzertrennlichkeit" hat was mit CGI zu tun. Natürlich ist PERL dafür nicht ganz unwichtig, aber bei weitem nicht der einzige "Teilhaber".

jo, genau.

Ach bezüglich cgi-bin: Kann man da dann auch eigene schöne .exe-teile und sowas reinpacken, und die werden dann als cgi-programme ausgeführt? coool :)

grrrmpf ... jaein. Du kannst in ein solches Verzeichnis auch eine HTML-Datei legen, und was würdest du von der "ausführen" lassen wollen?

hmm... nein :)
Ich meinte eigentlich, dass es afaik bei Apache eine Möglichkeit gibt, dass er die Dateien dann unabhängig ihrer Endung einfach alle als cgi-dateien ausführt.

/cgi-bin/program
  /cgi-bin/programmblabla

Richtig ist allerdings, daß ein solches Verzeichnis _in der Regel_ ausführbare Dateien enthält.

na wenn's doch so ist ;) - mein weberver enthält um die 500 ausführbare Dateien, und keine einzige steckt in einem cgi-bin-verzeichnis :)

Mit welcher Datei der Apache sie dann ausführt, dass soll in der ersten Zeile stehen

Genau, dieser shebang-...strengenommener fastschwachsinn.

Du meinst die shebang. Es gibt dort eine Pfadangabe, die korrekt sein muß, falls es sich bei deiner CGI-Datei tatsächlich um ein PERL-Script handelt. Ich habe in meinem CGI-BIN-Verzeichnis auch noch allerhand BAT- und EXE- und ein paar andere ausführbare Dateien liegen, und die benötigen keine shebang.

genau, weil sie ja auch _richtige_ ausführbare dateien sind ;)

Bezüglich shebang: Die plattformunabhängigkeit, ja sogar rechnerunabhängigkeit ist dadurch ja völlig zerstört. So schicke ich dir jetzt mal 100 Perl-Dateien von mir, und alle haben im Shebang die Adresse _meiner_ perl.exe, und zwar D:/perl/bin/perl.exe (ist es glaube ich ;) stehen, und bei dir ist es dann /usr/bin/perl oder sowas... nicht wahr?

Allgemein üblich habe ich überall perl-dateien mit der Endung .pl gesehen
Das ist mehr oder weniger durch Gewohnheit geheiligter "Standard". Sie könnten aber genausogut ".alfons" heißen, sofern dein Webserver und dein Interpreter was damit anfangen kann.

jo, klar. "allgemein üblich"... Alle Perl-Dateien, auf die ich bis jetzt gestoßen bin, hatten entweder keine endung oder die endung "pl".

Selbstverständlich hält auch Apache2 die Einrichtung von cgi-bin-Verzeichnissen vor, einschließlich der zugehörigen Script-Aliase. Wer erzählt dir da was anderes?

Ich meinte dieses Verhalten mit dem Shebang. So, und jetzt muss ich endlich meine Quelle zu rate ziehen:

http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf061.htm

Ich zitiere, etwas unterhalb der "mitte":

--------------------------------------------------------------

Apache durchsucht grundsätzlich sämtliche CGI-Scripts nach einer "shebang"-Zeile.

Diese Kommentarzeile, die immer die erste Zeile des Scripts sein muß, besteht

aus der Raute (#) und einem Ausrufezeichen (!), gefolgt von der Pfadangabe für

das Programm, das dieses spezielle CGI-Script ausführen soll.

Beispiel:

Sie möchten ein Perl-Script als CGI-Script ausführen lassen. Der Pfad zu Ihrer

"perl.exe"lautet "C:\Perl\bin". Dann muß die "shebang"-Zeile folgendes Aussehen

haben:

#  #!C:/Perl/bin/perl.exe

AUF GAR KEINEN FALL darf die aktuelle "shebang"-Zeile eingerückt werden, und es

muß auch IMMER die erste Zeile in Ihrem Script sein. Selbstverständlich müssen

Sie auch die Ausführung von CGI-Programmen durch Ihren Server zulassen, indem Sie

entsprechende Script-Aliase vergeben oder die Anweisung "Options ExecCGI" für

die infrage kommenden Dateien bzw. Verzeichnisse aktivieren.

Apache kann unter WINDOWS entweder das eben beschriebene UNIX-Verhalten

befolgen oder die registry nach Dateinamen-Erweiterungen durchsuchen. Der Befehl

zum Ausführen einer Datei, deren Typ in der registry beschrieben ist, wird

übernommen und mit derselben Methode abgearbeitet, mit der der WINDOWS-

Explorer diesen Dateityp bei einem Doppelklick mit der Maustaste behandeln

würde.

Sie können unter WINDOWS selbst bestimmen, welches Programm für die

Abarbeitung von bestimmten Dateinamen-Erweiterungen zuständig sein soll. Dazu

öffnen Sie im WINDOWS-Explorer unter "Ansicht" die "Ordneroptionen", klicken

dort auf die Registerkarte "Dateitypen" und legen in den sich öffnenden Dialogfenstern

fest, welches Programm Apache beim Aufruf des ausgewählten Dateityps ausführen

soll. Schlägt eine Programmausführung fehl, wird Apache versuchen, den "shebang"-

Befehl zu befolgen.

Dieses Verhalten soll in der Apache-Version 2.0 anders gestaltet werden.

--------------------------------------------------------

Mit einem Augenmerk auf die letzte Zeile.

Ach ja, und danach kam sowas:

--------------------------------------------------------
 Jeder Mechanismus hat seine eigenen Sicherheitsrisiken, wenn Sie ein Programm

von einer Webseite aus direkt aufrufen, aber nicht immer erst eine Sicherheitsabfrage

beantworten möchten. Die Suche nach geeigneten risikolosen Methoden ist die

Grundlage einer unendlichen Debatte.

Um nun dieses spezielle WINDOWS-Verhalten zu erlauben (und den äquivalenten

UNIX-Stil zu unterdrücken) entfernen Sie das Kommentarzeichen vor der nächsten

Zeile.

ScriptInterpreterSource registry
-------------------------------------------------------

Die Direktive habe ich bei Apache2 noch nirgends gefunden.

WauWau

[Christoph Schnauß]

morgens WauWau,

Also, es gab das Ding als zip und als msi. Ich wollte mir eigentlich das MSI-Teil holen.

Hättest du mal machen sollen.

Da war auch gleich eine nette .bat dabei, die auf der Konsole auch das gemacht hat, was sie machen sollte, und zwar Perl richtig "installieren"

Ohje. Es sind in diesem ZIP-Archiv eine ganze Reihe von BAT-Dateien drin, und längst nicht alle "installieren" dir PERL. Welche davon hast du nun wie aufgerufen?

ooeehmm, was hat das eigentlich gemacht?

öhm, keine Ahnung. Wahrscheinlich hat sie das gemacht, was in ihr als "Befehl" drinsteht. Hast du nicht reingeschaut?

Ich bemerke gerade, dass die Endung "pl" gar nicht mit dem Perl-Interpreter "verbunden" wurde 8[

Da dürfte noch viel mehr nicht passiert sein. Dir werden wahrscheinlich ein paar Dutzend bis ein paar Hundert registry-Einträge fehlen.

Na gut, es hat das gesamte ding einmal in ein anderes verzeichnis kopiert (das hat ungefähr eine halbe stunde gedauert

halbe Stunde? Um Gottes willen! Was für einen Uralt-Rechner hast du  -  einen 386er? Auf meinem 486er mit 16 MB RAM dauert das ziemlich exakt vier Minuten.

Na gut, fehlendes, wie z.B. der Eintrag in die httpd.conf sowie der Eintrag der "pl"-Endung in Registry hat es nicht gemacht

Kann "es" auch nicht. Das mußt du schon selbst entscheiden, ob du sowas überhaupt haben möchtest.

Ich habe PHP als SAPI beim Apachen drin

Ja, na und? Das hat mit PERL gar nix zu tun.

Ach bezüglich cgi-bin: Kann man da dann auch eigene schöne .exe-teile und sowas reinpacken, und die werden dann als cgi-programme ausgeführt?

Selbstverständlich kann man das. Man muß es nur dem Apache sagen, daß und wie er auf Requests für EXE-Dateien reagieren soll.

mein weberver enthält um die 500 ausführbare Dateien, und keine einzige steckt in einem cgi-bin-verzeichnis

Nö. Dein Webserver "enthält" nicht eine einzige ausführbare Datei  -  er ist selbst eine. Er ist aber notabene gezwungen, mit ausführbaren Dateien plattformunabhängig umgehen zu können. Du mußt dir langsam mal über den Gebrauch des korrekten Vokabulars klar werden, könnte irgendwann mal später in einer Abiturprüfung abgefragt werden. Zur Zeit würde ich dich durchfallen lassen, dir aber Nachhilfestunden (gegen entsprechendes Entgelt) anbieten.

Bezüglich shebang: Die plattformunabhängigkeit, ja sogar rechnerunabhängigkeit ist dadurch ja völlig zerstört. So schicke ich dir jetzt mal 100 Perl-Dateien von mir, und alle haben im Shebang die Adresse _meiner_ perl.exe, und zwar D:/perl/bin/perl.exe (ist es glaube ich ;) stehen, und bei dir ist es dann /usr/bin/perl oder sowas... nicht wahr?

Das ist mir wurscht. Der Apache kennt (leider) auch die Drektive "ScriptInterpreterSource"

http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf061.htm
  Ich zitiere, etwas unterhalb der "mitte"

Nett von dir. Du zitierst meinen eigenen Feature-Artikel (den ich als Verfasser ja wohl kennen sollte). Das ist, glaube ich, noch nie vorgekommen. Große Ehre für mich. Nur: daß es in Apache2 "default" keinen solchen Kommentarblock mehr gibt, bedeutet noch lange nicht, daß Apache 2.x.x cgi-bin-Verzeichnisse nach wesentlich anderen Gesichtspunkten behandeln würde als sein Vorgänger. Im Gegenteil: in der Doku fällt nun die Erklärung für CGI etwas genauer aus. Dann braucht man einen solchen Kommentarblock eben nicht mehr in der httpd.conf mitzugeben.

Grüße aus Berlin

Christoph S.

[WauWau]

Hallo Christoph,

Also, es gab das Ding als zip und als msi. Ich wollte mir eigentlich das MSI-Teil holen.

Hättest du mal machen sollen.

Wird schon nicht so schlimm sein. Das ding ist sowieso mehrere .... MB groß und ich werde mir jetzt nicht noch zusätzlich die msi holen.

Ohje. Es sind in diesem ZIP-Archiv eine ganze Reihe von BAT-Dateien drin, und längst nicht alle "installieren" dir PERL. Welche davon hast du nun wie aufgerufen?

Die Datei "Installer.bat", direkt im "obersten" Verzeichnis in der zip.

ooeehmm, was hat das eigentlich gemacht?

öhm, keine Ahnung. Wahrscheinlich hat sie das gemacht, was in ihr als "Befehl" drinsteht. Hast du nicht reingeschaut?

doch, habe ich. Drinnen steht erst mal ein bisschen BAT-Zeugs, das ruft dann den perl-interpreter auf, der rest ist nur noch Perl-Code. Und hier steht was es macht (ich ... scheine es vergessen zu haben):

#!ActivePerl/Perl/bin/perl -w
#line 15

ActivePerl ZIP installer

Copyright (c) 2000-2003 ActiveState Corp.  All rights reserved.

ActiveState is a division of Sophos Plc.

This program completes a simple installation of ActivePerl

The intent of this program is to provide a "fail-safe" way of installing

a fully-functional version of ActivePerl.  If there is a failure, this

script should explain exactly what went wrong, and how to fix it.

If not, submit that as a bug.

What is does:

#     o Relocates Perl
#     o Creates MSWin32 Shortcuts to the HTML documentation
#     o Configures PPM
#     o Configures lib/Config.pm for use with a development system
#     o Creates ActivePerl registry entries
#     o Updates the PATH environment variable

Todo:

#     o uninstall (pretty simple)
#     o configure Perl for use with a Web Server
#     o set up file associations on Win32

also.

Ich bemerke gerade, dass die Endung "pl" gar nicht mit dem Perl-Interpreter "verbunden" wurde 8[

Da dürfte noch viel mehr nicht passiert sein. Dir werden wahrscheinlich ein paar Dutzend bis ein paar Hundert registry-Einträge fehlen.

siehe oben was das bat macht. Fehlt da noch was?

Na gut, es hat das gesamte ding einmal in ein anderes verzeichnis kopiert (das hat ungefähr eine halbe stunde gedauert

halbe Stunde? Um Gottes willen! Was für einen Uralt-Rechner hast du  -  einen 386er? Auf meinem 486er mit 16 MB RAM dauert das ziemlich exakt vier Minuten.

In dem zip befinden sich 2870 Dateien. Das heißt, er hat gerade mal rund 2900 Dateien extrahiert (hat nur etwa eine minute gedauert) und das bat hat das ganze zeugs einmal von einer festplatte zur anderen (gleicher pc) rübergepfuscht. also von einer partition zur anderen.
Und was ich für einen habe? 386er Pentium (oh!) mit 32MB RAM ;) nene, meiner ist ein 667MHZ-PentiumIII mit 256MB Ram. Ist aber schon im leerlauf recht ausgelastet, wegen den ganzen serverdiensten (apache, wie bereits gesagt php als api drin (+10MB), mysql, ... und win2k ;)

Na gut, fehlendes, wie z.B. der Eintrag in die httpd.conf sowie der Eintrag der "pl"-Endung in Registry hat es nicht gemacht

Kann "es" auch nicht. Das mußt du schon selbst entscheiden, ob du sowas überhaupt haben möchtest.

Es hätte zumindest fragen können ;-)

Ich habe PHP als SAPI beim Apachen drin
Ja, na und? Das hat mit PERL gar nix zu tun.

Hat es auch nicht. Aber du hast das ja hier auch schlichtweg aus dem sinnzusammenhang geschnitten, denn es bezog sich darauf, dass ich keine lust habe, noch mehr ressourcen für den apachen zur verfügung zu stellen. muss ich aber auch net. Perl bekommt eine einfache cgi-einbindung und endung .pl wird mit perl.exe ausgeführt, und basta. nix sapi oder sowas

Ach bezüglich cgi-bin: Kann man da dann auch eigene schöne .exe-teile und sowas reinpacken, und die werden dann als cgi-programme ausgeführt?

Selbstverständlich kann man das. Man muß es nur dem Apache sagen, daß und wie er auf Requests für EXE-Dateien reagieren soll.

na dann ist ja gut :)

mein weberver enthält um die 500 ausführbare Dateien, und keine einzige steckt in einem cgi-bin-verzeichnis
Nö. Dein Webserver "enthält" nicht eine einzige ausführbare Datei  -  er ist selbst eine.

Entschuldige vielmals, das ist aber auch ein arger ausdruck da oben... natürlich enthält nicht mein schöner kleiner Apache diese 500 Dateien, sondern das Verzeichnis E:/Homepages/webserver/, das Stammverzeichnis des "Haupthosts". In diesem verzeichnis stecken eben wie bereits gesagt an die 500 PHP-Dateien, und keine einzige in einem cgi-bin-verzeichnis.

Du mußt dir langsam mal über den Gebrauch des korrekten Vokabulars klar werden,

Also .... es tud mir vielmals leid, ich scheine diesen Satz da oben ohne auch nur ein bisschen Nachdenken geschrieben zu haben ;)

könnte irgendwann mal später in einer Abiturprüfung abgefragt werden.

Dauert noch ein paar Jährchen *g* ;)

Zur Zeit würde ich dich durchfallen lassen,

Nun, erst einmal geht es beim Abi nicht nur um den "Gebrauch des korrekten Vokabulars" (vielleicht in Fremdsprachen ;), und zudem ... kann sich wauwau sehrwohl korrekt ausdrücken ;-)

dir aber Nachhilfestunden (gegen entsprechendes Entgelt) anbieten.

.... Du willst mir Nachhilfestunden in der deutschen Sprache geben? *ggg* ;-) Das ist lustig ;)

Bezüglich shebang: Die plattformunabhängigkeit, ja sogar rechnerunabhängigkeit ist dadurch ja völlig zerstört. So schicke ich dir jetzt mal 100 Perl-Dateien von mir, und alle haben im Shebang die Adresse _meiner_ perl.exe, und zwar D:/perl/bin/perl.exe (ist es glaube ich ;) stehen, und bei dir ist es dann /usr/bin/perl oder sowas... nicht wahr?

Das ist mir wurscht. Der Apache kennt (leider) auch die Drektive "ScriptInterpreterSource"

Dir ist es wurscht, ob du deine perl-dateien noch benutzen kannst, wenn du sie ... plötzlich auf einem anderen server ausführen lassen sollst/willst? Imho keine gute Einstellung.

Du zitierst meinen eigenen Feature-Artikel (den ich als Verfasser ja wohl kennen sollte).

Der ist von dir, genau. Habe ich auch nicht so ganz mitbekommen, obwohl ich sogar den Namen "Christoph Schnauß" registriert habe ;-)
Da siehst du mal, wie zerstreut ich bereits bin....

Nett von dir.
Das ist, glaube ich, noch nie vorgekommen. Große Ehre für mich.

...Fühlst du dich jetzt gekränkt, da ich eine "Quelle" (von dir) angegeben habe? Das ist doch jetzt nicht so schlimm, oder?

Nur: daß es in Apache2 "default" keinen solchen Kommentarblock mehr gibt,

Wie "default"? Du meinst, in der "voreingestellten" httpd.conf? Da gibt (bzw. bei meiner "gab") es auch eine ganze menge kommentare, von denen ich meine httpd.conf erst einmal befreien musste ;-)

bedeutet noch lange nicht, daß Apache 2.x.x cgi-bin-Verzeichnisse nach wesentlich anderen Gesichtspunkten behandeln würde als sein Vorgänger.

Hmm... und auf was bezieht sich die Aussage, im Apachen2 solle dieses [Verhalten mit den Shebangs] sich ändern?

Im Gegenteil: in der Doku fällt nun die Erklärung für CGI etwas genauer aus.

ja, die Doku ist schon cool.

Dann braucht man einen solchen Kommentarblock eben nicht mehr in der httpd.conf mitzugeben.

richtig. aber gab's den keine gute doku für apache1[.3]?

Grüße aus Berlin

hallo nach da oben ;-)
Grüße aus .... ist doch mittlerweile bekannt, oder? na gut, ich liebe es, diese fürchterliche homepage zu verlinken: http://www.kelkheim.de ;-)

WauWau

[Erwin]

Hallo,

Nun mein Gedanke über "cgi-bin". Diese sonderbaren Verzeichnisse, die unzertrennlich mit Perl in Verbindung gebracht werden (zumindest in jedem Zusammenhang, den ich bis jetzt gehört habe), scheinen ja was ganz tolles zu sein. Oder gewesen zu sein. Oder wie jetzt?

Nun, PerlScripts, besser gesagt, CGI-Scripts , werden im weiteren Sinne als Programme, also als ausführbare Dateichen betrachtet. Und früher war's so, dass Programme Binärdateien , binaries, sind. Joho, aus CGI und BIN , schwuppdiewupp, hahmse (Ouh - ja wer eigentlich, ich war's nich) /cgi-bin/ gemacht.

Als ich vor ein paar Tagen mal hier im Self-Raum rumgelungert bin, bin ich auch mal über eine Apache-Beispielkonfiguration (für unterschiedliche OS) gestoßen... Es war die für einen Apache 1.3, ich benutze schon Apache2 (hmm.. Apache 1.3 muss sehr alt sein, nicht wahr?). Demnach, was ich da gelesen habe, würde ich sagen, dass Dateien in cgi-bin-verzeichnissen grundsätzlich als "ausführbare" Dateien behandelt werden. Mit welcher Datei der Apache sie dann ausführt, dass soll in der ersten Zeile stehen, diesem... wie hieß das gleich nochmal? Naja, sieht auf jeden fall z.B. so aus:

#!/user/bin/..../perl.exe -w

Das is die Shebang. (DE: Kram)

Der Apache brauchtse, danmit er weiß was er mit der Datei machen soll, z.B. die Datei zum PERL - Interbreter schicken zum ausführen.

GRundsätzlich sind Dateien im Verzeichnis /cgi-bin/ nicht grundsätzlich ausführbar, das privileg der Ausführbarkeit ist ein Attribut einer Datei und im FileSystem verankert (um das mal so zu sagen , ja).

oder vergleichbares ;). Nunja, das scheint wohl der Verwendungszweck von cgi-bin-verzeichnissen zu sein [1] - oder gewesen zu sein...!?

Immerhin haben alle Perl-Dateien, die bei dem Installationszip dabei waren, die Endung .pl. Genauso wie die, die bei Apache dabei waren, und die, die bei meinem MySQL dabei waren. Allgemein üblich habe ich überall perl-dateien mit der Endung .pl gesehen. wieso also Perl-Dateien lediglich als keine-endung-dateien in einem cgi-bin-verzeichnis speichern, um sie anschließend mit diesem #!-schnörkel (der name liegt mir auf der zunge....) auszuführen? Ich würde sie in meinen Apachen genauso wie PHP-Dateien einbinden. Dann könnten sie überall liegen. Nur seltsamerweise sieht man sowas heutzutage recht selten. Wieso? Warum? Grund...!?

Im Apache Web Server kannst du entweder einen ScriptAlias auf

/cgi-bin/
/cgi-fuzzi/

angeben oder mit

AddHandler cgi-script .cgi .pl .fuzz .foo .bar

dafür sorgen, dass die Dateien mit obenstehender Erweiterung in jedem Verzeichnis als CGI-Script ausgeführt werden, sofern die laut Dateiattribute auch ausführbar sind.

Gruss, Rolf

[WauWau]

Hallo Erwin,

Nun, PerlScripts, besser gesagt, CGI-Scripts , werden im weiteren Sinne als Programme, also als ausführbare Dateichen betrachtet.

Hmmm... nunja, ohne den Interpreter sind sie nix weiter als sinnlose Textdateien. Deswegen würde _ich_ sie nicht umbedingt als "ausführbare Dateichen" ansehen. Aber es kommt natürlich auf den Blickwinkel drauf an ;)

Und früher war's so, dass Programme Binärdateien , binaries, sind. Joho, aus CGI und BIN , schwuppdiewupp, hahmse (Ouh - ja wer eigentlich, ich war's nich) /cgi-bin/ gemacht.

hmm.. super idee ;)

#!/user/bin/..../perl.exe -w
Das is die Shebang. (DE: Kram)

jo, genau. Das süße kleine Wörtchen ist mir net eingefallen... Frechheit ;)

Der Apache brauchtse, danmit er weiß was er mit der Datei machen soll, z.B. die Datei zum PERL - Interbreter schicken zum ausführen.

genau. Zumindest ... der Apache 1.3. Beim Apachen2... kann der's eigentlich noch? Wenn nicht, wäre ja komisch..., wenn schon, wundere ich mich, wo da einzustellende direktiven sind ;)

GRundsätzlich sind Dateien im Verzeichnis /cgi-bin/ nicht grundsätzlich ausführbar, das privileg der Ausführbarkeit ist ein Attribut einer Datei und im FileSystem verankert (um das mal so zu sagen , ja).

Auch wieder eine Sache für sich. Unter Linux mag einem ja die Möglichkeit gegönnt sein, diese Attribute (die sich mittels FTP-Clienten auf Dateien ja wunderschön einstellen lassen) einzustellen, doch wenn der Webserver der eigene Computer ist, zudem darauf Windows läuft, dann gibt's da keine weiteren Attribute außer "Archiv", "Schreibgeschützt" und "Versteckt" ;-)

/cgi-bin/
/cgi-fuzzi/
angeben ...

jo, genau...

AddHandler cgi-script .cgi .pl .fuzz .foo .bar
dafür sorgen, dass die Dateien mit obenstehender Erweiterung in jedem Verzeichnis als CGI-Script ausgeführt werden, sofern die laut Dateiattribute auch ausführbar sind.

eben. Letztenendes die Frage, ob man sich darauf beschränken will, Perl-dateien nur in stupiden cgi-bin-verzeichnissen zu benutzen ;-)
Aber vielleicht bin ich auch nur den "Luxus" von PHP-Dateien gewöhnt, sie nicht in cgi-bin-Verzeichnissen abzuspeichern ;-)

WauWau

[Vinzenz]

Hallo WauWau,

Hmmm... nunja, ohne den Interpreter sind sie nix weiter als sinnlose Textdateien. Deswegen würde _ich_ sie nicht umbedingt als "ausführbare Dateichen" ansehen. Aber es kommt natürlich auf den Blickwinkel drauf an ;)

Batch-Dateien, oder allgemeiner Shellscripts sind ausführbare Dateien, auch wenn sie einen Interpreter benötigen. Die Ausführbarkeit einer Datei hat weniger damit zu tun, ob es sich um eine Binärdatei oder eine Textdatei handelt. Eine Grafikdatei ist eine Binärdatei, dennoch nicht ausführbar. Ein Shellskript ist eine ASCII-Datei, dennoch ausführbar.

Unter UNIX/Linux musst Du das Ausführbarkeitsflag setzen, unter Windows der Datei die entsprechende Endung verpassen. Du solltest übrigens die Doku von ActivePerl lesen ;-)

Der Apache brauchtse, danmit er weiß was er mit der Datei machen soll, z.B. die Datei zum PERL - Interbreter schicken zum ausführen.
genau. Zumindest ... der Apache 1.3. Beim Apachen2... kann der's eigentlich noch? Wenn nicht, wäre ja komisch..., wenn schon, wundere ich mich, wo da einzustellende direktiven sind ;)

Kein Unterschied zwischen apache 1.3, dem direkten Vorläufer von apache 2, und seinem Nachfolger :-)
Die Shebang-Zeile wird nicht für den apache benötigt, sondern für die Shell. Diese muss wissen, an wen sie das Skript schicken soll.

Auch wieder eine Sache für sich. Unter Linux mag einem ja die Möglichkeit gegönnt sein, diese Attribute (die sich mittels FTP-Clienten auf Dateien ja wunderschön einstellen lassen) einzustellen, doch wenn der Webserver der eigene Computer ist, zudem darauf Windows läuft, dann gibt's da keine weiteren Attribute außer "Archiv", "Schreibgeschützt" und "Versteckt" ;-)

Selbst unter schnödem MS-DOS gab es bereits das Attribut "System"
S steht nicht für "Schreibgeschützt", sondern für "System",
R steht für "Schreibgeschützt" (read only)

Bei NTFS ist alles ein Attribut, selbst der Dateiinhalt.
Wie Du Perlskripte unter Windows "direkt" ausführen lassen kannst, entnehme bitte der Dokumentation von ActiveState. (Schreibe Batchdateien, erweitere den Suchpfad, ...)

Aber vielleicht bin ich auch nur den "Luxus" von PHP-Dateien gewöhnt, sie nicht in cgi-bin-Verzeichnissen abzuspeichern ;-)

Vielleicht läßt sich das aus der Intention der Entwickler der Sprache ableiten, ich zitiere zunächst Larry Wall, den Schöpfer von Perl (ich besitze die deutsche Ausgabe des Kamelbuchs):
"Kurz gesagt, wurde Perl so entworfen, dass es die einfachen Aufgaben einfach macht, ohne die schweren Jobs unmöglich zu machen."

Perl wurde _nicht_ speziell für Webaufgaben entwickelt, eignet sich jedoch hervorragend dafür.

Jetzt der erste Satz von Rasmus Lerdorf, dem Schöpfer von PHP (aus Programming PHP):
"PHP is a simple yet powerful language designed for creating HTML content"

PHP wurde speziell für Webaufgaben entwickelt, eignet sich jedoch auch für allgemeine Aufgaben.

Verstehst Du vielleicht, warum Du gewisse Dinge bei PHP als "Luxus" empfindest und warum Du Dich bei Perl etwas Aufwand (es ist ja nicht viel) treiben musst?

Freundliche Grüsse,

Vinzenz

[WauWau]

Hallo Vinzenz,

Batch-Dateien, oder allgemeiner Shellscripts sind ausführbare Dateien, auch wenn sie einen Interpreter benötigen. Die Ausführbarkeit einer Datei hat weniger damit zu tun, ob es sich um eine Binärdatei oder eine Textdatei handelt. Eine Grafikdatei ist eine Binärdatei, dennoch nicht ausführbar. Ein Shellskript ist eine ASCII-Datei, dennoch ausführbar.

Nunja, gut. Ich habe die Ausführbarkeit einer (text-)Datei eigentlich eher an der Tatsache, ob sie einen Interpreter braucht oder nicht festgemacht. Naja gut, wie dem auch sei - egal ;)

Unter UNIX/Linux musst Du das Ausführbarkeitsflag setzen, unter Windows der Datei die entsprechende Endung verpassen. Du solltest übrigens die Doku von ActivePerl lesen ;-)

Jo, die werde ich mir mal "reinziehen", um es so zu sagen ;)

Die Shebang-Zeile wird nicht für den apache benötigt, sondern für die Shell. Diese muss wissen, an wen sie das Skript schicken soll.

hmmm... die Windows-Shell verwendet afaik keine Shebang-Zeile, oder? Kann ich sie dann weglassen...!?

Auch wieder eine Sache für sich. Unter Linux mag einem ja die Möglichkeit gegönnt sein, diese Attribute (die sich mittels FTP-Clienten auf Dateien ja wunderschön einstellen lassen) einzustellen, doch wenn der Webserver der eigene Computer ist, zudem darauf Windows läuft, dann gibt's da keine weiteren Attribute außer "Archiv", "Schreibgeschützt" und "Versteckt" ;-)

Selbst unter schnödem MS-DOS gab es bereits das Attribut "System"
S steht nicht für "Schreibgeschützt", sondern für "System",
R steht für "Schreibgeschützt" (read only)

Stimmt, ich habe "System" vergessen. Aber immer noch gibt es nicht so viele tolle Flags und Attribute wie bei dem tollen linux,...

Bei NTFS ist alles ein Attribut, selbst der Dateiinhalt.

ach toll.... ;)

Wie Du Perlskripte unter Windows "direkt" ausführen lassen kannst, entnehme bitte der Dokumentation von ActiveState. (Schreibe Batchdateien, erweitere den Suchpfad, ...)

Nö, das geht ganz einfach per "Dateiendung"<=>Zuordnung des Programms, mit dem die Endung geöffnet werden soll.

Vielleicht läßt sich das aus der Intention der Entwickler der Sprache ableiten, ich zitiere zunächst Larry Wall, den Schöpfer von Perl (ich besitze die deutsche Ausgabe des Kamelbuchs):

Kamelbuch?

"Kurz gesagt, wurde Perl so entworfen, dass es die einfachen Aufgaben einfach macht, ohne die schweren Jobs unmöglich zu machen."
Perl wurde _nicht_ speziell für Webaufgaben entwickelt, eignet sich jedoch hervorragend dafür.
Jetzt der erste Satz von Rasmus Lerdorf, dem Schöpfer von PHP (aus Programming PHP):
"PHP is a simple yet powerful language designed for creating HTML content"
PHP wurde speziell für Webaufgaben entwickelt, eignet sich jedoch auch für allgemeine Aufgaben.
Verstehst Du vielleicht, warum Du gewisse Dinge bei PHP als "Luxus" empfindest und warum Du Dich bei Perl etwas Aufwand (es ist ja nicht viel) treiben musst?

jo, das war mir auch vorher klar!? ;)

WauWau

[Vinzenz]

Hallo WauWau,

Wie Du Perlskripte unter Windows "direkt" ausführen lassen kannst, entnehme bitte der Dokumentation von ActiveState. (Schreibe Batchdateien, erweitere den Suchpfad, ...)

Lies bitte die Doku :-)

Nö, das geht ganz einfach per "Dateiendung"<=>Zuordnung des Programms, mit dem die Endung geöffnet werden soll.

Du meinst wohl Dateien, nicht Endungen, die geöffnet werden ;-)
Programme kann man nicht nur durch Klicken starten :-) auch unter Windows.
Programme müssen nicht die Endungen "exe" oder "com" tragen.
Der Kommandozeileninterpreter von Windows-NT-ähnlichen Betriebssystemen reicht zwar nicht an die Mächtigkeit von typischen Linux/Unix-Shells (mein persönlicher Favorit ist bash) heran, wird aber gerne unterschätzt. Kommandozeilenparameter bei Programmen oft sträflichst vernachlässigt.

Kamelbuch?

Eine Erklärung liefert das Archiv, </archiv/2004/3/76275/#m439283>.

jo, das war mir auch vorher klar!? ;)

Es gibt übrigens auch Hoster, bei denen Du PHP-Skripte ebenfalls im cgi-bin-Verzeichnis ablegen musst.

Freundliche Grüsse,

Vinzenz

[WauWau]

Hallo Vinzenz,

Nö, das geht ganz einfach per "Dateiendung"<=>Zuordnung des Programms, mit dem die Endung geöffnet werden soll.

Du meinst wohl Dateien, nicht Endungen, die geöffnet werden ;-)

jo, das wird wohl so sein ;)

Programme kann man nicht nur durch Klicken starten :-) auch unter Windows.
Programme müssen nicht die Endungen "exe" oder "com" tragen.

genau. Und ich will auch keine Programme starten, sondern Dateien mit der endung "pl" mit dem Perl-interpreter (perl.exe) interpretieren lassen und dessen ausgabe auf dem dos-prompt anzeigen. Geht mit php ganz genauso einfach und wird dementsprechend kein problem sein.

Der Kommandozeileninterpreter von Windows-NT-ähnlichen Betriebssystemen reicht zwar nicht an die Mächtigkeit von typischen Linux/Unix-Shells (mein persönlicher Favorit ist bash) heran, wird aber gerne unterschätzt. Kommandozeilenparameter bei Programmen oft sträflichst vernachlässigt.

ich denke, "perl.exe --h" oder -h oder -help oder --help wird mir die nötigen informationen geben.

Kamelbuch?
Eine Erklärung liefert das Archiv, </archiv/2004/3/76275/#m439283>.

ahh. Also sozusagen toller perl-wälzer von bedeutendem autor?

jo, das war mir auch vorher klar!? ;)
Es gibt übrigens auch Hoster, bei denen Du PHP-Skripte ebenfalls im cgi-bin-Verzeichnis ablegen musst.

hmm... jo.

Wauwau

[Eternius]

Hallo,

nun, WauWau hat gestern __endlich__ Mal ActivePerl für Windows runtergeladen (oder war das heute...?).

jeder kommt mal zur Vernunft

datt ding heisst shebang.
leo sacht:
   Unmittelbare Treffer
 shebang     die Bude
 shebang     die Hütte
   Wendungen und Ausdrücke
   the whole shebang     die ganze Chose
   the whole shebang     der ganze Kram

|Dann könnten sie überall liegen. Nur seltsamerweise sieht man sowas heutzutage recht selten. Wieso? Warum? Grund...!?
weil perl eigentlich kein mix aus html und perl ist, so wie man es oft vorfindet.

Ich fände es auf jeden fall extrem ... komisch, wenn ich meine webpräsenzen - (nur) weil sie in Perl geschrieben sind - in cgi-bin-verzeichnissen speichern würde...

ich glaub ich habs eben schon gelesen aber theoretisch kann jedes verzeichnis ein "cgi-bin" sein

Übrigens sind Perl-Dokumente recht unkomportabel, denn dieses schnörkel, auf dessen name ich nicht komme, beschreibt ja den Pfad zu dem Perl.exe-Programm, der ja von System zu System unterschiedlich ist - obwohl es bei Linux da höchstwahrscheinlich überall gleich ist...

sollte zumindest ;-)
warum das ganze? linux ist nicht so dämlich und klassifiziert eine datei anhand ihrer endung. wenn in einer shell eine datei aufgerufen wird, dann guckt linux ob die datei ausführrechte hat, wenn ja, wird geguckt, ob es ein executable ist (gibt 3 verschiedene, je nachdem was der kernel kann) oder wenn nicht, ob es ein skript ist. damit linux dann weiss, um was für ein skript es sich handelt gibt es den shebang. ist aber eigentlich kein problem. wenn du dateien von einem zum anderen lin sys portierst, wo perl woanders liegt, kannst du theoretisch einfach einen symlink auf den im shebang angegebenen pfad erstellen und fertig.

nur so lästige Gui's wie KDE etc fangen auch an teilweise dateien nach ihrer endung zu klassifizieren.

gruss

[Eternius]

argh

weil perl eigentlich kein mix aus html und perl ist, so wie man es oft vorfindet.

so wie mann es oft bei php findet

[Christoph Schnauß]

hrm ...

weil perl eigentlich kein mix aus html und perl ist, so wie man es oft vorfindet.
so wie mann es oft bei php findet

Nö. PHP ist PHP, genauso wie PERL eben PERL ist. Übrigens waren die allerersten PHP-Scripte von Rasmus L. klassisches PERL (daher kommt die Verwandtscahft der beiden Sprachen).

Der Unterschied zwischen PERL und PHP besteht darin, daß beide HTML-Code erzeugen können (aber nicht müssen), und beide auch in HTML eingebettet werden können (aber nicht müssen).

So, jetzt darfst du über dieses Paradoxon nachdenken und dich vielleicht ein bißchen bei Originalquellen belesen.

Grüße aus Berlin

Christoph S.

[WauWau]

Hallo Christoph,

Nö. PHP ist PHP, genauso wie PERL eben PERL ist. Übrigens waren die allerersten PHP-Scripte von Rasmus L. klassisches PERL (daher kommt die Verwandtscahft der beiden Sprachen).

hmmm... also ist PHP nur ein modifiziertes Perl mit einer anderen engine und einem bisschen anderen zeugs ;) ?

Der Unterschied zwischen PERL und PHP besteht darin, daß beide HTML-Code erzeugen können (aber nicht müssen), und beide auch in HTML eingebettet werden können (aber nicht müssen).

<?php
  // PHP-Code
?>

und Perl? Mir fällt momentan nur ActivePerl als Script-Sprache unter windows ein... geht dann irgendwie so mit ASP...

<%
 # Perl-CODE
%>

WauWau

[Matti Maekitalo]

use Mosche;

und Perl? Mir fällt momentan nur ActivePerl als Script-Sprache unter windows ein... geht dann irgendwie so mit ASP...

<%
 # Perl-CODE
%>

Wie anderswo gesagt:
embPerl oder HTML::Mason
[pref:t=78692&m=455443]

use Tschoe qw(Matti);

[WauWau]

Hallo Matti,

und Perl? Mir fällt momentan nur ActivePerl als Script-Sprache unter windows ein... geht dann irgendwie so mit ASP...

<%
 # Perl-CODE
%>

Wie anderswo gesagt:
embPerl oder HTML::Mason
[pref:t=78692&m=455443]

hmm... embPerl sieht komisch aus...

[! Perl-Code !]

... und bei HTML::Mason habe ich dementsprechend nix gefunden.

Na dann ... bleibe ich bei meinem einfachen schönen perl. Und damit werde ich jetzt auch gleich anfangen. So, viel spaß noch,

WauWau

[WauWau]

Hallo Eternius,

nun, WauWau hat gestern __endlich__ Mal ActivePerl für Windows runtergeladen (oder war das heute...?).
jeder kommt mal zur Vernunft

Hmm, ich habe Perl jetzt zwar noch nicht "richtig" ausprobiert, würde aber sagen, dass es in Punkto Einsetzung in Webprogrammierung keineswegs besser als PHP ist.

datt ding heisst shebang.
leo sacht:
   Unmittelbare Treffer
 shebang     die Bude
 shebang     die Hütte
   Wendungen und Ausdrücke
   the whole shebang     die ganze Chose
   the whole shebang     der ganze Kram

und was soll ich aus dem von leo gesagtem nun ziehen?

|...

Cool, endlich jemand, der diese anderen Quotationzeichen benutzt ;)
Hmm, also es scheint ja so, als ob die genauso in normale Zitate umgesetzt werden. Wie ist das beim posting-angezeigt-bekommen: Siehst du dann auch diese komischen Striche, oder dann die "originalen" »» ?

weil perl eigentlich kein mix aus html und perl ist, so wie man es oft vorfindet.

da ziehe ich dann mal die "verbesserte Version" aus [pref:t=78672&m=455152] zu rate...:

so wie mann es oft bei php findet

Hmm, man findet es eigentlich nicht "nur" oft bei PHP vor ;)
Übrigens macht dasda:

weil perl eigentlich kein mix aus html und perl ist, so wie mann es oft bei php findet

auf dasda:

Dann könnten sie überall liegen. Nur seltsamerweise sieht man sowas heutzutage recht selten. Wieso? Warum? Grund...!?

keinen richtigen sinn ;)

nur so lästige Gui's wie KDE etc fangen auch an teilweise dateien nach ihrer endung zu klassifizieren.

Du scheinst ein "richtiger" Linux-Benutzer zu sein ;-) Gui's sind böse und allgemein gefährlich, die Konsole ist alles *g*

Na gut, Linux ist echt "besser", aber wenn ich es mir mal recht überlege... würde ich hier neben meinem win2k noch linux draufmachen, dann würde ich ohne zu zögern noch den apachen, php, mysql und andere solche sachen draufpacken, und das würde dann entgültig den Rahmen des erdenkbaren sprengen. WauWau ist nämlich "nur" mit einem 256MB-RAM, 667MHZ-Rechner von.... 98 oder 99 oder so ausgerüstet, und der Apache mit PHP als API (etwa 20MB RAM-Verbrauch im Leerlauf) sowie MySQL (nochmals etwa 20MB RAM-Verbauch im Leerlauf! Ich überlege ernsthaft, ob ich nicht zu ODBC wechsle...) zerren schon arg am RAM :.... 8[[

WauWau

[Eternius]

gude,

Hmm, ich habe Perl jetzt zwar noch nicht "richtig" ausprobiert, würde aber sagen, dass es in Punkto Einsetzung in Webprogrammierung keineswegs besser als PHP ist.

hmm, php ist halt fürs web gemacht (worden), heisst ja auch People Hate Perl ;-)

und was soll ich aus dem von leo gesagtem nun ziehen?

das war eine ergänzung zu [pref:t=78672&m=455100]

Cool, endlich jemand, der diese anderen Quotationzeichen benutzt ;)
Hmm, also es scheint ja so, als ob die genauso in normale Zitate

umgesetzt werden. Wie ist das beim posting-angezeigt-bekommen: Siehst du dann auch diese komischen Striche, oder dann die "originalen" »» ?
ich seh eigentlich nur |, weil es sonst ja auch keinen sinn machen würde, hab aber noch nicht wirklich drauf geachtet.

Du scheinst ein "richtiger" Linux-Benutzer zu sein ;-) Gui's sind böse und allgemein gefährlich, die Konsole ist alles *g*

nein, jedes betriebssystem hat seine stärken und schwächen (genauso wie meine rechtschreibung).
da ich mir keine Sun für daheim leisten kann, muss halt n alter celeron 640 als server herhalten mit linux. die workstations haben aber alle win und linux, wobei win am meisten benutzt wird.

Na gut, Linux ist echt "besser", aber wenn ich es mir mal recht

s.o. ;-)

gruss

[WauWau]

Hallo Eternius,

hmm, php ist halt fürs web gemacht (worden), heisst ja auch People Hate Perl ;-)

Ach, so würde ich das nicht sehen. ICh wollte heute abend/nacht noch Perl auf meinem apachen "einrichten" und ein kleines template-proggi + mod_rewrite für eine kleine präsenz einrichten. Dürfte nicht so ein problem sein, und ich wollte schon immer mal _endlich_ Perl schreiben :))

und was soll ich aus dem von leo gesagtem nun ziehen?
das war eine ergänzung zu [pref:t=78672&m=455100]

aja, klar.

ich seh eigentlich nur |, weil es sonst ja auch keinen sinn machen würde, hab aber noch nicht wirklich drauf geachtet.

Hmm... ich habe nämlich überlegt, ob ich als quotationzeichen ">" einstelle (ist soviel leichter einzutippen als »»), aber ich will nicht auf die schönen »» als anzeige verzichten.

Du scheinst ein "richtiger" Linux-Benutzer zu sein ;-) Gui's sind böse und allgemein gefährlich, die Konsole ist alles *g*
nein, jedes betriebssystem hat seine stärken und schwächen (genauso wie meine rechtschreibung).
da ich mir keine Sun für daheim leisten kann, muss halt n alter celeron 640 als server herhalten mit linux. die workstations haben aber alle win und linux, wobei win am meisten benutzt wird.

aja. klar ;)

WauWAu

[Matti Maekitalo]

use Mosche;

ich seh eigentlich nur |, weil es sonst ja auch keinen sinn machen würde, hab aber noch nicht wirklich drauf geachtet.

Hmm... ich habe nämlich überlegt, ob ich als quotationzeichen ">" einstelle (ist soviel leichter einzutippen als »»), aber ich will nicht auf die schönen »» als anzeige verzichten.

Da musst du dich entscheiden. Das Zitatzeichen, welches du dir aussuchst, wird von Forum wiederum in ein Meta-Zeichen umgewandelt, allerdings nur _dein_ Zitatzeichen. D.h., wenn du als Zitatzeichen '»»' benutzt, wird auch nur '»»' wieder richtig umgewandelt, während "Zitate" mit '>', '|' oder so dann nicht mehr so schön erkennbar sind.

use Tschoe qw(Matti);

[WauWau]

hola,

ich seh eigentlich nur |, weil es sonst ja auch keinen sinn machen würde, hab aber noch nicht wirklich drauf geachtet.

Hmm... ich habe nämlich überlegt, ob ich als quotationzeichen ">" einstelle (ist soviel leichter einzutippen als »»), aber ich will nicht auf die schönen »» als anzeige verzichten.

Da musst du dich entscheiden. Das Zitatzeichen, welches du dir aussuchst, wird von Forum wiederum in ein Meta-Zeichen umgewandelt, allerdings nur _dein_ Zitatzeichen. D.h., wenn du als Zitatzeichen '»»' benutzt, wird auch nur '»»' wieder richtig umgewandelt, während "Zitate" mit '>', '|' oder so dann nicht mehr so schön erkennbar sind.

ich glaube, ich lass es einfach, und basta ;) immerhin konnte ich bis jetzt ganz gut damit leben :)

WauWau

[Christoph Schnauß]

morgens,

weil perl eigentlich kein mix aus html und perl ist, so wie man es oft vorfindet.

Oh, was ist denn das für eine Aussage, und wo findet man das "oft"? PERL ist PERL und sonst gar nix.

ich glaub ich habs eben schon gelesen aber theoretisch kann jedes verzeichnis ein "cgi-bin" sein

Das ist richtig.

nur so lästige Gui's wie KDE etc fangen auch an teilweise dateien nach ihrer endung zu klassifizieren.

Ich halte KDE keineswegs für "lästig". Und ganz ohne GUI kommst du auch auf einer LINUX-Kiste nicht aus  -  Anwendungen wie mozilla funktionieren ohne grafische Oberfläche nicht. Auf der Konsole hast du im Grunde genommen nur LYNX. Der ist für schnelle Orientierung und das Lesen von Textinhalten hervorragend geeignet, macht dir aber bereits Probleme, wenn du damit hier im Forum etwas schreiben möchtest. Zum Nachweis bitte im Forumsarchiv recherchieren, wir hatten auch dieses Thema schon mehrfach.

Christoph S.

[Eternius]

fast abends,

Oh, was ist denn das für eine Aussage, und wo findet man das "oft"? PERL ist PERL und sonst gar nix.

argh:
[quote]
What's the difference between "perl" and "Perl"?

One bit. Oh, you weren't talking ASCII? :-) Larry now uses "Perl" to signify the language proper and "perl" the implementation of it, i.e. the current interpreter. Hence Tom's quip that "Nothing but perl can parse Perl." You may or may not choose to follow this usage. For example, parallelism means "awk and perl" and "Python and Perl" look OK, while "awk and Perl" and "Python and perl" do not. But never write "PERL", because perl is not an acronym, apocryphal folklore and post-facto expansions notwithstanding.
[/quote]

Ich halte KDE keineswegs für "lästig". Und ganz ohne GUI kommst du auch auf einer LINUX-Kiste nicht aus  -

jaja weiss ich auch, kommt halt nur drauf an was du machen willst.
meine "arbeitstiere" (server) benutzen linux, der rest ist windows.

gruss

[WauWau]

Nun abends,

Oh, was ist denn das für eine Aussage, und wo findet man das "oft"? PERL ist PERL und sonst gar nix.
argh:
[quote]
What's the difference between "perl" and "Perl"?

One bit. Oh, you weren't talking ASCII? :-) Larry now uses "Perl" to signify the language proper and "perl" the implementation of it, i.e. the current interpreter. Hence Tom's quip that "Nothing but perl can parse Perl." You may or may not choose to follow this usage. For example, parallelism means "awk and perl" and "Python and Perl" look OK, while "awk and Perl" and "Python and perl" do not. But never write "PERL", because perl is not an acronym, apocryphal folklore and post-facto expansions notwithstanding.
[/quote]

hä... was ist jetzt der Unterschied zwischen Perl und perl?

Ich halte KDE keineswegs für "lästig". Und ganz ohne GUI kommst du auch auf einer LINUX-Kiste nicht aus  -
jaja weiss ich auch, kommt halt nur drauf an was du machen willst.
meine "arbeitstiere" (server) benutzen linux, der rest ist windows.

... immer diese reichen leute hier mit ihren zig servern....
ich will mir erst gar nicht vorstellen, wie eure umgebung ist... 10 Comps stehen da bestimmt rum, 2 funkelnagelneue mit win2k, an jedem 4 Bildschirme drangeschlossen, und hinten stehen noch 4 pc's mit Linux und FreeBSD und dem ganzen zeugs (LAMPP, DNS-Server, DHCP und sowas... <g>), und dann noch 2 mac's... osX versteht sich...

Ich bin nur der arme wauwau, der _einen_ kleinen, aber feinen win2k-rechner hat 8[  ... ;-)

WauWau

[Matti Maekitalo]

use Mosche;

Larry now uses "Perl" to signify the language proper and "perl" the implementation of it, i.e. the current interpreter.

hä... was ist jetzt der Unterschied zwischen Perl und perl?

Perl ist eine Sprache, so wie Deutsch. perl ist ein Interpreter, zB also jemand, der deutsch versteht bzw. spricht.

use Tschoe qw(Matti);

[WauWau]

Hallo Matti,

Larry now uses "Perl" to signify the language proper and "perl" the implementation of it, i.e. the current interpreter.

hä... was ist jetzt der Unterschied zwischen Perl und perl?

Perl ist eine Sprache, so wie Deutsch. perl ist ein Interpreter, zB also jemand, der deutsch versteht bzw. spricht.

unglaublich.... genau das habe ich mir gedacht!

WauWau