[quote=lichtkind,16.11.2005, 10:08]wenn sie aus einem elf dump extrahiert können leicht auch mal EOL symbole mittendrin vorkommen,
[/quote]
Wie das?
Und wenn, wie sollte man zwischen einem "echten" und einem "zu den Daten gehoerigen" Newline unterscheiden?

Quote

mich würde auch interessieren wieso eure substitude ohne g auskommt?

Wenn man diesen Aufruf:

unter Unix/Linux macht, dann wird die Datei sowieso zeilenweise abgearbeitet (wegen -p), und da gibt's nicht mehr als ein Newline pro Zeile.

Machte man den gleichen Aufruf unter Windows, dann wuerde die ganze Datei als eine Zeile eingelesen (weil ja nach <CR><LF> als Zeilentrenner gesucht wird) und man braeuchte einen /g-Modifier, muesste aber auch die Ersetzung aendern oder die Datei im Binaermodus bearbeiten, da sonst aus "\r\n" die Bytefolge <CR><CR><LF> wuerde. Schliesslich wird jedes Newline beim Schreiben einer Textdatei unter Win/DOS in <CR><LF> gewandelt.

Tatsaechlich kann man dieses Verhalten unter Win/DOS ausnutzen und im Textmodus ersetzen:

Diese recht unverstaendliche Variante wandelt tatsaechlich die in der Datei vorhandenen einzelnen (und deshalb beim Einlesen nicht als Zeilenumbruch erkannten) <LF> in <CR><LF> um, auch wenn sie so aussieht, als taete sie gar nichts. (Diese Loesung hat sogar den kleinen Vorteil, dass man sie problemlos mehrfach auf eine Datei anwenden kann, ohne dass weitere <CR> eingefuegt werden. Das .bak ist noetig, da unter Windows irgendwie das in-place-edit nicht funktioniert.)

Wie man sieht, ist es eine schlechte Gewohnheit, das perl-interne Newline-Zeichen \n als Synonym fuer ein Linefeed \012 bzw. \cJ zu benutzen. Die bessere Schreibweise waere also:

oder auch

wobei das .bak und das /g nur unter Windows benoetigt werden, der Code aber sowohl unter Unix/Linux als auch Windows funktioniert.


Naeheres s. auch perlport, Abschnitt "Newlines"