Welche Sonderzeichen in textareas escapen?

[csx]

Hallo alle!

Ich hab ein script in Perl mit dem ich online Dateien (HTML, TXT, PM, PL, CGI, PHP, CONF, etc) bearbeite (um die Seiten nicht immer runterladen, editieren und wieder raufladen zu müssen. (Bitte erzählt mir jetzt nicht irgentwas von "editieren sollte man nicht direkt auf dem Live-System etc. - Danke!)

Also, mein script lädt also eine Datei und stellt sie ($pg) dann über HTML in einer textarea dar:

&Add("<textarea onChange='hasChanged = 1;' name='data' id='edit-textarea' wrap='off'>$pg</textarea>");

Problem ist klar: Ich muß bestimmte Zeichen vorher escapen, mindestens darf die Zeichenfolge "</textarea>" nicht im Ausgabestring ($pg) vorkommen. Also:

$pg=~s/</&#x003C;/g;
$pg=~s/>/&#x003E;/g;

Ich möchte aber auch Perl-Scripts editieren können, auch das Script des Editors selbst! Würde ich es so ausgeben, dann würde ja &#x003C in ein "<"-Zeichen umgewandelt werden. Also muß cih auch Hashes escapen:

$pg=~s/&/&#x0026;/g;
$pg=~s/</&#x003C;/g;
$pg=~s/>/&#x003E;/g;

Nach dem submitted der textarea müssen die escapten Werte wieder zurückgewandelt werden

$in{'data'} =~ s/&#x003C;/</g;
$in{'data'} =~ s/&#x003E;/>/g;
$in{'data'} =~ s/&#x0026;/&/g;

Bevor der String in die zuvor "gebackupte" Datei geschrieben wird.

Frage: Hab ich beim escapen der Werte noch irgentwas übersehen? Ich möchte jede mögliche (Text-)datei in die textarea laden können, ohne das sich nach dem submit irgentein Buchstabe oder Sonderzeichen ändern würde.

Danke für Tipps!
csx

[Cheatah]

Hi,

$pg=~s/&/&#x0026;/g;
$pg=~s/</&#x003C;/g;
$pg=~s/>/&#x003E;/g;

ja. Definierte Entities wie & würden es allerdings auch tun.

Nach dem submitted der textarea müssen die escapten Werte wieder zurückgewandelt werden

Nein. Nach dem Parsen des gelieferten HTML-Codes durch den Client sind keine Entities mehr vorhanden - und wenn doch, wurden sie als solche eingegeben und müssen ergo bleiben.

$in{'data'} =~ s/&#x003C;/</g;

%in? Hast Du das aus CGI::param erzeugt? Wenn ja, warum? Wenn nein, warum nicht?

Frage: Hab ich beim escapen der Werte noch irgentwas übersehen?

Das Content-Modell von <textarea> enthält PCDATA. Das bedeutet, HTML-spezifische Zeichen müssen escaped werden, inklusive des Escape-Zeichens "&" selbst. Theoretisch reichen also "&" und "<" - es ist allerdings alles andere als falsch (um nicht zu sagen, um vieles besser), einfach HTML::Entities einzusetzen. Dadurch entfällt dann auch die Beschränkung auf Text-Dateien.

Cheatah

[csx]

Hi

ja. Definierte Entities wie & würden es allerdings auch tun.

Das ist eigentlich egal.

Nein. Nach dem Parsen des gelieferten HTML-Codes durch den Client sind keine Entities mehr vorhanden - und wenn doch, wurden sie als solche eingegeben und müssen ergo bleiben.

Ack. Da hast du wohl Recht.

%in? Hast Du das aus CGI::param erzeugt? Wenn ja, warum? Wenn nein, warum nicht?

Nein, ist eine eigene Routine die ich immer benutze. Soweit es geht versuche ich Module zu vermeiden, damit ich nicht so sehr von der lokalen Installation abhängig bin.

Das Content-Modell von <textarea> enthält PCDATA. Das bedeutet, HTML-spezifische Zeichen müssen escaped werden, inklusive des Escape-Zeichens "&" selbst. Theoretisch reichen also "&" und "<" - es ist allerdings alles andere als falsch (um nicht zu sagen, um vieles besser), einfach HTML::Entities einzusetzen. Dadurch entfällt dann auch die Beschränkung auf Text-Dateien.

Naja, da ich eh nicht vorhabe "Binärdateien" in einem Texteditor zu bearbeiten, ist das eigentlich recht egal. Ich werd mit HTML::Entities trotzdem mal angucken. Obwohl ich eigentlich ganz gern auf Module verzichten würde...

Danke Dir!
csx

[Cheatah]

Hi,

ja. Definierte Entities wie & würden es allerdings auch tun.
Das ist eigentlich egal.

ja.

%in? Hast Du das aus CGI::param erzeugt? Wenn ja, warum? Wenn nein, warum nicht?
Nein, ist eine eigene Routine die ich immer benutze.

Das solltest Du _dringend_ ändern.

Soweit es geht versuche ich Module zu vermeiden, damit ich nicht so sehr von der lokalen Installation abhängig bin.

Was?! Du hast das grundlegende Prinzip von Perl nicht verstanden. Benutze _unbedingt_ Perl-Module, sofern es für die benötigten Aufgaben solche gibt. Du sparst Dir damit eine Menge Scherereien - beispielsweise wäre Dein aktuelles Problem nicht aufgetreten. Zudem ist CGI.pm ein Standardmodul.

[...] HTML::Entities einzusetzen. Dadurch entfällt dann auch die Beschränkung auf Text-Dateien.

Naja, da ich eh nicht vorhabe "Binärdateien" in einem Texteditor zu bearbeiten, ist das eigentlich recht egal.

Ja, das ist auch nur ein Nebeneffekt.

Cheatah

[csx]

Hi!

Nein, ist eine eigene Routine die ich immer benutze.
Das solltest Du _dringend_ ändern.

Warum? Sicherheitsbedenken? Nur welche? Eingaben werden eh nie ohne nochmalige Prüfung an Systembefehle übergeben.

Was?! Du hast das grundlegende Prinzip von Perl nicht verstanden. Benutze _unbedingt_ Perl-Module, sofern es für die benötigten Aufgaben solche gibt. Du sparst Dir damit eine Menge Scherereien - beispielsweise wäre Dein aktuelles Problem nicht aufgetreten. Zudem ist CGI.pm ein Standardmodul.

Es läuft ja, nur man muß eben selbst nachdenken statt sich darauf zu verlassen, daß andere richtig nachgedacht haben als sie das jeweilige Modul geschrieben haben. Den GET oder POST-String zu parsen ist ja nix wirklich schwieriges. Ok, wenn ich eine Datei hochladen will, dann ist CGI.pm wohl einfacher, aber sonst seh ich da keinen großen Vorteil. Das mag auch daran liegen, daß ich CGI.pm kaum benutze...

Gruß
csx

[Struppi]

Was?! Du hast das grundlegende Prinzip von Perl nicht verstanden. Benutze _unbedingt_ Perl-Module, sofern es für die benötigten Aufgaben solche gibt. Du sparst Dir damit eine Menge Scherereien - beispielsweise wäre Dein aktuelles Problem nicht aufgetreten. Zudem ist CGI.pm ein Standardmodul.

Es läuft ja, nur man muß eben selbst nachdenken statt sich darauf zu verlassen, daß andere richtig nachgedacht haben als sie das jeweilige Modul geschrieben haben. Den GET oder POST-String zu parsen ist ja nix wirklich schwieriges. Ok, wenn ich eine Datei hochladen will, dann ist CGI.pm wohl einfacher, aber sonst seh ich da keinen großen Vorteil. Das mag auch daran liegen, daß ich CGI.pm kaum benutze...

Nein, du verläßt dich darauf, das beim nachdenken eines einzelnen mehr oder wenigstens halbwegs das gleiche rauskommt, wie bei der Entwicklung mit hilfe Millionen von Benutzer (das CGI Modul hat ja schon ein paar Jahre auf dem Buckel).

Darüber hinaus ist das Modul zumindest in meines Augen eben nicht in erster Linie für das parsen der eingehenden Daten da, sondern es lohnt sich vor allem für die Ausgabe, da es sehr praktische Routinen für das erzeugen von Formularen und Tabellen hat, die deinen Code wesentlich übersichtlicher und perliger machen.

Das verzichten wollen auf Module ist eher so eine Marotte von Anfängern, die noch lernen wollen und Angst haben dass sie nichts lernen, wenn sie Module benutzen. Aber es gibt kaum eine programmiersprache wo Module/Libaries nicht üblich sind.

2 cent.

struppi.

[csx]

Hi

Das verzichten wollen auf Module ist eher so eine Marotte von Anfängern, die noch lernen wollen und Angst haben dass sie nichts lernen, wenn sie Module benutzen. Aber es gibt kaum eine programmiersprache wo Module/Libaries nicht üblich sind.

Puh! Um dir mal ein Bsp zu nennen: In Perl hab ich mein eigenes Modul, um Sessions zu verwalten und durch den Aufruf von nur 3 subs relativ schnell und sauber Login/LOgout-Status eines Benutzes zu verwalten. Dann hab ich mal wa in PHP versucht und bin beim Session-Handling stecken geblieben. Nach stundenlanger suche und einer Kompletten Neuinstallation von PHP (update auf eine aktellere Version) funktionierte es dann endlich. Auf meinem Server läuft es immer noch nicht, weil da nicht die richtige 4.1.x drauf ist. Klasse! Hätte ich das Session-Handling selbst geschrieben, wäre ich 3x schneller fertig gewesen.

Nochmal: Module find ich gut, da sie zum Teil Zeit sparen und den Programmierprozess beschleunigen. Wenn man aber weis, das ein bestimmtes Script in der Zukunft auf vielen verschiedenen Plattformen laufen soll, dann sollte man soweit wie möglich auf Module verzichten, da sie nur zu unnötigen Inkompatibilitäten führen.

Ich lehne Module nicht rigoros ab, aber ich bin auch nicht jemand, der für alles und jedes erstmal ein Modul braucht. Was ist so schlimm daran, print"Content-type: bla/bla\n\n"; zu schreiben? Warum sollte ich das über ein Modul machen? Damit mein script auch ja nur dort läuft, wo das entsprechende Modul installiert ist?

Gruß
csx

[Struppi]

Puh! Um dir mal ein Bsp zu nennen: In Perl hab ich mein eigenes Modul, um Sessions zu verwalten und durch den Aufruf von nur 3 subs relativ schnell und sauber Login/LOgout-Status eines Benutzes zu verwalten. Dann hab ich mal wa in PHP versucht und bin beim Session-Handling stecken geblieben. Nach stundenlanger suche und einer Kompletten Neuinstallation von PHP (update auf eine aktellere Version) funktionierte es dann endlich. Auf meinem Server läuft es immer noch nicht, weil da nicht die richtige 4.1.x drauf ist. Klasse! Hätte ich das Session-Handling selbst geschrieben, wäre ich 3x schneller fertig gewesen.

PHP ist ja auch ein bisschen neuer insofern sind die entwicklungsschritte evtl. größer als bei Perl.

Ich lehne Module nicht rigoros ab, aber ich bin auch nicht jemand, der für alles und jedes erstmal ein Modul braucht. Was ist so schlimm daran, print"Content-type: bla/bla\n\n"; zu schreiben? Warum sollte ich das über ein Modul machen? Damit mein script auch ja nur dort läuft, wo das entsprechende Modul installiert ist?

Es gibt ein Haufen standardmodule, die bei jeder Perl Version dabei sind.

Natürlich kommt es auf den Umfang an den man braucht. Aber bei aus deienem Codeschnipsel läßt sich erahnen, das das benutzen von CGI.pm ratsam wäre.

Struppi.

[Cheatah]

Hi,

Puh! Um dir mal ein Bsp zu nennen: In Perl hab ich mein eigenes Modul, um Sessions zu verwalten und durch den Aufruf von nur 3 subs relativ schnell und sauber Login/LOgout-Status eines Benutzes zu verwalten. Dann hab ich mal wa in PHP versucht und bin beim Session-Handling stecken geblieben. Nach stundenlanger suche und einer Kompletten Neuinstallation von PHP (update auf eine aktellere Version) funktionierte es dann endlich. Auf meinem Server läuft es immer noch nicht, weil da nicht die richtige 4.1.x drauf ist. Klasse! Hätte ich das Session-Handling selbst geschrieben, wäre ich 3x schneller fertig gewesen.

und was hat PHP bzw. eine fehlende Behandlung eventueller Abhängigkeiten mit Perl und dessen Modulen zu tun?

Nochmal: Module find ich gut, da sie zum Teil Zeit sparen und den Programmierprozess beschleunigen.

Das ist nur einer der Vorteile von Modulen.

Wenn man aber weis, das ein bestimmtes Script in der Zukunft auf vielen verschiedenen Plattformen laufen soll, dann sollte man soweit wie möglich auf Module verzichten, da sie nur zu unnötigen Inkompatibilitäten führen.

Nein, nein und nochmals nein. Die Abhängigkeit ist zu behandeln; bei Perl etwa durch einen Fehler beim Precompiling.

Ich lehne Module nicht rigoros ab, aber ich bin auch nicht jemand, der für alles und jedes erstmal ein Modul braucht.

Die meisten Perl-Programmierer haben so angefangen. Oder anders gesagt: Daran erkennt man einen Anfänger.

Was ist so schlimm daran, print"Content-type: bla/bla\n\n"; zu schreiben?

Was ist, wenn HTTP/1.2 oder HTTP/2.0 mehr als nur das benötigt? Willst Du _alle_ Deine Scripts anpassen, oder einmalig CGI.pm aktualisieren?

Übrigens verlangt HTTP schon jetzt CRLF, nicht nur LF. Mit CGI.pm wäre das nicht passiert.

Warum sollte ich das über ein Modul machen?

Ich denke, das sollte jetzt klar sein.

Damit mein script auch ja nur dort läuft, wo das entsprechende Modul installiert ist?

Bei einem Modul, das in zehn Jahren drei mal installiert wurde, könnte ich diese Argumentation verstehen - wenn auch nicht akzeptieren. Aber bei _Standard_modulen?

Cheatah

[csx]

Hi

und was hat PHP bzw. eine fehlende Behandlung eventueller Abhängigkeiten mit Perl und dessen Modulen zu tun?

Das lokal eine falsche Version installiert war, und deswegen das Script nicht so lief wie es sollte. Ergo: Ich bin abhängig davon, das bestimmte Module/Versionen richtig installiert sind. Richtig?

Wenn man aber weis, das ein bestimmtes Script in der Zukunft auf vielen verschiedenen Plattformen laufen soll, dann sollte man soweit wie möglich auf Module verzichten, da sie nur zu unnötigen Inkompatibilitäten führen.

Nein, nein und nochmals nein. Die Abhängigkeit ist zu behandeln; bei Perl etwa durch einen Fehler beim Precompiling.

Perl ist üblicherweise eine Interpretersprache. Wenn du noch nicht weist, auf welchen Systemen dein Script später mal installiert ist, und auf die Installationsverzeichnisse keinen zugriff hast, dann ist das etwas schiwierig, oder?

Ich lehne Module nicht rigoros ab, aber ich bin auch nicht jemand, der für alles und jedes erstmal ein Modul braucht.

Die meisten Perl-Programmierer haben so angefangen. Oder anders gesagt: Daran erkennt man einen Anfänger.

Du hast ja durchaus Ahnung von der Materie, Cheatah. Aber was mich wirklich nervt ist deine Art. Wenn jemand es nicht genauso macht wie du, dann ist es schon mal falsch. Ich habe eine völlig andere Frage gestellt, und du fängst an mich voll zu labern und mir zu erzählen ich wäre ein Anfänger, nur weil ich meine scripts möglichst wenig von lokal installierten Erweiterungen abhängig machen möchte. Das gleiche Verhalten ist mir bei dir leider schon des öffteren Aufgefallen. Ich sage "leider", weil du andererseits fachlich durchaus was drauf hast. Echt schade.

Was ist, wenn HTTP/1.2 oder HTTP/2.0 mehr als nur das benötigt? Willst Du _alle_ Deine Scripts anpassen, oder einmalig CGI.pm aktualisieren?
Übrigens verlangt HTTP schon jetzt CRLF, nicht nur LF. Mit CGI.pm wäre das nicht passiert.

Du, es gibt Unix-Befehle aus den 70er Jahren, die immer noch kompatibel mit ihren heutigen implementationen sind. Meinst du im ernst, das HTTP/2 nicht abwärtskompatibel sein wird?

Es nützt mir herzlich wenig zu wissen, das mein script (dank CGI-pm) auch in 30 Jahren auf HTTP/36.0 noch lauffähig ist, wenn ich bei jeder 2. Installation erstmal 20 Module nachinstallieren oder updaten muß, falls ich überhaupt root haben sollte auf dem entsprechenden System...

Warum sollte ich das über ein Modul machen?
Ich denke, das sollte jetzt klar sein.

Nö.

Bei einem Modul, das in zehn Jahren drei mal installiert wurde, könnte ich diese Argumentation verstehen - wenn auch nicht akzeptieren. Aber bei _Standard_modulen?

Also Cheatah, du machst es auf deine Weise, ich auf meine. Ok?

Tschüß
csx

[Cheatah]

Hi,

und was hat PHP bzw. eine fehlende Behandlung eventueller Abhängigkeiten mit Perl und dessen Modulen zu tun?
Das lokal eine falsche Version installiert war, und deswegen das Script nicht so lief wie es sollte. Ergo: Ich bin abhängig davon, das bestimmte Module/Versionen richtig installiert sind. Richtig?

sofern Du Dich immer noch auf Perl beziehst: nein. Bei PHP mag es eine kranke Versionsproblematik geben; bei Perl wird Dir allenfalls gesagt, dass ein bestimmtes Modul nicht oder nicht neu genug vorliegt, welches dann halt installiert wird.

Nein, nein und nochmals nein. Die Abhängigkeit ist zu behandeln; bei Perl etwa durch einen Fehler beim Precompiling.
Perl ist üblicherweise eine Interpretersprache. Wenn du noch nicht weist, auf welchen Systemen dein Script später mal installiert ist, und auf die Installationsverzeichnisse keinen zugriff hast, dann ist das etwas schiwierig, oder?

Nein. Siehe

perldoc perlmodinstall

Die meisten Perl-Programmierer haben so angefangen. Oder anders gesagt: Daran erkennt man einen Anfänger.
Du hast ja durchaus Ahnung von der Materie, Cheatah. Aber was mich wirklich nervt ist deine Art.

Siehe Archiv.

Wenn jemand es nicht genauso macht wie du, dann ist es schon mal falsch.

Nein.

Ich habe eine völlig andere Frage gestellt, und du fängst an mich voll zu labern und mir zu erzählen ich wäre ein Anfänger, nur weil ich meine scripts möglichst wenig von lokal installierten Erweiterungen abhängig machen möchte.

Nein. Weil Du auf den Einsatz von Modulen - und zwar insbesondere von Standardmodulen - verzichtest.

Das gleiche Verhalten ist mir bei dir leider schon des öffteren Aufgefallen.

Siehe Archiv.

Was ist, wenn HTTP/1.2 oder HTTP/2.0 mehr als nur das benötigt? Willst Du _alle_ Deine Scripts anpassen, oder einmalig CGI.pm aktualisieren?
Übrigens verlangt HTTP schon jetzt CRLF, nicht nur LF. Mit CGI.pm wäre das nicht passiert.
Du, es gibt Unix-Befehle aus den 70er Jahren, die immer noch kompatibel mit ihren heutigen implementationen sind. Meinst du im ernst, das HTTP/2 nicht abwärtskompatibel sein wird?

Natürlich wird es das. Du kennst die Unterschiede zwischen HTTP/1.0 und HTTP/1.1? Unabhängig davon ist der von Dir eingesetzte Umbruch aber schon bei HTTP/0.9 falsch gewesen, und auch bei HTTP/2.0 ist nicht abzusehen, dass sich daran etwas ändern wird.

Es nützt mir herzlich wenig zu wissen, das mein script (dank CGI-pm) auch in 30 Jahren auf HTTP/36.0 noch lauffähig ist, wenn ich bei jeder 2. Installation erstmal 20 Module nachinstallieren oder updaten muß, falls ich überhaupt root haben sollte auf dem entsprechenden System...

Ich weiß nicht, ob Du gerade nur in Rage hoffnungslos übertrieben hast; aber Du wirst eher alle paar Jahre mit der Aktualisierung _eines_ Moduls zu "kämpfen" haben.

Warum sollte ich das über ein Modul machen?
Ich denke, das sollte jetzt klar sein.
Nö.

Schade. Dann deutlicher:

Dein Code ist defekt. Unter Verwendung des Standardmoduls CGI.pm wäre er das nicht; weder jetzt noch in Zukunft, selbst wenn sich die Standards beliebig verändern.

Bei einem Modul, das in zehn Jahren drei mal installiert wurde, könnte ich diese Argumentation verstehen - wenn auch nicht akzeptieren. Aber bei _Standard_modulen?
Also Cheatah, du machst es auf deine Weise, ich auf meine. Ok?

Möchtest Du damit sagen, dass Du Argumenten, langjähriger Praxiserfahrung und bewusster Adaption internationaler und professioneller Styleguides gegenüber nicht aufgeschlossen bist, sondern statt dessen lieber ein eigenes Süppchen kochst, dass außer Dir kein Mensch konsumieren möchte?

Cheatah

[csx]

hi

sofern Du Dich immer noch auf Perl beziehst: nein. Bei PHP mag es eine kranke Versionsproblematik geben; bei Perl wird Dir allenfalls gesagt, dass ein bestimmtes Modul nicht oder nicht neu genug vorliegt, welches dann halt installiert wird.

Sofern du die nötigen Rechte hast...

perldoc perlmodinstall

Du bist ja echt süß. Meinst du ich weis nicht, wie man Module installiert? Nur weil ich sie möglichst nicht benutze... (bitte richte deine Aufmerksamkeit vor allem auf die Vokabel "möglichst")

Cheatah [...] was mich wirklich nervt ist deine Art.

Siehe Archiv.

Genau.

Nein. Weil Du auf den Einsatz von Modulen - und zwar insbesondere von Standardmodulen - verzichtest.

Wie gesagt, ich hab schon viele Systeme (vor allem Windows-Versionen) gesehen, wo die nicht vorhanden waren.

Was ist, wenn HTTP/1.2 oder HTTP/2.0 mehr als nur das benötigt? Willst Du _alle_ Deine Scripts anpassen, oder einmalig CGI.pm aktualisieren?

Wie gestagt:

Du, es gibt Unix-Befehle aus den 70er Jahren, die immer noch kompatibel mit ihren heutigen implementationen sind. Meinst du im ernst, das HTTP/2 nicht abwärtskompatibel sein wird?

Nochmal: Meinst du das im Ernst?

Möchtest Du damit sagen, dass Du Argumenten, langjähriger Praxiserfahrung und bewusster Adaption internationaler und professioneller Styleguides gegenüber nicht aufgeschlossen bist, sondern statt dessen lieber ein eigenes Süppchen kochst, dass außer Dir kein Mensch konsumieren möchte?

"langjähriger Praxiserfahrung", "internationaler", "professioneller" Ach Gottchen! Du bist nicht nur süß, du bist auch noch lustig. Ich hab auch meine Erfahrung und bin bisher ganz gut damit gefahren. In den letzten 7 Jahren mußte ich noch nie meine Scripts "aktuallisieren" wegen "Änderungen irgentwelcher Standarts". Komisch. Kann so schlimm wohl nicht sein, was du so behauptest. Oh ja, "international" arbeite ich auch. So, haben wir nun alle von dir ins Spiel gebrachten Buzzwords durch?

Noch einmal: Lass mich meinen Kram so machen wie ich es mache, und du machst es so, wie du es machst. Ganz einfach.

Danke das du anfangs mir (vielleicht) Tipps geben wolltest. Gebracht hat es letztendlich (mal wieder) leider nix.

So, und nun tschüß!
csx

[Christian Kruse]

Hallo csx,

sofern Du Dich immer noch auf Perl beziehst: nein. Bei
PHP mag es eine kranke Versionsproblematik geben; bei
Perl wird Dir allenfalls gesagt, dass ein bestimmtes
Modul nicht oder nicht neu genug vorliegt, welches dann
halt installiert wird.

Sofern du die nötigen Rechte hast...

Falsch.

perldoc perlmodinstall

Du bist ja echt süß. Meinst du ich weis nicht, wie man
Module installiert? Nur weil ich sie möglichst nicht
benutze... (bitte richte deine Aufmerksamkeit vor allem
auf die Vokabel "möglichst")

Ja. Du sagtest oben 'sofern du die noetigen Rechte hast'.
Du brauchst nur deine eigenen Rechte, um Module zu
installieren.

Nein. Weil Du auf den Einsatz von Modulen - und zwar
insbesondere von Standardmodulen - verzichtest.

Wie gesagt, ich hab schon viele Systeme (vor allem
Windows-Versionen) gesehen, wo die nicht vorhanden waren.

Standard-Module sind auf allen Systemen vorhanden. Dann waren
es keine Standard-Module.

Gruesse,
 CK

[Michael Schröpl]

Hi csx,

Nochmal: Module find ich gut, da sie zum Teil Zeit sparen und den Programmierprozess beschleunigen. Wenn man aber weis, das ein bestimmtes Script in der Zukunft auf vielen verschiedenen Plattformen laufen soll, dann sollte man soweit wie möglich auf Module verzichten, da sie nur zu unnötigen Inkompatibilitäten führen.

nicht, wenn es Standardmodule sind.

Dies zu unterscheiden ist es, was Du ablehnst und wofür Cheatah Dich kritisiert.

Viele Grüße
      Michael

[Christian Kruse]

Hallo csx,

Was ist so schlimm daran, print"Content-type: bla/bla\n\n";
zu schreiben?

Es ist falsch. Richtig waere:

print "Content-Type: blah/blah\015\012";

Gruesse,
 CK

[Michael Schröpl]

Hi csx,

Es läuft ja, nur man muß eben selbst nachdenken statt sich darauf zu verlassen, daß andere richtig nachgedacht haben als sie das jeweilige Modul geschrieben haben.

warum verläßt Du Dich dann aber gleichzeitig auf genau diese Eigenschaft, in dem Du Perl verwendest?

Wieso sollten in einem einfaches Modul, das noch dazu Open Source ist, mit höherer Wahrscheinlichkeit Fehler enthalten sein als in einem sehr viel komplexeren Interpreter?

Viele Grüße
      Michael

[Struppi]

Also, mein script lädt also eine Datei und stellt sie ($pg) dann über HTML in einer textarea dar:

Problem ist klar: Ich muß bestimmte Zeichen vorher escapen, mindestens darf die Zeichenfolge "</textarea>" nicht im Ausgabestring ($pg) vorkommen. Also:

....

Ich möchte aber auch Perl-Scripts editieren können, auch das Script des Editors selbst! Würde ich es so ausgeben, dann würde ja &#x003C in ein "<"-Zeichen umgewandelt werden. Also muß cih auch Hashes escapen:

...

Nach dem submitted der textarea müssen die escapten Werte wieder zurückgewandelt werden

....

Bevor der String in die zuvor "gebackupte" Datei geschrieben wird.

Frage: Hab ich beim escapen der Werte noch irgentwas übersehen? Ich möchte jede mögliche (Text-)datei in die textarea laden können, ohne das sich nach dem submit irgentein Buchstabe oder Sonderzeichen ändern würde.

Also wen ich das richtig sehe, muss so nichts escapet werden:

#!/usr/bin/perl -w

use HTML::Entities;
use CGI qw/:standard/;

my $v = "<textarea>";

print header(), start_html();
if(param('action'))
{
print '<pre style="border:1px solid black">' . encode_entities(param('text')) . '</pre>';

}

print start_form()
     . textarea(-name=>'text', -value => $v)
     . br()
     . submit(-name => 'action', -value => 'abschicken')
     . end_form();

Struppi.