ubuntuusers.de

Es heisst, dass Editoren die Zeichenkombination \n interpretieren um Zeilenumbrüche machen.

Ich nutze Featherpad und dieser Editor macht Zeilenumbrüche wenn ich "Enter" drücke. Gemäss obigem Statement hätte ich jetzt erwartet, dass Featherpad auch Zeilenumbrüche machen würde, wenn ich Featherpad normal öffne und einen Text wie den folgenden eintippe:

aaaaaa   \n bbbbbb \n cccccccc

Wenn ich jetzt Featherpad schliesse und wieder öffne, hätte ich erwartet, dass er den Text mit 2 Zeilenumbrüchen anzeigt:

aaaaaa
bbbbbb
cccccccc

Weshalb macht es das nicht?

Bitte beachten: Das ist eine reine Interessenfrage.

(Zusatzfrage: Ist es ein Unterschied in Featherpad, ob ich einen Zeilenumbruch mit Shift+Enter oder nur mit Enter mache?)

Eine Antwort würde mich freuen. Besten Dank.

Ich kenne Featherpad nicht, aber jeder normale Editor hat eigentlich die Aufgabe, das Zeug genau so zu speichern wie du es eingegeben hast, und nicht willkürlich nach Speichern Schließen Neuladen, auf einmal was ganz anderes anzuzeigen.

Wenn \n zum Zeilenumbruch wird, darfst du ansonsten auch jeden anderen \ als \\ schreiben. Und wenn bei jedem Speichern, Laden eine \ Ebene wegfallen würde, hättest du bei \\\\n dann nach zweidreimal Speichern auf einmal einen Zeilenumbruch (\\\\n wird zu \\n wird zu \n wird zum Zeilenumbruch). Das kann so normalerweise nicht funktionieren.

Manchmal landet man bei Programmiersprachen, oder in Shellscripten, in so einer Escapehölle weil jeder Zwischenschritt dir ein paar von den \ Escapes wegfrisst. Im Texteditor will man das lieber nicht haben.

Das Shift+Enter kommt meist von WYSIWYG/HTML-Editoren her, die unterscheiden zwischen <p> (Absatz) und <br> (Zeilenumbruch). Enter und Shift+Enter ist dann jeweils das eine oder das andere. Bei Plaintext gibts hier keine semantische Unterscheidung und man macht für Absätze ggf. eben zwei Zeilenumbrüche.

Danke.

Ich denke ich weiss jetzt, wieso meine normal im Editor eingegebenen Zeichen "\n" nicht als Zeilenumbruch interpretiert werden, wenn ich den Texteditor schliesse und wieder öffne.

Wenn ich \n im Texteditor eintippe, speichert Featherpad das Zeichen "\" als 4-stelligen Hexadezimalcode "005c" und "n" als 4-stelligen Hexadezimalcode "006e" .

Wenn ich hingegen "Enter" drücke speichert Featherpad das "entstandene Zeichen" als 4-stelligen Hexadezimalcode "000a" ab.

Auf diese Weise kann Featherpad beim öffnen die beiden Sachen auseinander halten.

Ich glaube nicht das Featherpad das macht. Wie kommst Du darauf? Da könnte ja kein anderes Programm als Featherpad etwas mit anfangen.

Kann es sein, dass Du den Text in UTF-16-Kodierung gespeichert hast, und ein anderes Programm zum Anzeigen verwendest, dass die Bytes/Words dann in einer Hexadezimaldarstellung anzeigt‽

Es heisst, dass Editoren die Zeichenkombination \n interpretieren um Zeilenumbrüche machen.

Ein normaler Editor macht so etwas nicht. Im Prinzip wurde das auch schon gesagt.

Aber, wenn du jetzt einen Text erzeugen willst, der von einem anderen Programm weiter verarbeitet werden soll, z.B. weil das ein Shellscript oder für einen Compiler ist, sieht das etwas anders aus. Nämlich wenn das andere Programm einen Text ausgeben soll, der Zeilenumbrüche enthält. Dann muss es eine Möglichkeit geben, den Zeilenumbruch so weiter zu geben, dass dein Eingegebener Text davon nicht betroffen ist. Die Zeichekombination "\n" wird erst von den weiterverarbeitenden Programmen interpretiert.

Mal ein fiktives Beispiel:

print "Tolles Programm - Version: 0.0 \u00A9 by Noboddy\n"

Man kann bei vielen Editoren so auch viele Unicode Zeichen eingeben, wenn man deren Hex Codierung kennt. Im Beispiel ist dass das Copyright Zeichen, welches dann in UTF-8 Codierung umgesetzt wird.

