Formulardaten in txt schreiben

[Peda7]

Hallo!

Wie der Titel schon sagt, möchte ich die Formulardaten beim Absenden in eine txt Datei schreiben!

Wie man die Daten in eine txt Datei schreibt ist jetzt nicht das große Problem! Ich möchte aber das beim Absenden des Formulars immer eine neue Text Datei erzeugt wird und in diese die Daten reingeschrieben werden!
Der Titel der Text-Datei soll auch aus einem Formularfeld ausgelesen werden!

Hab schon ein wenig gesucht, bin aber nicht wirklich zu einem Ergebnis gekommen!

Darum die Frage an Euch!

Thx schon mal für Eure Antworten

mfg

[suit]

Wie man die Daten in eine txt Datei schreibt ist jetzt nicht das große Problem!

Denke ich mir - mit PHP gibts dafür aber mehrere Möglichkeiten.

Ich möchte aber das beim Absenden des Formulars immer eine neue Text Datei erzeugt wird und in diese die Daten reingeschrieben werden!

Das ist ein noch geringeres Problem als jedes mal in dieselbe Datei schreiben.

Der Titel der Text-Datei soll auch aus einem Formularfeld ausgelesen werden!

Und wo ist jetzt das große Problem?

Hab schon ein wenig gesucht, bin aber nicht wirklich zu einem Ergebnis gekommen!

Nicht so demotiviert - in deinem alten Thread bist du immerhin auch selbst auf eine Lösung gekommen.

Darum die Frage an Euch!

Thx schon mal für Eure Antworten

So wie beim letzten Mal?

[Peda7]

Und wo ist jetzt das große Problem?

Wie kann ich mit PHP beim Absenden des Formulars eine Text Datei automatisch erzeugen lassen?

[suit]

Und wo ist jetzt das große Problem?

Wie kann ich mit PHP beim Absenden des Formulars eine Text Datei automatisch erzeugen lassen?

Wie sendest du mit PHP denn dein Formular überhaupt ab - du widersprichst dir.

Sofern das Problem etwas mit deinem vorhergehenden Thread zu tun hat, schickst du zwei Formulare unabhängig voneinander per JavaScript ab - nicht mit PHP.

In der Verarbeitungsroutine an die du die Formulare vermutlich schickst, kannst du an geeigneter Stelle eine Textdatei erzeugen lassen - du selbst hast ja bereits gesagt, der Teil wäre einfach.

[Peda7]

Hierbei handelt es sich nur um 1 Formular.

Beim Absenden werden die Forumlareingaben mittels PHP Formmailer verschickt.
Die Daten die in der Mail verschickt werden, sollen dann auch jedesmal in eine eigene txt Datei gespeichert werden!

[Tom]

Hello,

Beim Absenden werden die Forumlareingaben mittels PHP Formmailer verschickt.
Die Daten die in der Mail verschickt werden, sollen dann auch jedesmal in eine eigene txt Datei gespeichert werden!

Hatte eben schon mal hier geantwortet, ist aber verschwunden (?)

$fh = fopen($dateiname,'xb+');

sollte Dir weiterhelfen. Den Dateinamen generierst Du z.B. aus einem Timestamp und einer laufenden Nummer, solange bis es geklappt hat, oder ein Maximum an Versuchen erreicht ist.

Der Vollständigkeit halber sollte (auch) die (neue) Datei bei Bearbeitung imemr gesperrt werden.
http://aktuell.de.selfhtml.org/artikel/programmiertechnik/dateisperren/,
auch, wenn dies hier nicht zwingend erfoderlich ist. Wenn aber später mehrere Scripte/Funktionen auf die Dateien zugreifen sollen, müsstest Du es nachbessern...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Peda7]

Ok habs jetzt geschafft das jedesmal eine neue txt Datei erzeugt wird!

thx dafür

Für den Dateinamen hab ich das jetzt so gemacht:

  
$handle = fopen($_POST['Feldname1'].".txt", "w+");  

Es kann vorkommen das der Dateiname von Feldname2 ausgelesen wird falls in Feldname 1 nichts eingetragen wurde. Kann man das mit || realisieren?
Habs probiert, funktioniert leider nicht?

thx

