\n wird wann genutzt?

Nein, '\n', bedeutet Newline. Suche mal nach "escape-sequences"

mil704e schrieb:
> Habe es probiert, scheint mir auf denh
> ersten Blick keinen funktionellen Unterschied zu machen.

zu was?
Wie ist der Unterschied einer Brücke?

\n heisst nur newline, von CR ist da nicht mal die Rede!

Auf jeder Schreibmaschine konnte ich neue Zeilen beginnen, auch ohne 
Wagenrücklauf. Wer eine neue Zeile mit Wagenrücklauf möchte muss das 
bestellen, also /r/n mit CR und LF, nur die Linuxwelt sieht das anders, 
sie kennen wohl keine Schreibmaschinen.

Zugegeben als Byte noch knapp waren sparten sie ein Zeichen, aber heute 
ist die Zweigleisigkeit ein Anachronismus von alten Sturköpfen und 
keiner will nachgeben, das braucht man nicht.
Mich ärgert es immer wenn ich zwischen den Welten wandel

was sehe ich an Steuerzeichen?
CR CRLF CR CRLF

und muss immer von den doppelten CR eines rauswerfen!
Wie kommt man darauf das CR automatisch LF beinhaltet?
LF nur wenn LF drin sein soll!
CR nur wenn CR bestellt wurde!

1

 Remarks:        

2

3

 known Problems: none

4

5

 Version:

Joachim B. schrieb:
> \n heisst nur newline, von CR ist da nicht mal die Rede!

Nicht in C. Da bedeutet es einen Sprung an den Anfang der nächsten 
Zeile.

> Auf jeder Schreibmaschine konnte ich neue Zeilen beginnen, auch ohne
> Wagenrücklauf.

Und, wie oft hast du das benutzt?

> Wer eine neue Zeile mit Wagenrücklauf möchte muss das bestellen, also /r/n
> mit CR und LF,

Wenn man unter CP/M oder ursprünglich darauf basierenden Systemen 
arbeitet und die Ausgabe nicht im Text-, sondern im Binärmodus 
geöffnet hat.
Übrigens: Auf dem Mac ist es nochmal anders.

> nur die Linuxwelt sieht das anders, sie kennen wohl keine Schreibmaschinen.

Das ist in C Standard. Der Ausgabestream kümmert sich darum, im Falle 
des Textmodus das \n in das systemspezifische Zeilenende zu 
konvertieren.

> Zugegeben als Byte noch knapp waren sparten sie ein Zeichen, aber heute
> ist die Zweigleisigkeit ein Anachronismus von alten Sturköpfen und
> keiner will nachgeben, das braucht man nicht.

Zu denen gehörst du offenbar auch.

> Wie kommt man darauf das CR automatisch LF beinhaltet?
> LF nur wenn LF drin sein soll!
> CR nur wenn CR bestellt wurde!

Wozu braucht man eigentlich in einem Terminal - oder von mir aus auch 
einem Drucker einen Zeilenvorschub ohne Wagenrücklauf? Ich muss sagen, 
ich hab das in >30 Jahren an Programmierung nicht einmal benötigt.

mil704e schrieb:
> vielen Dank für die schnelle Rückmeldung. ich hatte nur diesen Auschnitt
> (siehe Anhang) zur verfügung.

Wie kommst du von der Aussage auf dem Bild zu

mil704e schrieb:
> Es heißt ja,
> dass der Courser durch \n an das Ende der ausgabe gesetzt wird.

?

Das steht da nicht.

Rolf M. schrieb:
> Wozu braucht man eigentlich in einem Terminal - oder von mir aus auch
> einem Drucker einen Zeilenvorschub ohne Wagenrücklauf? Ich muss sagen,
> ich hab das in >30 Jahren an Programmierung nicht einmal benötigt.

und ich ärgere mich in den meisten Terminal Programmen über 
selbstständige LF wenn ich nur eine Ausgabezeile neu printen will ohne 
Zeilenvorschub, es ging sogar mal soweit das ich mit ESc backspace 
gemacht hatte um LF zu vermeiden!

Rolf M. schrieb:
> Zu denen gehörst du offenbar auch.

stur sind die die alles gutheissen wollen auch das Festhalten an den 
Unterschieden!
Ich habe jedenfalls immer Mehrarbeit um Quelltexte wieder lesbarer zu 
machen und überfüssige LF zu entfernen die nur auf einem CR beruhen!

Joachim B. schrieb:
> Rolf M. schrieb:
>> Wozu braucht man eigentlich in einem Terminal - oder von mir aus auch
>> einem Drucker einen Zeilenvorschub ohne Wagenrücklauf? Ich muss sagen,
>> ich hab das in >30 Jahren an Programmierung nicht einmal benötigt.
>
> und ich ärgere mich in den meisten Terminal Programmen über
> selbstständige LF wenn ich nur eine Ausgabezeile neu printen will ohne
> Zeilenvorschub,

Ja, so herum sehe ich durchaus einen Sinn. Aber hier ging es um die 
umgekehrte Variante, also Vorschub, ohne an den Anfang der Zeile zu 
gehen. Für die fällt mir kein vernünftiger Anwendungsfall ein.

