Hallo! Es würde mich wirklich einmal interessieren, warum manche Systeme ein carriage-return und linefeed ausführen und andere nicht bzw. wo die Vor- und Nachteile liegen. Soviel ich weis, wird unter Linux nur ein LF ausgeführt? Kann mir das jemand kurz umschreiben? Gruß -- Andreas Meyer http://home.wtal.de/MeineHomepage
* Andreas Meyer schrieb am 30.Jun.2001:
Es würde mich wirklich einmal interessieren, warum manche Systeme ein carriage-return und linefeed ausführen und andere nicht bzw. wo die Vor- und Nachteile liegen. Soviel ich weis, wird unter Linux nur ein LF ausgeführt?
Ja, so ist es.
Kann mir das jemand kurz umschreiben?
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. Vorteil von LF gegenüber CR gar keinen, gegenüber LF und CR ein Zeichen weniger. Nachteil gibt es keinen. Bernd
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) und eine Hardreturn. Wobei mir der Unterschied erstmal nicht so klar ist, vom neuen Absatzbeginn abgesehen. 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..... 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?
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... Gruß -- Andreas Meyer http://home.wtal.de/MeineHomepage
From: "Andreas Meyer" <anmeyer@anup.de> Hallo,
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.
Mit "DOS und damit Windows" wäre ich aber vorsichtig. :-) In diesem Fall stimmts, aber beide OSse benutzen z.B. unterschiedliche Codepages. Unter Windows sind z.B. DOS-Umlaute im Ar...gen.
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) und eine Hardreturn. Wobei mir der Unterschied erstmal nicht so klar ist, vom neuen Absatzbeginn abgesehen.
das ist etwas ganz anderes. Diese Option bietet praktisch jede Textverarbeitung und jedes DTP-Programm. Wenn du z.B. eine Aufzählung machst, bei der vor jedem Absatz ein "- " oder ähnliches auftaucht, dann erscheint dieses Zeichen nur nach einem "harten" Return. mit einem "weichen" würdest du nur einen Absatz ohne Aufzählungszeichen machen. Beispiel: ------------------------ - Mein Problem: mein Rechner stürzt dauernd ab. - Meine Lösung: Servicepack 2741 ------------------------ Nach "Problem:" muß ein weicher Return kommen, sonst stände vor "mein Rechner" auch ein Aufzählungszeichen. Nach "dauernd ab" kommt ein harter Return, denn hier ist ein echter Absatz. Das nur als Beispiel. Es gibt sehr, sehr viele Beispiele, wo "Zeilenumbruch" etwas anderes bedeutet als "Absatzende": - Tabellen - erzwungene Trennungen in Editoren, die keine manuellen Trennvorschläge kennen. - Verwendung von Absatzstilen, die sich auf logische Absätze beziehen sollen . usw... usf... Da aber Word und Co weit mehr können, als in ASCII definiert ist, hat das mit unserer Frage nix zu tun. .DOC ist ein binäres Format und enthält sehr viel mehr als CR und LF-Formatierungen. Der Grund für die CR-LF-Codierung von Texten unter Windows ist ein "historisch korrektes" Verhalten. :-) Stell dir die ersten uralt-Terminals vor, die waren im Prinzip Ersatz für die Schreibmaschine. "Carriage Return" heisst "Wagenrücklauf", also das zurückschieben des Papierwäglechens nach rechts. Damit hast du aber noch nicht die Zeile gewechselt! Du brauchst also noch eine Zeile Vorschub: "Line Feed" - im Prinzip das gleiche wie "Cursor runter". Oder eben der Hebel an der Schreibmaschine. Da heute praktisch niemand mehr "dumme" ASCII-Drucker im Einsatz hat, ist das im Prinzip erledigt und es ist "egal", was ein OS sich da definiert. Es geht ja selten was direkt zum Drucker, ohne nicht irgendwelche PostScript-, GDI-, QuickDraw- oder sonstwas für Zwischenschritte zu durchlaufen. Brauchbare Texteditoren erkennen ohnehin beim Öffnen, welches Format der Text hat und sichern im selben. Wofür ich auch sehr dankbar bin, da ich desöfteren Texte auf dem Mac schreibe, sie durch Linux-Tools modifiziere und sie dann mit Windows vom Linux-Server hole und per ftp auf dem Unix-Webserver ablege. :-) Gruß, Ratti
* ratti schrieb am 30.Jun.2001:
Mit "DOS und damit Windows" wäre ich aber vorsichtig. :-) In diesem Fall stimmts, aber beide OSse benutzen z.B. unterschiedliche Codepages. Unter Windows sind z.B. DOS-Umlaute im Ar...gen.
Ja, klar. Das mit den DOS-Umlauten wußte ich noch nicht. Ich denke Linux ist so schrecklich, weil alle sich unterscheiden. Nun ja, daß das alles Blödsinn ist, ist mir natürlich klar, aber daß es im Gegenteil bei DOS/Windows so schlimm ist, war mir nicht bekannt.
Der Grund für die CR-LF-Codierung von Texten unter Windows ist ein "historisch korrektes" Verhalten. :-) Stell dir die ersten uralt-Terminals vor, die waren im Prinzip Ersatz für die Schreibmaschine.
So ein Teletype. Wann gab es die, und wann gab es ASCII? Hast Du da Ahnung von. So viel ich weiß, ist das schon eine ganze Weile her. Länger als es Computer gibt?
Da heute praktisch niemand mehr "dumme" ASCII-Drucker im Einsatz hat, ist das im Prinzip erledigt und es ist "egal", was ein OS sich da definiert. Es geht ja selten was direkt zum Drucker, ohne nicht irgendwelche PostScript-, GDI-, QuickDraw- oder sonstwas für Zwischenschritte zu durchlaufen.
Nun Linux hat das von UNIX geerbt und das gab es schon 1969. Viel früher als DOS und erst Recht Windows. Schon merkwürdig, daß DOS und Windows den Blödsinn immer noch machen. Bernd
Hallo, On Sat, 30 Jun 2001 at 19:36 (+0200), Bernd Brodeßer wrote:
* ratti schrieb am 30.Jun.2001:
Da heute praktisch niemand mehr "dumme" ASCII-Drucker im Einsatz hat, ist das im Prinzip erledigt und es ist "egal", was ein OS sich da definiert. Es geht ja selten was direkt zum Drucker, ohne nicht irgendwelche PostScript-, GDI-, QuickDraw- oder sonstwas für Zwischenschritte zu durchlaufen.
Nun Linux hat das von UNIX geerbt und das gab es schon 1969. Viel früher als DOS und erst Recht Windows. Schon merkwürdig, daß DOS und Windows den Blödsinn immer noch machen.
Wieso? Eigentlich verhält sich doch DOS korrekt: Wagenrücklauf *und* neue Zeile. In Internetprotokollen wird IIRC auch \r\n zur Übertragung verwendet. Gruß, Bernhard
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 <------- -----------------------------------------------------------------
* Bernhard Walle <Bernhard.Walle@gmx.de> textete am 30.06.01:
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.
Es ist halt ein optischer/virtueller Zeilenumbruch.
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.
Doch. Bearbeiten->Zeilenumbruch Dann wird am Fensterende umgebrochen. Nur mit dem Speichern sollte man da vorsichtig sein. cu flo --
PLONK Mach dir nichts draus! ich habe schon in so vielen Killfiles Überwintert und übersommert, das es bald gar nicht mehr Wahr sein dürfte. Dort ist es recht gemütlich. [WoKo in dag°]
On Sun, 01 Jul 2001 at 13:16 (+0200), Florian Gross wrote:
* Bernhard Walle <Bernhard.Walle@gmx.de> textete am 30.06.01:
On Sat, 30 Jun 2001 at 18:22 (+0200), Andreas Meyer wrote:
Am Sam, 30 Jun 2001 schrieb Bernd Brodesser:
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.
Doch. Bearbeiten->Zeilenumbruch Dann wird am Fensterende umgebrochen. Nur mit dem Speichern sollte man da vorsichtig sein.
Schön. Ich will aber nicht am Fensterende umbrechen sondern die UNIX-Zeilenumbrüche berücksichtigen. Gruß, Bernhard -- "Oh no, I'm sure nobody will even dare to think of writing this kind of HTML code!" [The KHTML team, shortly before the daily "reading bug reports hour" starts.]
* Bernhard Walle <Bernhard.Walle@gmx.de> textete am 01.07.01:
On Sun, 01 Jul 2001 at 13:16 (+0200), Florian Gross wrote:
* Bernhard Walle <Bernhard.Walle@gmx.de> textete am 30.06.01:
On Sat, 30 Jun 2001 at 18:22 (+0200), Andreas Meyer wrote:
Am Sam, 30 Jun 2001 schrieb Bernd Brodesser:
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.
Doch. Bearbeiten->Zeilenumbruch Dann wird am Fensterende umgebrochen. Nur mit dem Speichern sollte man da vorsichtig sein.
Schön. Ich will aber nicht am Fensterende umbrechen sondern die UNIX-Zeilenumbrüche berücksichtigen.
Dachte ich mir. ;-) cu flo -- Hallo Eugel Gutgut! Dieter Ist Doof! Ich bin Doof! Du bist Doof! Wir alle sind Doof! Willkommen im Klub der Doofen ! Tschau [WoKo in dag°]
Am Sam, 30 Jun 2001 schrieb Bernhard Walle: [snipp.... jede Menge input]
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.
"Interpretiert" bedeutet offenbar ein internes Verhalten einer shell; ist also anscheinend im code der shell verankert.
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.
ah, "recode", damit werde ich mich auch mal beschäftigen! Kann man ein "recode" nicht in den code einer shell gleich mit einbauen? :-) Gruß -- Andreas Meyer http://home.wtal.de/MeineHomepage
* Andreas Meyer schrieb am 01.Jul.2001:
Am Sam, 30 Jun 2001 schrieb Bernhard Walle:
[snipp.... jede Menge input]
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.
"Interpretiert" bedeutet offenbar ein internes Verhalten einer shell; ist also anscheinend im code der shell verankert.
Nö, ehr in sowas wie cat oder less. Aber ehr in ncurses, also alles was etwas auf dem Bildschirm oder auf einem Blatt Papier darstellt. Bernd -- LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo aufzurufen? Ist Deine /boot-Partition unter der 1024 Zylindergrenze? Bei anderen LILO Problemen mal in der SDB nachschauen: http://localhost/doc/sdb/de/html/rb_bootdisk.html |Zufallssignatur 6
On Sun, 01 Jul 2001 at 21:20 (+0200), Andreas Meyer wrote:
Am Sam, 30 Jun 2001 schrieb Bernhard Walle:
[snipp.... jede Menge input]
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.
"Interpretiert" bedeutet offenbar ein internes Verhalten einer shell; ist also anscheinend im code der shell verankert.
Nein. Auch ein Texteditor wie z. B. nedit macht das. Der braucht nun wirklich keine Shell, um funktioneren zu könnnen. Ich weiß nicht, wo dieses Verhalten festgelegt wird, vielleicht in irgendwelchen Libraries.
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.
ah, "recode", damit werde ich mich auch mal beschäftigen! Kann man ein "recode" nicht in den code einer shell gleich mit einbauen? :-)
Wieso? Was hätte das für Vorteile? Gruß, Bernhard -- "Never do today what you can postpone and do tomorrow." [David Faure, KDE-Entwickler]
participants (5)
-
Andreas Meyer -
B.Brodesser＠t-online.de -
Bernhard Walle -
Florian Gross -
ratti