[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-linux
Subject:    Re: CR und LF
From:       Bernhard Walle <Bernhard.Walle () gmx ! de>
Date:       2001-06-30 17:50:27
[Download RAW message or body]

Hallo,

On Sat, 30 Jun 2001 at 18:22 (+0200), Andreas Meyer wrote:
> Am Sam, 30 Jun 2001 schrieb Bernd Brodesser:
> 
> > Was soll man dazu sagen? Linux beendet so wie jedes UNIX eine Zeile
> > mit einem LF. Das heißt immer wenn in einem ASCII-File ein LF
> > auftaucht, wird dies als Zeilenumbruch interpretiert.
> > 
> > Wenn ich richtig liege, macht MAC das gleiche mit einem CR. DOS und
> > damit Windows bricht eine Zeile mit LF und einem CR um. Keine Ahnung
> > in welcher Reihenfolge. 
> 
> Ich bin da etwas irritiert! Ich habe diese Woche mal die Gelegenheit
> gehabt, in Word reinzuschnuppern und da gibt es angeblich zwei Arten
> von returns; einen Zeilenumbruch (automatisch) 

Automatisch heißt gar keinen. Natürlich wird die Zeile umgebrochen,
weil sie sonst nicht mehr aufs Papier passt. Wenn Du aber ein Wort
dazuschreibst, verschiebt er sich wieder. 

Dieses Konzept ist bei allen Textverarbeitungen gleich, hat also
nichts mit Windows oder sonstwas zu tun.

Was es noch gibt ist Shift-Return. Da wird eine neue Zeile
angefangen, nicht aber ein neuer Absatz. Das sind aber Befehle der
Textverarbeitung, hat nichts mit Betriebssystem oder System i. allg.
zu tun. Bei Win-Editoren oder -mailclients gibt's ja auch nur einen
Zeilenumbruch.

> und eine Hardreturn.
> Wobei mir der Unterschied erstmal nicht so klar ist, vom neuen
> Absatzbeginn abgesehen.

s. o.

> Lasse ich mir mit dem IE den source-code meiner Homepage anzeigen,
> dann erscheint der ganze code in zwei unendlich langen Zeilen.
> Das ist ja furchtbar.....

Liegt die HP auf der lokalen Festplatte? Dann ist alles klar: Da der
Linux/Unix-Zeilenumbruch nur \n ist, Windows aber \r\n erwartet,
geht's nicht. Der DOS-Editor kommt übrigens damit zurecht,
Windows-Notepad nicht.

Macht aber nichts, wenn die Seiten auf einem Webserver liegen: da im
"Textmodus" übertragen wird, wird der Code richtig angezeigt.
Deshalb sollten insbesondere Skripte über FTP immer im Textmodus
übertragen werden, weil sie sonst nicht interpretiert werden können!

> Mir ist auch schon aufgefallen, daß bei mails, die Leute hier mit
> outlook schreiben, die Zeilen auch nicht umgebrochen sind, oder
> zumindest nicht richtig.
> 
> Hat das damit was zu tun?

Nein. Das hat was damit zu tun, dass die Leute ihre Zeilen nicht
selber umbrechen und auch ihren Client nicht so eingestellt haben,
dass er das für sie erledigen würde. Outlook bricht nicht beim
Schreiben um sondern unmittelbar vor dem Senden, weshalb man das
Ergebnis des Umbruchs nicht mehr zu Gesicht bekommt und
Überraschungen erleben kann. Netscape macht das auch so, wenn auch
intelligenter, indem er zitierten Text *nicht* umbricht.


> > Vorteil von LF gegenüber CR gar keinen, gegenüber LF und CR ein
> > Zeichen weniger. Nachteil gibt es keinen.
> 
> Ich frage mich nur, wie der cursor bei einem LF dann weis, daß er an
> den nächsten linken Rand springen soll.
> Oder beim Mac er dann in die nächste Zeile wechselt, wenn kein LF
> ausgeführt wird und nicht in der gleichen Zeile wieder von links
> anfängt...

eigentlich: 
Zeilenumbruch = nächste Zeile anfang
\r = nur an Anfang, keine neue Zeile
\n = nur neue Zeile, nicht an Anfang

Unter Unix wird in Textdateien halt ein \n als ganzer Zeilenumbruch
interpretiert. Auf dem Mac hat ein \r. Richtig wäre so gesehen \r\n.
Man wollte wahrscheinlich ein wertvolles Byte einsparen, als man die
Regel aufgestellt hat.

Nur wo liegt das Problem?

Dass man Dateien vorher mit 

recode latin1..cp1252 <Datei> für Windows oder
recode latin1..ibmpc <Datei> für DOS oder OS/2
recode latin1..mac/CR <Datei> für MacOS

umwandeln muss? Klar, das nervt, aber was soll's.


Gruß,
Bernhard

-- 
-----------------------------------------------------------------
----->              http://www.linuxfreunde.de           <-------
-----------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]