[quote=J-jayz-Z,15.11.2005, 09:28]Auf der Konsole:
[/quote]
hast du das mal ausprobiert?
ich denke, du meinst
perl -pi -e's/\n/\r\n/' datei

[quote=pq,15.11.2005, 21:27][quote=J-jayz-Z,15.11.2005, 09:28]Auf der Konsole:
[/quote]
hast du das mal ausprobiert?
ich denke, du meinst
perl -pi -e's/\n/\r\n/' datei[/quote]
Was schreibe ich für ein Müll ... ?
es ist
Wobei das ohne |g ist, das es wirkt wie while(<>) und das nur Zeilenweise ausgibt. Und da jede Zeile nur ein Zeilenumbruch hat, hat sich das erledigt .

Nimm lieber -p statt -n, sonst hast Du nicht viel davon ;-)

[quote=J-jayz-Z,15.11.2005, 23:10][quote=pq,15.11.2005, 21:27]hast du das mal ausprobiert?
ich denke, du meinst
perl -pi -e's/\n/\r\n/' datei[/quote]
Was schreibe ich für ein Müll ... ?
es ist [/quote]
ähm, nein, ist es nicht... das gibt gar nichts aus und verändert auch die datei nicht.
-pi tut es, aber das schrieb ich ja schon.

wenn sie aus einem elf dump extrahiert können leicht auch mal EOL symbole mittendrin vorkommen, deswegen hab ich die version ohne regex favorisiert. mich würde auch interessieren wieso eure substitude ohne g auskommt?

[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"

ich hab es als hexdump verstanden der ja sehr gut beliebige bytewerte enthalten kann. und grade weil man die hinterher nicht von EOL unterscheiden kann muss man gleich beim generieren die "richtigen" EOL produzieren. da ja aber selbst beim einlesen unter win ja "fake-EOL" die in wirklichkein binärcode sind auftauchen können bräuchte man einen stärkeren EOL marker für das script das es dann weiterverarbeitet.

Also langsam frag ich mich, ob das Problem wirklich mit Perl zu tun hat. Wenn ich unter Linux eine Datei erzeuge, dann hat die halt die dort üblichen line endings. Wenn die Datei dann (im text mode) auf ein Windows-System übertragen wird, erledigt das Umsetzen normalerweise die Transfersoftware. Sogar ZIP-Software kann beim Extrahieren die line endings anpassen. Mein Editor kann das übrigens auch. Warum sollte man (oder Frau :D) sich also die Mühe machen, auf dem lokalen System schon die line endings eines Fremdsystems zu erzeugen?

Zugriff via samba? oder automatische synchronizer, die keinen textmodus verwenden?

ich habe mal ein stueck software, das sowohl unter linux/solaris als auch windows identisch laufen sollte und aus einer menge modulen bestand, komplett mit unix-zeilenendungen versehen, damit es sowohl unter windows als auch unter unix/linux einfach entpackt werden konnte und laeuft. Umgekehrt haette es zwar auch fast funktioniert (perl selbt haette das gefressen), aber der shebang nicht, und einen link auf den unix-systemen namens /usr/bin/perl<CR> wollte ich dann doch nicht anlegen ;-)

Manchmal ist es auch von Vorteil, dass Windoof keinen shebang kennt ;) .