Formulartext per CGI Script in angenehm lesbares Format bringen

[Alex]

Hat jemand ein Script, das die lästigen Zusatzzeichen und Ä/Ö/Ü Umschreibungen aus dem ins Formular eingetragenen Text nimmt, bevor es als mail verschickt wird?

[Cheatah]

Hi,

Hat jemand ein Script, das die lästigen Zusatzzeichen und Ä/Ö/Ü Umschreibungen aus dem ins Formular eingetragenen Text nimmt, bevor es als mail verschickt wird?

#!/usr/bin/perl -w
use strict;
use CGI ':standard';
print header, param('text');

Mehr dazu in

perldoc CGI

Cheatah

[Peter Squentz]

Hat jemand ein Script, das die lästigen Zusatzzeichen und Ä/Ö/Ü Umschreibungen aus dem ins Formular eingetragenen Text nimmt, bevor es als mail verschickt wird?

#!/usr/bin/perl -w
use strict;
use CGI ':standard';
print header, param('text');

Na, hier wird aber nicht per Mail verschickt. Man koennte es so loesen (exemplarisch und ungetestet):

#!/usr/local/bin/perl -w
use strict:
use CGI ':standard';
open MAIL, "/usr/lib/sendmail  -oi -t -odq" or die "sendmail: $!";
print MAIL <<_;
From: [e-mail]
To: [e-mail]
Subject: Formulardaten

_
print MAIL map "$_ -> @{[param $_]}\n", param;
close MAIL or die "closing sendmail: $!"

Peter

[Peter Squentz]

From: [e-mail]
To: [e-mail]

Zu bloed, schon ist mir ein Fehler passiert. Es muss hier heissen:

[e-mail]

Peter

[Andreas Bierhals]

Moin,

ich hab mal eine allgemeine Frage zu Perl und cgi.pm.
In letzter Zeit werden sehr viele Anfragen der Form, "wie löst man $Problem in Perl"
mit einem Skriptbeispiel beantwortet, welches oben mit "use CGI:standard;" beginnt.
Danach kommen dann ein oder zwei Aufrufe aus dieser Bibliothek, und $Problem
ist gelöst.

Meine Frage richtet sich jetzt nach der Performance. Das Modul cgi.pm umfaßt immerhin

• Moment ... - gute 6000 Zeilen, was für den Perl Interpreter einiges an zusätzlicher Arbeit bedeutet.
  "Damals" auf meinem Pentium 166 verstrichen hierfür zwischen 3 und 6 zusätzliche
  Sekunden, bevor irgendetwas vom Skript zurückkam, was bereits für manche cgi-basierte
  Benutzeroberflächen unerträglich lang sein kann. Richtige heutige Server mögen da vielleicht
  andere "Zeitvorstellungen" haben, sind dafür aber auch gleichzeitig mit mehreren
  Anfragen mehrerer Web-Sites beschäftigt. Hat daher jemand mal Erfahrungswerte gesammelt, wie
  es mit cgi.pm unter verschiedenen Konfigurationen (perl, mod_perl, perl*.dll, mit perlcc in diversen
  Varianten compiliert, fast-cgi) in der Performance aussieht?

