Welche Bedeutung hat das Protokoll „Kein Zeilenumbruch am Dateiende“?

Lesezeit: 8 Minuten

Welche Bedeutung hat das Protokoll „Kein Zeilenumbruch am Dateiende
Schrittmacher

Wenn Sie a git diff es sagt “Kein Zeilenumbruch am Dateiende”.

Welche Bedeutung hat die Botschaft und was will sie uns sagen?

  • Wenn Sie eine Datei haben, die ohne Zeilenumbruch endet, und Sie eine weitere Zeile hinzufügen, müsste git vielleicht zeigen, dass sich die vormals letzte Zeile geändert hat, da sie das Zeilenumbruchzeichen als Teil der Zeile enthält?

    – nö

    13. April 2014 um 21:20 Uhr

Es zeigt an, dass Sie keinen Zeilenumbruch haben (normalerweise '\n'auch bekannt als CR oder CRLF) am Ende der Datei.

Das heißt, einfach gesagt, das letzte Byte (oder Bytes, wenn Sie Windows verwenden) in der Datei ist kein Zeilenumbruch.

Die Meldung wird angezeigt, weil es sonst keine Möglichkeit gibt, den Unterschied zwischen einer Datei mit einem Zeilenumbruch am Ende und einer Datei ohne Zeilenumbruch zu erkennen. Diff muss sowieso einen Zeilenumbruch ausgeben, sonst wäre das Ergebnis schwieriger zu lesen oder automatisch zu verarbeiten.

Beachten Sie, dass es ein guter Stil ist, den Zeilenumbruch immer als letztes Zeichen einzufügen, wenn das Dateiformat dies zulässt. Außerdem wird es beispielsweise für C- und C++-Header-Dateien vom Sprachstandard gefordert.

  • Können Sie aus Neugierde erklären, warum es als guter Stil angesehen wird, immer einen Zeilenumbruch als letztes Zeichen zu setzen? Edit: Habe diese Diskussion gefunden.

    – Paul Bellora

    16. November 2012 um 20:27 Uhr


  • @PaulBellora Historisch gesehen war dies eine Entscheidung des C-Sprachstandards stackoverflow.com/a/729725/233098 Praktisch, weil viele Unix-Tools dies für die ordnungsgemäße Anzeige von stackoverflow.com/a/729795/233098 erfordern oder erwarten. Da jede Zeile in einer Textdatei mit einem “Ende-der-Zeile”-Zeichen endet, sollte philosophisch gesehen die letzte Zeile keine Ausnahme sein. Wenn wir es anders betrachten, untersuchen wir die Umkehrung. Wenn anstelle von „Zeilenende“ eine „Zeilenanfangs“-Markierung vorhanden wäre, würden Sie das „Zeilenanfangs“-Zeichen in der ersten Zeile weglassen?

    – Jo

    24. April 2014 um 3:50 Uhr


  • @Joe Das macht nicht so viel Sinn. Ein Zeilenumbruch ist ein Neue Zeile, dh das Trennzeichen zwischen Zeilen, kein Zeilenende. Wir haben keine Zeilenanfangszeichen, weil sie nicht notwendig sind. Aus dem gleichen Grund haben wir keine Zeilenendezeichen.

    – ach ja

    19. September 2014 um 1:59 Uhr

  • @acjay Ich behaupte, dass zwischen “Trennzeichen zwischen Zeilen” und “Zeilenende” von Natur aus besser ist. Keine der Ansichten ist von Natur aus richtig oder falsch, sondern nur eine Möglichkeit, sie zu betrachten. Ich schlage vor, dass wir weiterhin den historisch praktischen Standpunkt verwenden, da wir es bereits so und so machen tut Sinn machen, wenn du es akzeptierst. Konsistenz ist wichtig. Es besteht keine Notwendigkeit, dies im Namen des Standpunkts “das Trennzeichen zwischen den Linien” zu brechen.

    – Jo

    19. September 2014 um 16:18 Uhr

  • @WORMSS „Neu für mich“ ist nicht dasselbe wie „eine neue Konvention“. Das ist genauso, als würde man jede andere Art von Programmierkonvention entdecken. Du gehst einfach mit. Sie könnten abweichen, aber du isolierst dich nur. (Oder in diesem Fall tatsächlich Tools zu brechen.) Denken Sie darüber nach, wie viele andere eine Rails-Konvention oder PEP8 entdeckten und wie konsistent diese Communities als Ganzes blieben, weil sie nachgaben – obwohl sie gegenteiligen Code geschrieben hatten.

    – Jo

    18. Dezember 2014 um 1:42 Uhr

Dies ist nicht nur schlechter Stil, sondern kann auch zu unerwartetem Verhalten führen, wenn andere Tools für die Datei verwendet werden.