[Tom]

Hello,

Ok habs jetzt geschafft das jedesmal eine neue txt Datei erzeugt wird!

thx dafür

Für den Dateinamen hab ich das jetzt so gemacht:

$handle = fopen($_POST['Feldname1'].".txt", "w+");

  
Das ist aber gefährlich. So kann der User auch Pfade angeben und Dir wichtige Dateien überscheiben. Außerdem solltest Du verhindern, dass auf diese Weise Scripte hochgeladen werden können.  
  
Außerdem sollte man sich immer noch auch die druckbaren ASCII-Zeichen beschränken bei Dateinamen.  
  
Du hast also noch einige Punkte abzuarbeiten.  
  
- Es können Pfade angegeben werden  
- es können ggf. auch noch beliebige Dateien angelegt werden,  
  wenn man es schafft, das Anhängen von ".txt" an den Namen irgendwie zu verhindern  
- Vorhandene Dateien werden einfach überschrieben  
usw.  
  
  
  
  
Liebe Grüße aus dem schönen Oberharz  
  
  
Tom vom Berg  
![](http://selfhtml.bitworks.de/Virencheck.gif)  
  

-- 
 ☻\_  
/▌  
/ \ Nur selber lernen macht schlau  
<http://bergpost.annerschbarrich.de>

[Shadowcrow]

'ǝɯɐu$ ıɥ

Du hast also noch einige Punkte abzuarbeiten.

• Es können Pfade angegeben werden
• es können ggf. auch noch beliebige Dateien angelegt werden,
    wenn man es schafft, das Anhängen von ".txt" an den Namen irgendwie zu verhindern
• Vorhandene Dateien werden einfach überschrieben
  usw.

• es könnte PHP Code (Javascript,...) im Dateinamen oder in der Datei stehen wenn das zb. bei einer Ausgabe durch den Parser geht *schauder*.

ssnɹƃ
ʍopɐɥs

[dedlfix]

Hi!

• es könnte PHP Code (Javascript,...) im Dateinamen oder in der Datei stehen wenn das zb. bei einer Ausgabe durch den Parser geht *schauder*.

Das ist kein Problem des Dateinamens sondern wäre ein missachteter Kontextwechsel. Du kannst den Inhalt einer Datei zwar soweit einschränken, dass er garantiert in allen Kontexten kein Problem darstellt, dann ist ihre Länge aber konstant 0. Das ist natürlich nicht sinnvoll, also ist es nicht sinnvoll, den Inhalt anders als wegen fachlicher Bedingungen zu beschränken und bei der Ausgabe den jeweiligen Kontext zu beachten und die Daten entsprechend anzupassen.

Lo!

[Tom]

Hello Dedlfix,

• es könnte PHP Code (Javascript,...) im Dateinamen oder in der Datei stehen wenn das zb. bei einer Ausgabe durch den Parser geht *schauder*.

Das ist kein Problem des Dateinamens

doch, es ist auch Problem des Dateinamens, da übliche Webserver die Dateien (auch) an ihrem Namen (der Extension) unterscheiden und dann ggf. dem Parser zuleiten.

sondern wäre ein missachteter Kontextwechsel.

Das mag ebenfalls zutreffen. Sicherer ist es aber, die Files sofort ein einem Verzeichnis abzulegen, dessen Inhalt garantiert nicht geparst wird.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

• es könnte PHP Code (Javascript,...) im Dateinamen oder in der Datei stehen wenn das zb. bei einer Ausgabe durch den Parser geht *schauder*.
  Das ist kein Problem des Dateinamens
  doch, es ist auch Problem des Dateinamens, da übliche Webserver die Dateien (auch) an ihrem Namen (der Extension) unterscheiden und dann ggf. dem Parser zuleiten.

Es ist ein bisschen uneindeutig von Shadowcrow geschrieben. Code im Dateinamen sollte in der Regel irrelevant sein (wenn nicht irgendwo ein Kontextwechsel bei der Ausgabe des Dateinamens missachtet wird). Die Gestaltung eines Dateinamen allein hat erstmal keine weiteren Konsequenzen. Es kommt auf die verarbeitenden Systeme an, und da kann selbst der anderswo harmloseste Dateiname Ungewolltes anstellen.

Code in der Datei selbst und eine entsprechende Endung ist schon eher ein anzutreffender Fall, aber auch der wird nur zum Problem, wenn die zugrifenden Systeme nicht gescheit konfiguriert sind.

Lösen lassen sich beide Probleme auf generelle Weise nur wenn weder Dateiname noch Inhalt existiert. Alles andere kommt auf die Umstände an.

Sicherer ist es aber, die Files sofort ein einem Verzeichnis abzulegen, dessen Inhalt garantiert nicht geparst wird.

Das wäre eine praktikable Herangehensweise, die jedoch eine gut überlegte Serverkonfiguration erfordert, was nicht unbedingt bei allen Hostern möglich ist.

Lo!

[Tom]

Hello,

Sicherer ist es aber, die Files sofort in einem Verzeichnis abzulegen, dessen Inhalt garantiert nicht geparst wird.

Das wäre eine praktikable Herangehensweise, die jedoch eine gut überlegte Serverkonfiguration erfordert, was nicht unbedingt bei allen Hostern möglich ist.

Ich habe in der Vergangenheit durchaus den Eindruck gehbat, dass "die Hoster" hier mitlesen. Es hat sich über die Jahre nämlich schon vieles zum Besseren gewandelt, nachdem hier darüber diskutiert wurde.

Ein Verzeichnis "Daten" o.ä., das außerhalb der Document Root liegt, gehört heute schon fast zum Standard. Warum sollten die Mitleser dann nicht auch irgendwann ein Verzeichnis "Uploads", "not_parsed" o.ä. schaffen, das innerhalb der Document-Root liegt und samt seiner Unterverzeichnisse nicht geparst wird.

Das hilft natürlich nur, wenn in den begleitenden Dokumentationsseiten des Hosters auch der Sinn dieses Verzeichnisses klar gemacht wird.

Aber die Hoffnung stirbt zuletzt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Ich habe in der Vergangenheit durchaus den Eindruck gehbat, dass "die Hoster" hier mitlesen. Es hat sich über die Jahre nämlich schon vieles zum Besseren gewandelt, nachdem hier darüber diskutiert wurde.

Vielleicht war das einfach nur Zeitgeist oder bei ihnen selbst gesammelte Erkenntnis oder aus Kundenwunsch entstanden oder in der verwendeten Konfigurationssoftware schon so vorgesehen ... Spekulatius

Ich hab die Tage Bekannschaft mit Plesk gemacht, das erstellt einen recht ordentlichen Verzeichnisbaum beim Anlegen von Domains und auch Subdomains.

Ein Verzeichnis "Daten" o.ä., das außerhalb der Document Root liegt, gehört heute schon fast zum Standard. Warum sollten die Mitleser dann nicht auch irgendwann ein Verzeichnis "Uploads", "not_parsed" o.ä. schaffen, das innerhalb der Document-Root liegt und samt seiner Unterverzeichnisse nicht geparst wird.

Das halte ich nicht für die beste Idee. Woran soll man das festmachen? An einer Namenskonvention? Oder soll es eine Konfigurationsoption mehr in der Verwaltungsoberfläche für den Kunden geben, mit der man das konfigurieren kann? Und warum im DocumentRoot? Ich würde da gar kein großes Federlesen drum machen sondern einfach nur im Kundenverzeichnis bestimmte grundlegende Verzeichnisse per Default erstellen, vor allem ein eigenes für das DocumentRoot.

Lo!

[Tom]

Hello,

Ein Verzeichnis "Daten" o.ä., das außerhalb der Document Root liegt, gehört heute schon fast zum Standard. Warum sollten die Mitleser dann nicht auch irgendwann ein Verzeichnis "Uploads", "not_parsed" o.ä. schaffen, das innerhalb der Document-Root liegt und samt seiner Unterverzeichnisse nicht geparst wird.

Das halte ich nicht für die beste Idee. Woran soll man das festmachen? An einer Namenskonvention? Oder soll es eine Konfigurationsoption mehr in der Verwaltungsoberfläche für den Kunden geben, mit der man das konfigurieren kann? Und warum im DocumentRoot? Ich würde da gar kein großes Federlesen drum machen sondern einfach nur im Kundenverzeichnis bestimmte grundlegende Verzeichnisse per Default erstellen, vor allem ein eigenes für das DocumentRoot.

Das kann man am Namen festmachen, JA.

Innerhalb der Document-Root muss es liegen, damit die Files (z.B. Bilder) direkt per HTTP-Request erreichbar sind, aber keinesfalls geparst werden.

Warum Bilder nicht geparst werden dürfen, hat Martin kürzlich eindrucksvoll gezeigt. Spätestens wenn ich ein Tool gefunden habe oder aber meines fertig bekommen habe, das derartig präparierte Bilder erzeugen kann, geht auch der Artikel weiter, allerdings ohne das Tool zu veröffentlichen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Shadowcrow]