Eine grundsätzliche Frage wäre noch - muß es immer gleich cgi.pm sein, auch wenn
man nur ein paar Formularfelder eines Homepage-Feedback-Formulars
decodieren will? Gerade für Perl-Anfänger sind dann imho
eher solche Beispiele wie im selfhtml cgi-Kapitel lehhreich als ein Funktionsaufruf aus
einem Modul (wobei ich natürlich zugeben muß, daß fast alle einfachen Perl-Fragen
eh' schon im Archiv zu finden sind...).

Oder anders formuliert - ab wann bzw. welcher Komplexität lohnt sich die Verwendung
von Modulen wie cgi.pm wirklich?

Bis dannundwann

Andreas

[Peter Squentz]

decodieren will? Gerade für Perl-Anfänger sind dann imho
eher solche Beispiele wie im selfhtml cgi-Kapitel lehhreich als ein Funktionsaufruf aus
einem Modul (wobei ich natürlich zugeben muß, daß fast alle einfachen Perl-Fragen
eh' schon im Archiv zu finden sind...).

Nein, hier muss ich deutlich widersprechen: Der Code ist daher ungeeignet, weil er nicht in allen Fällen anwendbar ist. Wer weiss, wo man ihn benutzen kann, mag's tun (wird er aber in der Regel nicht). Ein Anfänger weiss das in der Regel nicht.

Nebenbei, ein Skript, dass nur CGI.pm laedt und danach ein exit, braucht bei mir (AMD 350 MHz, 128 MB RAM):

real    0m0.143s
user    0m0.130s
sys     0m0.000s

Zum Vergleich ohne CGI.pm:

real    0m0.021s
user    0m0.020s
sys     0m0.000s

Sicherlich ein signifikanter Unterschied, der aber kaum spuerbar ist und praktisch (meist) irrelevant ist; zumal man meist Skripte hat, die komplexer sind und die Differenz (relativ gesehen) geringer ausfallen dürfte.

Peter

[n.d. parker]

hi peter

Nein, hier muss ich deutlich widersprechen: Der Code ist daher ungeeignet, weil er nicht in allen Fällen anwendbar ist. Wer weiss, wo man ihn benutzen kann, mag's tun (wird er aber in der Regel nicht). Ein Anfänger weiss das in der Regel nicht.

koenntest du dann gnaedigerweise uns anfaenger aufklaeren, wo und warum der code nicht funktioniert?
danke.

cua

n.d.p.

[Michael Schröpl]

Hi,

ich hab mal eine allgemeine Frage zu Perl und cgi.pm.
In letzter Zeit werden sehr viele Anfragen der Form, "wie löst man $Problem in Perl"
mit einem Skriptbeispiel beantwortet, welches oben mit "use CGI:standard;" beginnt.
Danach kommen dann ein oder zwei Aufrufe aus dieser Bibliothek, und $Problem
ist gelöst.

eben das ist m. E. der Sinn einer Antwort: Die Lösung eines Problems, in einer Form, die der Fragesteller versteht.

Sicherlich könnte Cheatah dem Fragesteller neben den drei Zeilen, die sein Problem lösen, weitere 30+ Zeilen Perl posten, welche den Einsatz von CGI.pm überflüssig machen.
Aber warum ein zweites Problem lösen, das vom Fragesteller gar nicht als solches angesehen wird, wenn dabei die Komplexität der Antwort um Faktor 10+ zunimmt?
Deshalb befürworte ich (im Gegensatz etwa zu Wolfgang Wiese) die Verwendung von CGI.pm gerade bei Antworten im Forum uneingeschränkt. Die meisten Fragesteller werden damit schnell und zuverlässig bedient.
Überlege selbst, wie lange es dauert, bis ein Anfänger zum ersten Mal eine Lösung realisieren muß, bei der Performance wirklich eine Rolle spielt! Bei mir war es noch nie der Fall, daß ich CGI.pm hätte "einsparen" wollen. Und wenn es denn so weit ist, kann der dann erfahrenere Entwickler selbständig die Archivsuche bemühen und nach Hinweisen suchen, welche seine Anwendung performanter machen helfen.

Gerade für Perl-Anfänger sind dann imho eher solche Beispiele wie im selfhtml cgi-Kapitel lehhreich als ein Funktionsaufruf aus einem Modul

Eben das sehe ich anders. Wenn Dich jemand auf der Straße nach dem Weg fragt, erklärst Du ihm dann das vollständige Deutsche Verkehrsrecht?

Oder anders formuliert - ab wann bzw. welcher Komplexität lohnt sich die Verwendung
von Modulen wie cgi.pm wirklich?

Ich würde sie genau anders herum stellen, nämlich: Ab welcher Performance-Anforderung aufwärts ist man gezwungen, die Hauptstärke von Perl, nämlich die vorhandenen Module, zugunsten sekundärer Eigenschaften (in diesem Falle ggf. Performance) in Frage zu stellen?
Bei *jedem* kleinen Projekt würde ich CGI.pm verwenden, eben weil es dort egal ist, Arbeit spart und potentielle Fehler bei der eigenen Implementierung ausschließt. Tuning ist m. E. der letzte Schritt einer Entwicklung, nicht der erste.

mfG - Michael

[n.d. parker]

hi

Gerade für Perl-Anfänger sind dann imho eher solche Beispiele wie im selfhtml cgi-Kapitel lehhreich als ein Funktionsaufruf aus einem Modul
Eben das sehe ich anders. Wenn Dich jemand auf der Straße nach dem Weg fragt, erklärst Du ihm dann das vollständige Deutsche Verkehrsrecht?

das sehe ich wiederum noch anders .-)

falscher vergleich - wenn mich jemand fragt, wie er wohin kommt, sag ich ihm nicht, er soll n taxi oder n bus nehmen, wenn das ziel eine strasse weiter ist.

wenn man immer nur auf vorgefertigtes zurueckgreift, lernt man _nie_ programmieren.

cua

n.d.p.

[kerki]

Hallo !

falscher vergleich - wenn mich jemand fragt, wie er wohin kommt, sag ich ihm nicht, er soll n taxi oder n bus nehmen, wenn das ziel eine strasse weiter ist.

CGI.pm ist aber doch der kürzeste und einfachste Weg !

wenn man immer nur auf vorgefertigtes zurueckgreift, lernt man _nie_ programmieren.

Ergo, muss ich jetzt meinen liebgewonnen und _vorgefertigten_ Editor wegwerfen, und erst einmal selbst einen programmieren? ;-)

Gruß,
Kerki

[n.d. parker]

auch hi

CGI.pm ist aber doch der kürzeste und einfachste Weg !

wenn man weiss, was man tut - ja, das wissen aber die meisten (anfaenger) nicht.
aber zum _lernen_ nicht zwingend der beste - nach jahrelanger _nur_ benutzung dieses moduls weiss man immer noch nicht, was dort eigentlich passiert

wenn man immer nur auf vorgefertigtes zurueckgreift, lernt man _nie_ programmieren.
Ergo, muss ich jetzt meinen liebgewonnen und _vorgefertigten_ Editor wegwerfen, und erst einmal selbst einen programmieren? ;-)

? was ist denn das jetzt fuern quatsch?

cua

n.d.p.

[kerki]

Hallo !

wenn man weiss, was man tut - ja, das wissen aber die meisten (anfaenger) nicht.
aber zum _lernen_ nicht zwingend der beste - nach jahrelanger _nur_ benutzung dieses moduls weiss man immer noch nicht, was dort eigentlich passiert

Die Frage ist aber doch, wie weit man (gerade als Anfänger) jede Einzelheit der benutzten Technik wissen MUSS.

Das sollte auch der 'Quatsch' mit dem Editor:

Wenn ich das Modul CGI.pm nicht benutzen darf, weil ich es nicht selbst programmiert habe und somit die Funktionsweise nicht genau nachvollziehen kann, gilt dies dann für Perl auch, und das Betriebssystem auf dem es läuft, und Computer überhaupt, und Strom ...

Ich weiß ja noch nicht einmal genau wie ich selbst als Mensch 'funktioniere', darf ich da überhaupt leben?

Zugegeben, das ist jetzt sehr weit ausgeholt, aber wo willst du die Grenze ziehen?

Gruß,
Kerki

[n.d. parker]

re hi

Die Frage ist aber doch, wie weit man (gerade als Anfänger) jede Einzelheit der benutzten Technik wissen MUSS.

man sollte ans anfaenger sich gerade fuer die details interessieren - sonst lernt mans nie - was bringt es mir, scripte zu benutzen, die ich nicht verstehe?
zeig mir den anfaenger, der weiss, was er da tut, der _versteht_, was er da macht. Insbesondere (und beispielsweise) in puncto Sicherheit herrscht ein ganz spezielles Defizit, aber wenn ich moegliche Fehlerquellen gar nicht kenne, kann ich sie auch nicht ausraeumen, oder?
und die ganzen selbsternannten "Webmaster" und "Programmierer" die im Netz ihr Unwesen treiben wissen mit _Sicherheit_ nicht, was sie tun - woher auch? es ist ja so einfach, auch als antwortender auf irgendwelche fragen - use CGI bla bla, keine erklaerung, gar nix, zu drei zeilen url-decoding muesste man ja noch was schreiben, pure faulheit auch auf seiten der "Wissenden", moechte ich meinen, und in einem solchen Falle, sollten sie die Antowrt lieber bleiben lassen.

Wenn ich das Modul CGI.pm nicht benutzen darf, weil ich es nicht selbst programmiert habe und somit die Funktionsweise nicht genau nachvollziehen kann, gilt dies dann für Perl auch, und das Betriebssystem auf dem es läuft, und Computer überhaupt, und Strom ...

von nicht duerfen redet hier keiner - aber wenn ich programmiere, sollte ich wissen, was ich tue, sonst koennte ich ja auch meine html-seiten mit nem wysiwyg-prog machen - siehst du das nicht ein?
wenn du nicht programmieren lernen willst, kannst du deine programme ja auch schreiben lassen.

Ich weiß ja noch nicht einmal genau wie ich selbst als Mensch 'funktioniere', darf ich da überhaupt leben?
Zugegeben, das ist jetzt sehr weit ausgeholt, aber wo willst du die Grenze ziehen?

zu weit ausgeholt, wuerde ich sagen, du weichst vom thema ab und wirst ganz gewaltig unsachlich.
ich sage nur, zum _verstehen_, was da passiert, ist es sch***, auf vorgefertigtes zurueckzugreifen, dass kann ich immer noch tun, wenn ichs begriffen hab.

btw: ich hab nichts gegen module, aber sie staendig als allheilmittel hinzustellen _ist_ schwachsinn, damit wird doch nur die mentalitaet - bekommen ja, selbermachen nein - gefoerdert.

cua

n.d.p.

[Holger]

Hat jemand ein Script, das die lästigen Zusatzzeichen und Ä/Ö/Ü Umschreibungen aus dem ins Formular eingetragenen Text nimmt, bevor es als mail verschickt wird?

Wenn Du das Formular nur per E-Mail verschicken willst brauchst Du doch gar kein CGI-Script.

<form name="mail" action="mailto:[e-mail]" method=post enctype="text/plain">

Ansonsten kannst Du hier (http://www.teamone.de/selfhtml/tgcm.htm) nachlesen, wie man mit dem Formulardatenstrom umgeht.

Gruss, Holger

[Cheatah]

Hi,

Wenn Du das Formular nur per E-Mail verschicken willst brauchst Du doch gar kein CGI-Script.

http://www.praast.de/ffq/mailto.htm

Cheatah

[kerki]

Hallo Cheatah !

Was sollen diese wiederholten Sticheleien ?

Wenn Du schon zitierst, dann bitte auch das Richtige :

<../../tchl.htm#a1>

Gruß,
Kerki

[Swen]

Moin,

was heist schon richtig ?

Ich hätte auf <../../sfausles/tsfa_tai.htm#a1> verwiesen, andere vielleicht auf http://www.teamone.de/selfaktuell/artikel/formmail.htm, der dritte zeigt hat gern auf eigene Werke.

Swen

[kerki]

Hallo Swen !

Sorry, aber mir scheint, du hast nicht verstanden, was ich sagen wollte.

Auf der von Cheatah gelinkten Seite http://www.praast.de/ffq/mailto.htm steht :

' Leider steht auch bei SelfHTML (http://www.teamone.de/selfhtml/tcha.htm#a2) nicht ausdrücklich, dass bei der Verwendung von <form action="mailto:[e-mail]" method=post enctype="text/plain"> mit massiven Problemen zu rechnen ist. '

Mein Link zeigt, dass in SelfHTML _sehr wohl_ auf diese Probleme hingewiesen wird.

Meine Kritik bezog sich also nicht auf den Link, der durchaus auf irgendeine Seite führen darf, die das Problem behandelt, sondern auf den Inhalt dieser Seite.

Schau bitte auch mal hier : http://www.teamone.de/selfaktuell/forum/messages/86167.html.

Ich bin scheinbar nicht der Einzige, der da Probleme mit Cheatah's Art hat.

Gruß,
Kerki

P.S.: Ich würde mich freuen, wenn wir beide uns jetzt endlich einmal richtig verstehen würden. ;-)

[Cheatah]

Hi,

Was sollen diese wiederholten Sticheleien ?

wieso Sticheleien?

Wenn Du schon zitierst, dann bitte auch das Richtige :

Ich halte die von mir genannte Ressource keineswegs für falsch.

Cheatah

[Peter Squentz]

Was sollen diese wiederholten Sticheleien ?

Ich denke, auf der von Hajo angefuehrten Seite werden sehr schluessige Argumente genannt. Von Stichelei kann hier keine Rede sein. Aber wie heisst es doch: the best defence against logic is ignorance.

Peter