Hier ist test.txt:

first line
second line

Die letzte Zeile enthält kein Zeilenumbruchzeichen. Mal sehen, wie viele Zeilen in der Datei sind:

$ wc -l test.txt
1 test.txt

Vielleicht ist es das, was Sie wollen, aber in den meisten Fällen würden Sie wahrscheinlich erwarten, dass die Datei 2 Zeilen enthält.

Auch wenn Sie Dateien kombinieren wollten, verhält es sich möglicherweise nicht so, wie Sie es erwarten würden:

$ cat test.txt test.txt
first line
second linefirst line
second line

Schließlich würde es Ihre Diffs etwas lauter machen, wenn Sie eine neue Zeile hinzufügen würden. Wenn Sie eine dritte Zeile hinzugefügt haben, wird sowohl eine Bearbeitung der zweiten Zeile als auch die neue Hinzufügung angezeigt.

  • Das Ergebnis von cat ist in Ordnung, aber der wc-Parameter “-l, –lines” ist einfach falsch. Sogar das Handbuch sagt “drucke die Zeilenumbrüche” und nicht “drucke die Zeilenzahlen”.

    – Der unglaubliche Jan

    13. Februar 2019 um 7:20 Uhr

  • Und ich kann dies (wc und cat) nicht einmal mit aktuellem util linux (util-linux 2.34) reproduzieren.

    – wget

    1. Oktober 2019 um 10:40 Uhr

  • @wget Ich bin auf util-linux 2.34 und kann bestätigen, dass das, was diese Antwort beschreibt, das aktuelle Verhalten ist. Ich vermute, dass Ihr Editor das Zeichen “\n” hinzugefügt hat.

    – stephanos

    27. Dezember 2019 um 11:36 Uhr

  • @TheincredibleJan Jede Zeile endet mit a '\n'. Es ist keine Linie, wenn es keine gibt '\n'. Die -l --lines Argument ist absolut richtig.

    – 12431234123412341234123

    4. März 2021 um 18:16 Uhr


1646258890 672 Welche Bedeutung hat das Protokoll „Kein Zeilenumbruch am Dateiende
Jaseem

Wenn Sie hinzufügen eine neue Textzeile am Ende der bestehenden Datei, die noch keine hat newline character Am Ende zeigt das Diff die alte letzte Zeile als geändert an, obwohl dies konzeptionell nicht der Fall war.

Dies ist mindestens ein guter Grund, a hinzuzufügen newline character Am Ende.

Beispiel

Eine Datei enthält:

A() {
    // do something
}

Hexdump:

00000000: 4128 2920 7b0a 2020 2020 2f2f 2064 6f20  A() {.    // do 
00000010: 736f 6d65 7468 696e 670a 7d              something.}

Sie bearbeiten es jetzt zu

A() {
    // do something
}
// Useful comment

Hexdump:

00000000: 4128 2920 7b0a 2020 2020 2f2f 2064 6f20  A() {.    // do 
00000010: 736f 6d65 7468 696e 670a 7d0a 2f2f 2055  something.}.// U
00000020: 7365 6675 6c20 636f 6d6d 656e 742e 0a    seful comment..

Das Git-Diff zeigt:

-}
\ No newline at end of file
+}
+// Useful comment.

Mit anderen Worten, es zeigt einen größeren Unterschied als konzeptionell aufgetreten ist. Es zeigt, dass Sie die Zeile gelöscht haben } und fügte die Zeile hinzu }\n. Das ist in der Tat passiert, aber es ist nicht das, was konzeptionell passiert, also kann es verwirrend sein.

  • Wir können dasselbe in die andere Richtung schreiben: Wenn Sie eine neue Zeile am Ende der vorhandenen Datei entfernen, die bereits einen Zeilenumbruch am Ende hat, zeigt das Diff die alte letzte Zeile auch als geändert an, obwohl dies konzeptionell nicht der Fall ist. Mindestens ein guter Grund, einen Zeilenumbruch am Ende zu entfernen.

    – Enzian

    8. September 2016 um 9:12 Uhr


  • @gentiane Du verwechselst “eine neue Zeile” (eine neue Zeile) und “eine neue Zeile” (1 oder 2 Zeichen, die das Ende einer Zeile begrenzen)

    – Minexew

    6. Januar 2017 um 17:00 Uhr

  • @minexew Nein, Enzian ist es nicht. Vielleicht ist Ihnen einfach nicht klar, dass “eine neue Zeile” dasselbe ist wie “eine neue Zeile”.

    – Der unglaubliche Jan

    13. Februar 2019 um 7:24 Uhr

  • @TheincredibleJan So wie sie in der Antwort verwendet werden, haben die beiden Begriffe unterschiedliche Bedeutungen. Ich weiß nicht, ob Sie versuchen, ein Klugscheißer zu sein, oder einfach nur falsch verstehen, was vor sich geht.

    – Minexew

    14. Februar 2019 um 21:59 Uhr

  • @minexew ich verstehe dich nicht und gentiane hat recht.

    – Der unglaubliche Jan

    13. Oktober 2020 um 7:11 Uhr