'ǝɯɐu$ ıɥ

Warum Bilder nicht geparst werden dürfen, hat Martin kürzlich eindrucksvoll gezeigt. Spätestens wenn ich ein Tool gefunden habe oder aber meines fertig bekommen habe, das derartig präparierte Bilder erzeugen kann, geht auch der Artikel weiter, allerdings ohne das Tool zu veröffentlichen.

Schau dir das mal an, dieses Bilder-Upload-Script hat eine fiese Sicherheitslücke:

Die Sicherheitslücke beruht auf einem Fehler in der Datei processing.php. Diese ermöglicht das Hochladen von Dateien mit mehreren Dateiendungen in einem Ordner innerhalb des Web-Root.
Dies kann dazu ausgenutzt werden, um z. B. das Ausführen von beliebigem PHP-Code durch Hochladen einer speziell gestalteten PHP-Skript, welches eine “GIF magic number” enthält.
Quelle: http://www.webichserheit.org/?p=7510

ssnɹƃ
ʍopɐɥs

[Tom]

Hello,

Schau dir das mal an, dieses Bilder-Upload-Script hat eine fiese Sicherheitslücke:

Die Sicherheitslücke beruht auf einem Fehler in der Datei processing.php. Diese ermöglicht das Hochladen von Dateien mit mehreren Dateiendungen in einem Ordner innerhalb des Web-Root.
Dies kann dazu ausgenutzt werden, um z. B. das Ausführen von beliebigem PHP-Code durch Hochladen einer speziell gestalteten PHP-Skript, welches eine “GIF magic number” enthält.

Quelle: http://www.websicherheit.org/?p=7510

Ja, genau um solche Scripte ging es.

Wenn beim Upload von Bildern nicht gewährleistet ist, dass diese keinesfalls geparst werden, dann können sich z.B. in den Exif-Daten ganze PHP-Scripte verstecken, die dann auch ausgeführt werden. Hierzu ist es aber notwendig, dass alle anderen Bilddaten keine für den PHP-Parser unerlaubten Steuerzeichen darstellen. Sonst streikt der zum Glück. Das ist z.Zt. noch die einzige "Versicherung".

Nun könnte man prüfen, dass ausschließlich Dateien mit den Endungen *.gif, *.png, *.jpg, *.bmp, *.tif usw, hochgeladen werden können. Das würde schon mal für Abhilfe sorgen. Besser wäre es aber, das Parsen im Bilder-Directory vollständig zu unterbinden.

Solange die Bilder außerhalb der Document-Root gespeichert werden, stellt das auch kein Problem dar. Nur dann muss jedes angeforderte Bild wieder durch ein Script ausgeliefert werden...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Shadowcrow]

'ǝɯɐu$ ıɥ

Und wo ist jetzt das große Problem?

Wie kann ich mit PHP beim Absenden des Formulars eine Text Datei automatisch erzeugen lassen?

Schau ins Handbuch fwrite(); der Dateiname ergibt sich bei dir ja aus einem Formularfeld ansonsten bilde einen Hash aus der Sternzeit oder so.

ssnɹƃ
ʍopɐɥs

[dedlfix]

Hi!

Schau ins Handbuch fwrite();

Warum so viel Mühe mit fwrite() und noch ein paar mehr Funktionen, wenn es mit file_put_contents() in einem Aufwasch geht?

Lo!

[Shadowcrow]

'ǝɯɐu$ ıɥ