> Rolf M. schrieb:
>> Zu denen gehörst du offenbar auch.
>
> stur sind die die alles gutheissen wollen auch das Festhalten an den
> Unterschieden!

Naja, du scheinst zumindest an einer bestimmten Variante unbedingt 
festhalten zu wollen. Wenn das die "Gegenseite" auch tut, dann kommt 
eben genau das raus.

> Ich habe jedenfalls immer Mehrarbeit um Quelltexte wieder lesbarer zu
> machen und überfüssige LF zu entfernen die nur auf einem CR beruhen!

Dann nutzt du den falschen Editor. Meiner schaltet wahlweise automatisch 
um oder konvertiert es optional gleich automatisch in das, was ich haben 
will. Und wenn man seinen Quellcode mit Tools wie svn oder git 
verwaltet, konvertieren die es einem schon passend.

Rolf M. schrieb:
> Und wenn man seinen Quellcode mit Tools wie svn oder git
> verwaltet, konvertieren die es einem schon passend.

ich nutze notepad++ was ist daran falsch wenn der Code einem über ein 
Linux NAS lief per FTP

die zusätzlichen CR waren NICHT im Quellcode, ich weiss ja was ich 
hochgeladen hatte.
Aber schön das du dem Anwender also mir die Schuld geben kannst, alle 
anderen können es eh besser.

Joachim B. schrieb:
> Rolf M. schrieb:
>> Und wenn man seinen Quellcode mit Tools wie svn oder git
>> verwaltet, konvertieren die es einem schon passend.
>
> ich nutze notepad++ was ist daran falsch wenn der Code einem über ein
> Linux NAS lief per FTP

Ob das NAS unter Linux läuft, hat doch nichts damit zu tun, mit welchen 
Zeilenenden dein Editor den Code abspeichert. Bei FTP muss man aber ggf. 
aufpassen. Das kennt einen Textmodus, in dem es die Zeilenenden 
konvertiert und einen Binärmodus, in dem es alle Daten 1:1 durchreicht.
Aber generell würde ich keine Software mehr entwickeln ohne ein 
gescheites Versionierungstool. Das ist für mich seit vielen Jahren 
Grundvoraussetzung.

> die zusätzlichen CR waren NICHT im Quellcode, ich weiss ja was ich
> hochgeladen hatte.

Das heißt, du lädst Dateien auf dein NAS hoch, und wenn du sie wieder 
runterlädst, haben sich die Zeilenenden geändert? Dann stimmt entweder 
mit dem FTP was nicht oder wie schon gesagt mit dem Editor.

> Aber schön das du dem Anwender also mir die Schuld geben kannst, alle
> anderen können es eh besser.

Ich hab meinen Text nochmal durchgelesen, und ich kann nicht erkennen, 
wo ich dir die Schuld an irgendwas gegeben hätte. Lediglich deinem 
Editor habe ich die Schuld gegeben.

Rolf M. schrieb:
> Wozu braucht man eigentlich in einem Terminal - oder von mir aus auch
> einem Drucker einen Zeilenvorschub ohne Wagenrücklauf?

Das benötigt man in einem Text-Editor, der den Cursor genau eine Zeile 
unter Beibehaltung der Spalte tiefer setzen will. Okay, es gibt auch die 
Möglichkeit, die Escape-Sequenz für Cursor-Down zu schicken.

Aber man muss das ganze auch mal etwas globaler sehen, es gibt ja nicht 
nur Terminals und Drucker, sondern auch Dateien.

Unter Unix (da kommt ja C her) braucht man in Text-Dateien nur ein '\n', 
auf einem Terminal oder Drucker aber ein '\r\n'. Daher wird der Output 
von '\n' auf Terminals wegen ONLCR gemappt auf '\r\n'. So ist es einem 
C-Programmierer vollkommen egal, ob sein Output auf ein Terminal oder 
eine Datei umgelenkt wird, er braucht nur ein '\n' zu schicken. Auf dem 
Terminal kommt ein '\r\n' an, in der Datei nur ein '\n', weil das bei 
Unix vollkommen reicht.

Unter Windows, wo bei Text-Dateien jedoch auch ein '\r\n' erforderlich 
ist, mappt das C-Runtime-System das '\n' ebenso auf '\r\n', so dass auch 
hier der C-Programmierer nur ein '\n' ausgeben braucht.

Das Ganze wird also portabel an das jeweilige Output-Gerät oder die 
Text-Datei des jeweiligen Betriebssystems angepasst.

Ausnahmen bestätigen die Regel:

Man kann unter Unix auch ein TTY in den "Raw-Modus" versetzen, so dass 
tatsächlich zwischen '\n' und '\r' unterschieden wird. Sinnvoll ist das 
bei dem oben angeführten Beispiel des Text-Editors. Diese nutzen das 
natürlich.

Anderes Beispiel ist das Schreiben in Binärdateien: Hier kann der 
Programmierer ebenso gezielt dafür sorgen, dass kein Mapping vorgenommen 
wird, wenn er ein '\n' schreibt. Das ist für Unix irrelevant: Unix 
unterscheidet hier nicht zwischen Text- und Binärdateien, Windows jedoch 
schon.