Was ist eine Kutsche und warum kehrt sie zurück? Wagenrücklauf Zeilenvorschub WAS BEDEUTET DAS ALLES!?!
Das Papier auf einer Schreibmaschine fährt horizontal auf einem Wagen. Das Carriage Return oder CR war ein nicht druckbares Steuerzeichen, das die Schreibmaschine an den Anfang der Textzeile zurücksetzte.
Ein Carriage Return bewegt den Wagen jedoch zurück, bewegt das Papier jedoch nicht um eine Zeile vor. Der Schlitten bewegt sich auf den X-Achsen...
Und Line Feed oder LF ist das nicht druckbare Steuerzeichen, das die Walze (den Hauptgummizylinder) um eine Zeile dreht.
Daher Carriage Return und Line Feed. Zwei Aktionen und seit Jahren zwei Steuerzeichen.
Jedes Betriebssystem scheint ein EOL (End of Line) anders zu codieren. Ende der 70er verwendeten alle Betriebssysteme CR LF buchstäblich zusammen, weil sie täglich Schnittstellen zu Schreibmaschinen/Druckern hatten.
Windows verwendet CRLF, weil DOS CRLF verwendet hat, weil CP/M CRLF verwendet hat, weil die Geschichte.
Mac OS verwendete CR jahrelang, bis OS X auf LF umstellte.
Unix verwendete nur ein einziges LF über CRLF und hat dies von Anfang an getan, wahrscheinlich weil Systeme wie Multics um 1965 anfingen, nur LF zu verwenden. Das Speichern eines einzelnen Bytes JEDER ZEILE war eine große Sache sowohl für die Speicherung als auch für die Übertragung.
Schneller Vorlauf bis 2018 und vielleicht ist es an der Zeit, dass auch Windows dazu übergeht, nur noch LF als EOL-Zeichen für Textdateien zu verwenden.
Wieso den? Für den Anfang hat Microsoft Notepad endlich aktualisiert, um Textdateien zu verarbeiten, die LF verwenden.
ABER
Wäre eine solche Änderung möglich? Wahrscheinlich nicht, es würde die Welt zerstören. Hier ist NewLine auf .NET Core.
public static String NewLine {
get {
Contract.Ensures(Contract.Result() != null);
#if !PLATFORM_UNIX
return "\r\n";
#else
return "\n";
#endif // !PLATFORM_UNIX
}
} Unabhängig davon, wenn Sie regelmäßig Windows und WSL (Linux auf Windows) und Linux zusammen verwenden, sollten Sie CRLF und LF bewusst und bewusst sein.
Ich bin kürzlich in eine interessante Situation geraten. Sehen wir uns zunächst an, was Git tut
Sie können .gitattributes konfigurieren, um Git mitzuteilen, wie Dateien zu behandeln sind, entweder einzeln oder nach Erweiterung.
Wenn
git config --global core.autocrlf true
gesetzt ist, konvertiert git Dateien automatisch leise, sodass sie auf eine betriebssystemspezifische Weise ausgecheckt werden. Wenn Sie Linux verwenden und zur Kasse gehen, erhalten Sie LF, wenn Sie Windows verwenden, erhalten Sie CRLF.
Viola auf Twitter bietet eine wichtige Klarstellung:
"gitattributes steuert das Zeilenendeverhalten für ein Repo, git config (insbesondere mit --global) ist eine Einstellung pro Benutzer."
99 % der Zeit funktionieren das System und die verfügbaren Optionen hervorragend.
Außer wenn Sie Dateisysteme zwischen Linux und Windows freigeben. Ich verwende Windows 10 und Ubuntu (über WSL) und bewahre Sachen in /mnt/c/github auf.
Wenn ich jedoch von Windows 10 ziehe, erhalte ich CRLF, und wenn ich von Linux ziehe, kann ich LF ausführen, sodass meine Shell-Skripte in Ubuntu MÖGLICHERWEISE FUNKTIONIEREN ODER NICHT.
Ich habe mich entschieden, eine .gitattributes-Datei zu erstellen, die sowohl Shell-Skripts als auch PowerShell-Skripts auf LF setzt. Auf diese Weise können diese Skripte verwendet und zwischen Systemen geteilt und ausgeführt werden.
*.sh eol=lf *.ps1 eol=lf
Sie haben viele Möglichkeiten. Auch hier ist autocrlf in 99% der Fälle das Richtige.
Aus den GitHub-Dokumenten:
Sie werden feststellen, dass Dateien abgeglichen werden – *.c , *.sln , *.png --, durch ein Leerzeichen getrennt, dann mit einer Einstellung versehen--text , text eol=crlf , binary . Im Folgenden gehen wir auf einige mögliche Einstellungen ein.
text=auto- Git behandelt die Dateien so, wie es für am besten hält. Dies ist eine gute Standardoption.
text eol=crlf- Git konvertiert Zeilenenden immer in
CRLFan der Kasse. Sie sollten dies für Dateien verwenden, dieCRLFbehalten müssen Endungen, sogar auf OSX oder Linux.
- Git konvertiert Zeilenenden immer in
text eol=lf- Git konvertiert Zeilenenden immer in
LFan der Kasse. Sie sollten dies für Dateien verwenden, die LF-Endungen behalten müssen, auch unter Windows.
- Git konvertiert Zeilenenden immer in
binary- Git wird verstehen, dass die angegebenen Dateien kein Text sind, und es sollte nicht versuchen, sie zu ändern. Die
binaryDie Einstellung ist auch ein Alias für-text -diff.
- Git wird verstehen, dass die angegebenen Dateien kein Text sind, und es sollte nicht versuchen, sie zu ändern. Die
Auch hier sind die Standardeinstellungen wahrscheinlich korrekt. ABER - wenn Sie seltsame Sachen machen, Dateien oder Dateisysteme über Betriebssysteme hinweg teilen, dann sollten Sie sich dessen bewusst sein.
Edward Thomson, ein Co-Maintainer von libgit2, hat dies zu sagen und verweist uns auf seinen Blogbeitrag zu Line Endings.
Ich würde das stärker sagen. Da `core.autocrlf` in einem Bereich konfiguriert wird, der pro Benutzer gilt, aber die Art und Weise beeinflusst, wie das gesamte Repository funktioniert, sollte `.gitattributes` _immer_ verwendet werden.
Wenn Sie Probleme haben, liegt es wahrscheinlich am Zeilenende. Edwards Empfehlung ist, dass ALLE Projekte ein .gitattributes.
einchecken
Der Schlüssel zum Umgang mit Zeilenenden besteht darin, sicherzustellen, dass Ihre Konfiguration mit .gitattributes an das Repository übergeben wird . Für die meisten Leute ist dies so einfach wie das Erstellen einer Datei mit dem Namen .gitattributes im Stammverzeichnis Ihres Repositorys, das eine Zeile enthält:
* text=auto
Hoffe, das hilft!
* Schreibmaschine von Matunos verwendet unter Creative Commons
Sponsor: Sehen Sie sich JetBrains Rider an:eine plattformübergreifende .NET-IDE. Bearbeiten, Refactoring, Testen und Debuggen von ASP.NET-, .NET Framework-, .NET Core-, Xamarin- oder Unity-Anwendungen. Erfahren Sie mehr und laden Sie eine 30-Tage-Testversion herunter!