Warum so viel Mühe mit fwrite() und noch ein paar mehr Funktionen, wenn es mit file_put_contents() in einem Aufwasch geht?

Weil ich Arrays im Kopf hatte...

ssnɹƃ
ʍopɐɥs

[Tom]

Hello,

Schau ins Handbuch fwrite();

Warum so viel Mühe mit fwrite() und noch ein paar mehr Funktionen, wenn es mit file_put_contents() in einem Aufwasch geht?

Das sehe ich noch nicht. Wie detektierst Du, dass es die Datei nicht schon gab unter dem Namen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Schau ins Handbuch fwrite();
Warum so viel Mühe mit fwrite() und noch ein paar mehr Funktionen, wenn es mit file_put_contents() in einem Aufwasch geht?
Das sehe ich noch nicht. Wie detektierst Du, dass es die Datei nicht schon gab unter dem Namen?

Na gut, das w+ im fopen() stellt ja schonmal sicher, dass ein Überschreiben existierender Datenen nicht möglich ist. Braucht es dann überhaupt noch ein Locking? Es kann doch eigentlich sowieso keine zweite Script-Instanz in die selbe Datei schreiben, weil das ja durch das w+ schon das Öffnen abgelehnt wird.

Lo!

[Tom]

Hello,

Schau ins Handbuch fwrite();
Warum so viel Mühe mit fwrite() und noch ein paar mehr Funktionen, wenn es mit file_put_contents() in einem Aufwasch geht?
Das sehe ich noch nicht. Wie detektierst Du, dass es die Datei nicht schon gab unter dem Namen?

Na gut, das w+ im fopen() stellt ja schonmal sicher, dass ein Überschreiben existierender Datenen nicht möglich ist.

Verwechselst Du das nicht mit "x+"?

"w+" bedeutet, dass die Datei angelegt, beschrieben und auch wieder gelesen werden darf.

Außedem würde ich immer noch das "b" einfügen, damit die Appklikationen auch auf Windows-Hosts neutral bleiben bezüglich Zeilenumbrüchen.

Braucht es dann überhaupt noch ein Locking? Es kann doch eigentlich sowieso keine zweite Script-Instanz in die selbe Datei schreiben, weil das ja durch das w+ schon das Öffnen abgelehnt wird.

Wie kommst Du darauf?
Es kann jede andere Prozess in eine gerade neu eröffnete Datei hineinschreiben, so zumindest bei den gängigen Filesystemen für DOS-Systeme, um die es hier ja wohl geht. Bei OS400 isht das anders aus.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Warum so viel Mühe mit fwrite() und noch ein paar mehr Funktionen, wenn es mit file_put_contents() in einem Aufwasch geht?
Das sehe ich noch nicht. Wie detektierst Du, dass es die Datei nicht schon gab unter dem Namen?
Na gut, das w+ im fopen() stellt ja schonmal sicher, dass ein Überschreiben existierender Datenen nicht möglich ist.
Verwechselst Du das nicht mit "x+"?

Ja, das x+ meinte ich. Das w+ von Peda7 hat mich abgelenkt.

Braucht es dann überhaupt noch ein Locking? Es kann doch eigentlich sowieso keine zweite Script-Instanz in die selbe Datei schreiben, weil das ja durch das w+ schon das Öffnen abgelehnt wird.

Wenn wir mal annehmen, ich hätte x+ geschrieben ...

Wie kommst Du darauf?
Es kann jede andere Prozess in eine gerade neu eröffnete Datei hineinschreiben, so zumindest bei den gängigen Filesystemen für DOS-Systeme, um die es hier ja wohl geht. Bei OS400 isht das anders aus.

... dann beendet sich ein fopen() mit false, wenn die Datei schon existiert. Es ist wohl davon auszugehen, dass allein dieses PHP-Script Erstellversuche in dem einen festgelegten Verzeichnis unternehmen wird. Und wenn die Datei einmal existiert, sträubt sich x+ gegen jeden weiteren Schreibzugriff seitens des PHP-Scripts. Der Auswertende kann davon ungehindert die Dateien öffnen und verändern. Sollte es dabei Konfliktsituationen geben, ist das nicht mehr im Focus des PHP-Scripts. Erst wenn er eine Datei löscht kann das PHP-Script eine neue gleichen Namens anlegen.