Tolles Programm - Version: 0.0 © by Noboddy
 

Wie der Text hinter dem "\" interpretiert wird, ist von dem Programm abhängig, das diesen Text vorgesetzt bekommt.

Wie kommst Du darauf?

Weil der Hexadezimalcode für "\" 005c oder 5c ist (https://www.compart.com/de/unicode/U+005C) und der Hexadezimalcode für "n" 006c oder 6c ist (https://www.compart.com/de/unicode/U+006E)und weil der Hexadezimalcode für Zeilenumbruch 0a oder 000a ist (https://codepoints.net/U+000A?lang=de)

Da könnte ja kein anderes Programm als Featherpad etwas mit anfangen.

Obiges gilt wohl für die meisten Texteditoren. Deshalb sind die Textdateien dann austauschbar.

Verwirrt und zu diesem Post veranlasst (Post#1) hat mich folgender Linux-bash-Code:

1
2
3

line="abc"
content="$line"$'\n'
echo -e "$content"  # Ergebnis: abc, mit einem Zeilenumbruch

Und dort "\n" in ...

1

content="$line"$'\n'

Aber inzwischen denke ich, dass eben gar kein "\n" eingefügt wird, sondern nur der Hexadezimalcode für Zeilenumbruch: 0a.

Edit: Sorry: Dakuan: Post-Crossing

Edit2:

Es heisst, dass Editoren die Zeichenkombination \n interpretieren um Zeilenumbrüche machen.

Ja das ist wohl falsch. Wie gesagt die Zeile "content="$line"$'\n'" hat mich verwirrt. \n heisst dort wohl in Wirklichkeit nicht \n . Das ist eine falsche Fährte in diesem Codebruchstück.

Der Shell Befehl "echo" ist, glaube ich, kein gutes Beispiel. Denn der hängt normalerweise immer einen Zeilenwechsel hinten drann. Wenn man den nicht haben will, kann man den mit der Option "-n" abschalten.

Und die gezeigten Hex Codes sind eigentlich die normalen ASCII Codes für diese Zeichen. Die werden bei UTF-x Codierung einfach übernommen und weiter gereicht. Entscheidend ist, wie der Empfänger das interpretiert/auswertet.

Es gibt übrigens noch mehr solcher "magischen" Sequenzen:

• \\ der Backslash selber

• \r Cursor (Wagen) Rücklauf (für mechanische Geräte)

• \t TAB

das sind die, sie mir gerade einfallen. Wenn du nur einfache Texte schreibst, brauchst du die aber nicht.

Es gibt übrigens noch mehr solcher "magischen" Sequenzen:

• \\ der Backslash selber

• \r Cursor (Wagen) Rücklauf (für mechanische Geräte)

• \t TAB

Gut dass du die erwähnst, das könnte mir noch nützlich sein.

@Umaash Was der Unicode-Codepoint für eine Hexadezimaldarstellung sagt nicht was in der Datei gespeichert wird. Das wird durch die Kodierung bestimmt in der ein Text gespeichert wird. Und das ist nicht die vierstellige Hexadezimaldarstellung von Unicode-Codepoints. Damit könnte kein Programm etwas anfangen. Zumal man die Zeichen für die Hexadezimaldarstellung auch wieder in irgendeiner Zeichenkodierung speichern müsste.

Bei dem Shell-Beispiel wird tatsächlich die Zeichenfolge Backslash und n in der Datei gespeichert. Wenn die Bash das *interpretiert* macht sie daraus ein Zeilenende-Zeichen. Wobei da das Dollarzeichen auch noch wichtig ist:

$ echo 'a\nb'
a\nb
$ echo $'a\nb'
a
b

Danke für den Hinweis. Interessant!

Aber dann verstehe ich das nicht:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

$ line=a
$ Var=""
$ Var+="$line"$'\n'
$ line='\n'
$ echo $line
\n
$ Var+="$line"$'\n'
$ line=b
$ Var+="$line"$'\n'
$ echo $Var
a \n b

3x füge ich hier \n in den Zeilen "$ Var+="$line"$'\n'" ein. Und 1x füge ich hier \n in der Zeile "$ Var+="$line"$'\n'" ein, nachdem $line mit \n befüllt wurde.

Der Output ganz am Schluss ist: a \n b

Das habe ich nicht erwartet. Wir haben jetzt in $Var total 4x \n drin. Also hätte ich am Schluss folgenden Output erwartet:

1

a\n\n\nb\n

Du quotest die Variable, die du an echo übergibst nicht - dadurch erlaubst du der Bash deren Inhalt am IFS aufzutrennen (das umfasst standardmäßig alle ASCII-Whitespace Zeichen, also u.a. Spaces, Tabs, Newlines) - dadurch bekommt echo mehrere Argumente übergeben, die es bei der Ausgabe mit einzelnen Spaces zusammenklebt - wenn man korrekt quotet, bekommt man das dazu passende Ergebnis (0x20 is ein Space, 0x0a ein Newline Zeichen, xxd lässt den 0x Teil der Hex-Werte für die Bytes weg):

1
2
3
4
5
6
7
8
9

$ echo $Var | xxd -g1
00000000: 61 20 5c 6e 20 62 0a                             a \n b.
$ echo "$Var"
a
\n
b

$ echo "$Var" | xxd -g1
00000000: 61 0a 5c 6e 0a 62 0a 0a                          a.\n.b..

Marc_BlackJack_Rintsch schrieb:

Wobei da das Dollarzeichen auch noch wichtig ist:

Ist dafür nicht eigentlich die Option -e gedacht?
▶ echo

Ich zögere immer ein wenig, alles mit dem Dollar-Zeichen zu erschlagen, das hat auch so schon zu viele unterschiedliche Bedeutungen: Variablenkenner, Befehlssubstitution und Zeilenende – das sind schon mal drei verschiedene Funktionen, die mir auf Anhieb einfallen. Sicherlich fallen mir bei weiterem Nachdenken noch mehr ein.

@seahawk1986:

$ echo "$Var" | xxd -g1
00000000: 61 0a 5c 6e 0a 62 0a 0a                          a.\n.b..

Das Ergebnis verstehe ich gerade irgendwie nicht so ganz. Es geht doch um den folgenden Ausdruck:

a\n\n\nb\n

Wenn ich also versuche, deinen Beitrag nachzuvollziehen, kommt bei mir das heraus:

09:37 ~$ echo "$var"
a\n\n\nb\n
________
09:37 ~$ echo "$var" | xxd -g1
00000000: 61 5c 6e 5c 6e 5c 6e 62 5c 6e 0a                 a\n\n\nb\n.
________
09:42 ~$

und

09:49 ~$ echo -e "$var" | xxd -g1
00000000: 61 0a 0a 0a 62 0a 0a                             a...b..
________
09:50 ~$

Danke @seahawk1986 für den Befehl xxd -g1 . Den kannte ich natürlich nicht. Eigentlich war ich auch auf der Suche, nach einem Befehl, der mir wirklich anzeigt, was irgendwo drin ist. Ich habe immer gedacht, dass in einer Variable oder in einer Datei tatsächlich byte für byte ein bestimmtes Zeichen drin ist.

Z.B.

– das Zeichen für "a" oder

– das Zeichen für den Zeilenumbruch oder

– das Zeichen "\" oder das Zeichen "n".

Und nun war ich der Überzeugung, dass der Befehl "xxd -g1" der Befehl ist, mit dem man aus einer Variablen auslesen kann, was wirklich drin ist. OK. Aber der Befehl "xxd -g1" gibt mir ja gar nicht das aus, was wirklich drin ist (in diesem Fall soll 'a\nb' den Variableninhalt simulieren). Sondern dieser Befehl gibt mir ja auch nur aus, was "echo" aus dem Inhalt der Variable gemacht hat. Und nicht das, was ursprünglich drin war.

Das wurde mir bei folgendem Code bewusst:

1
2
3
4
5

$ echo 'a\nb' | xxd -g1
00000000: 61 5c 6e 62 0a                                   a\nb.
D-Konto@mx:~
$ echo $'a\nb' | xxd -g1
00000000: 61 0a 62 0a                                      a.b.

Umaash schrieb:

Sondern dieser Befehl gibt mir ja auch nur aus, was "echo" aus dem Inhalt der Variable gemacht hat. Und nicht das, was ursprünglich drin war.

Natürlich. Der Befehl echo ... | schickt die Ausgabe, die normalerweise auf dem Bildschirm erscheint, in die Pipe, und xxd liest nur diese Ausgabe auf der anderen Seite der Pipe wieder aus.

Nachtrag: Du kannst die Variable aber auch direkt auslesen:

1
2
3

$ xxd -g1 <<< "$var"
00000000: 61 5c 6e 5c 6e 5c 6e 62 5c 6e 0a                 a\n\n\nb\n.
$ 

▶ zur Pipe

▶ Daten einlesen