Der einzige Grund ist, dass Unix historisch eine Konvention für alle menschenlesbaren Textdateien hatte, die mit einem Zeilenumbruch enden. Dies vermied damals eine zusätzliche Verarbeitung beim Anzeigen oder Verbinden von Textdateien und verhinderte, dass Textdateien anders behandelt wurden als Dateien, die andere Arten von Daten enthielten (z. B. binäre Rohdaten, die nicht für Menschen lesbar sind).

Aufgrund dieser Konvention erwarten viele Tools aus dieser Zeit den Zeilenumbruch am Ende, darunter Texteditoren, Vergleichstools und andere Textverarbeitungstools. Mac OS X wurde auf BSD Unix aufgebaut und Linux wurde so entwickelt, dass es Unix-kompatibel ist, sodass beide Betriebssysteme die gleiche Konvention, das gleiche Verhalten und die gleichen Tools geerbt haben.

Windows wurde nicht so entwickelt, dass es Unix-kompatibel ist, daher hat es nicht die gleiche Konvention, und die meiste Windows-Software kommt ohne nachgestellten Zeilenumbruch gut zurecht.

Da Git jedoch zuerst für Linux entwickelt wurde und viele Open-Source-Software auf Unix-kompatiblen Systemen wie Linux, Mac OS X, FreeBSD usw. basiert, werden die meisten Open-Source-Communities und ihre Tools (einschließlich Programmiersprachen) weitergeführt diesen Konventionen zu folgen.

Es gibt technische Gründe, die 1971 Sinn machten, aber in dieser Zeit sind es hauptsächlich Konventionen und die Aufrechterhaltung der Kompatibilität mit bestehenden Tools.

Es zeigt nur an, dass das Ende der Datei keinen Zeilenumbruch hat. Es ist keine Katastrophe, sondern nur eine Nachricht, um klarer zu machen, dass es keine gibt, wenn man sich einen Unterschied in der Befehlszeile ansieht.

Welche Bedeutung hat das Protokoll „Kein Zeilenumbruch am Dateiende
Leslie Krause

Der Grund, warum diese Konvention in die Praxis umgesetzt wurde, liegt darin, dass auf UNIX-ähnlichen Betriebssystemen ein Zeilenumbruchzeichen als Zeilenabschluss und/oder Nachrichtengrenze behandelt wird (dazu gehört auch die Weiterleitung zwischen Prozessen, Zeilenpufferung usw.).

Stellen Sie sich beispielsweise vor, dass eine Datei mit nur einem Zeilenumbruchzeichen als einzelne, leere Zeile behandelt wird. Umgekehrt ist eine Datei mit einer Länge von null Bytes eigentlich eine leere Datei mit null Zeilen. Dies kann laut bestätigt werden wc -l Befehl.

Insgesamt ist dieses Verhalten sinnvoll, da es keine andere Möglichkeit gäbe, zwischen einer leeren Textdatei und einer Textdatei mit einer einzigen leeren Zeile zu unterscheiden, wenn die \n Das Zeichen war lediglich ein Zeilentrennzeichen und kein Zeilenabschlusszeichen. Daher sollten gültige Textdateien immer mit einem Zeilenumbruchzeichen enden. Die einzige Ausnahme ist, wenn die Textdatei leer sein soll (keine Zeilen).

1646258892 295 Welche Bedeutung hat das Protokoll „Kein Zeilenumbruch am Dateiende
Benutzer34660

Es gibt eine Sache, die ich in früheren Antworten nicht sehe. Eine Warnung über kein Zeilenende könnte eine Warnung sein, wenn ein Teil einer Datei abgeschnitten wurde. Es könnte ein Symptom für fehlende Daten sein.

  • Guter Punkt im Allgemeinen, aber ich denke nicht, dass er im Zusammenhang mit dieser speziellen Frage sinnvoll ist.

    – cst1992

    9. April 2019 um 13:10 Uhr

  • @cst1992 Antworten in Stackoverflow sollen so nützlich wie möglich sein, was bedeutet, dass sie für alle Möglichkeiten gelten sollen. Die Frage ist kurz und ich sehe nicht, wo sie die von mir vorgeschlagene Möglichkeit ausschließt.

    – Benutzer34660

    13. April 2019 um 22:56 Uhr


916620cookie-checkWelche Bedeutung hat das Protokoll „Kein Zeilenumbruch am Dateiende“?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy