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

* 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 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 <------- -----------------------------------------------------------------

On Sun, 01 Jul 2001 at 13:16 (+0200), Florian Gross wrote:

* Bernhard Walle 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.]

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

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]