Lo!

[Tom]

Hello,

Wenn wir mal annehmen, ich hätte x+ geschrieben ...

Wie kommst Du darauf?
Es kann jede andere Prozess in eine gerade neu eröffnete Datei hineinschreiben, so zumindest bei den gängigen Filesystemen für DOS-Systeme, um die es hier ja wohl geht. Bei OS400 isht das anders aus.

... dann beendet sich ein fopen() mit false, wenn die Datei schon existiert. Es ist wohl davon auszugehen, dass allein dieses PHP-Script Erstellversuche in dem einen festgelegten Verzeichnis unternehmen wird. Und wenn die Datei einmal existiert, sträubt sich x+ gegen jeden weiteren Schreibzugriff seitens des PHP-Scripts. Der Auswertende kann davon ungehindert die Dateien öffnen und verändern. Sollte es dabei Konfliktsituationen geben, ist das nicht mehr im Focus des PHP-Scripts. Erst wenn er eine Datei löscht kann das PHP-Script eine neue gleichen Namens anlegen.

Ja, dieses Script schon.

Aber was ist mit einem Editierscript/einer Editierfunktion, das/die vielleicht noch folgt? Das/die dürfte dann in die gerade angelegte Datei hineinschreiben. Um dies zu verhindern, sollte auch die neu angelegte Datei mit einem Exclusive Lock belegt werden, bevor man sie beschreibt.

Alles andere wäre kurzsichtig gedacht.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Aber was ist mit einem Editierscript/einer Editierfunktion, das/die vielleicht noch folgt? Das/die dürfte dann in die gerade angelegte Datei hineinschreiben. Um dies zu verhindern, sollte auch die neu angelegte Datei mit einem Exclusive Lock belegt werden, bevor man sie beschreibt.
Alles andere wäre kurzsichtig gedacht.

Theoretisch gesehen ja. Aber stell dir das mal praktisch vor. Ein Script legt gerade eine Datei an und schreibt Inhalt hinein. Das passiert innerhalb von Nullkommawenig. Ein Bearbeiter soll zu diesem Zeitpunkt schon wissen, dass es diese Datei gibt und dass er sie bearbeiten will? Das ist ein extrem unwahrscheinliches Szenario. Ein Locking einzubauen ist zwar schnell gemacht, aber praktisch irrelevant bleibt es bei den derzeit von uns vermuteten Anwendungsfällen trotzdem.

Lo!

[Tom]

Hello,

Theoretisch gesehen ja. Aber stell dir das mal praktisch vor. Ein Script legt gerade eine Datei an und schreibt Inhalt hinein. Das passiert innerhalb von Nullkommawenig. Ein Bearbeiter soll zu diesem Zeitpunkt schon wissen, dass es diese Datei gibt und dass er sie bearbeiten will? Das ist ein extrem unwahrscheinliches Szenario. Ein Locking einzubauen ist zwar schnell gemacht, aber praktisch irrelevant bleibt es bei den derzeit von uns vermuteten Anwendungsfällen trotzdem.

*ähem*
Du erwartest doch jetzt nicht wirklich eine Antwort darauf?
Ich sage nur: "ein Bisschen schwanger" ist nichts dagegen.

Wie lange ein Prozess für das Wegschreiben der Daten benötigt, ob dies im API in einer Operation oder in vielen kleinen abgewickelt wird, ist doch nicht vorhersehbar [*] und genauso nicht, ob der konkurrierende Prozess nicht automatisch gesteuert sein wird (Bsp: setze bei allen Dateien im Verzeichnis einen Kommentar hinzu).

[*] Nach POSIX müssen Streams während der Bearbeitung gesperrt sein,
    aber das ist nicht unbedingt sichergestellt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hottii]

hi,

Darum die Frage an Euch!

Die Frage ist: wo ist die Frage? Ich lese von Dir nur Aussagen, die mit einem Ausrufezeichen terminiert sind!

Hotti!

[Lehrer]

Hör! Mal! Auf! Jeden! Satz! Mit! einem! Ausrufezeichen! Zu! Beenden!