GNU/Linux >> Znalost Linux >  >> Linux

Carriage Returns a Line Feeds vás nakonec skousnou – několik tipů Git

Co je to kočár a proč se vrací? Carriage Return Line Feed CO TO VŠECHNO ZNAMENÁ!?!

Papír na psacím stroji jezdí vodorovně na kočáru. Carriage Return neboli CR byl netisknutelný řídicí znak, který by přenastavil psací stroj na začátek řádku textu.

Funkce Carriage Return však posune vozík zpět, ale neposune papír o jeden řádek. Vozík se pohybuje na osách X...

A Line Feed neboli LF je netisknutelný ovládací znak, který otočí desku (hlavní pryžový válec) o jeden řádek.

Proto, Carriage Return a Line Feed. Dvě akce a po léta dvě řídící postavy.

Zdá se, že každý operační systém kóduje EOL (konec řádku) jinak. Všechny operační systémy na konci 70. let používaly CR LF společně doslova proto, že byly denně propojeny s psacími stroji/tiskárnami.

Windows používá CRLF, protože DOS používal CRLF, protože CP/M používal CRLF kvůli historii.

Mac OS používal CR roky, dokud OS X nepřešel na LF.

Unix používal pouze jeden LF přes CRLF a to od začátku, pravděpodobně proto, že systémy jako Multics začaly používat právě LF kolem roku 1965. Ušetřit jeden bajt KAŽDÝ ŘÁDEK byl obrovský problém pro ukládání i přenos.

Přejděte do roku 2018 a možná je čas, aby Windows také přešel na pouhé používání LF jako EOL znaku pro textové soubory.

Proč? Pro začátek Microsoft konečně aktualizoval Poznámkový blok, aby zpracovával textové soubory, které používají LF.

ALE

Byla by taková změna možná? Pravděpodobně ne, rozbilo by to svět. Zde je NewLine na .NET Core.

public static String NewLine {
    get {
        Contract.Ensures(Contract.Result() != null);
#if !PLATFORM_UNIX
        return "\r\n";
#else
        return "\n";
#endif // !PLATFORM_UNIX
    }
}

Bez ohledu na to, pokud pravidelně používáte Windows a WSL (Linux na Windows) a Linux společně, budete chtít být vědomi a vědomi si CRLF a LF.

Nedávno jsem se dostal do zajímavé situace. Nejprve se podívejme, co Git dělá

Soubory .gitattributes můžete nakonfigurovat tak, aby Gitu sdělily, jak zacházet se soubory, buď jednotlivě, nebo podle přípony.

Když

git config --global core.autocrlf true

je-li nastaven, git automaticky převede soubory tiše, aby byly rezervovány způsobem specifickým pro OS. Pokud používáte Linux a platíte, získáte LF, pokud používáte Windows, získáte CRLF.

Viola na Twitteru nabízí důležité vysvětlení:

"gitattributes řídí chování ukončování řádků pro repo, git config (zejména s --global) je nastavení pro uživatele."

99 % systému času a dostupných možností funguje skvěle.

Kromě případů, kdy sdílíte systémy souborů mezi Linuxem a Windows. Používám Windows 10 a Ubuntu (přes WSL) a uchovávám věci v /mnt/c/github.

Pokud však stahuji z Windows 10, dostanu CRLF a pokud stahuji z Linuxu, mohu LF, takže mé skripty shellu MOHOU NEBO NEMUSÍ FUNGOVAT v Ubuntu.

Rozhodl jsem se vytvořit soubor .gitattributes, který nastaví skripty shellu i skripty PowerShell na LF. Tímto způsobem mohou být tyto skripty používány a sdíleny a SPUŠTĚNY mezi systémy.

*.sh eol=lf
*.ps1 eol=lf

Máte spoustu možností. Opět je v 99 % případů autocrlf správná věc.

Z dokumentů GitHub:

Všimnete si, že se soubory shodují--*.c , *.sln , *.png --, oddělené mezerou, poté s nastavením --text , text eol=crlf , binary . Některá možná nastavení projdeme níže.

  • text=auto
    • Git bude se soubory nakládat jakýmkoli způsobem, který považuje za nejlepší. Toto je dobrá výchozí možnost.
  • text eol=crlf
    • Git vždy převede konce řádků na CRLF na pokladně. Toto byste měli použít pro soubory, které musí zachovat CRLF konce, dokonce i na OSX nebo Linux.
  • text eol=lf
    • Git vždy převede konce řádků na LF na pokladně. Měli byste to použít pro soubory, které musí zachovat koncovky LF, a to i ve Windows.
  • binary
    • Git pochopí, že zadané soubory nejsou text, a neměl by se je pokoušet změnit. binary nastavení je také alias pro -text -diff .

Opět platí, že výchozí hodnoty jsou pravděpodobně správné. ALE – pokud děláte divné věci, sdílíte soubory nebo souborové systémy napříč operačními systémy, měli byste si toho být vědomi.

Edward Thomson, co-správce libgit2, to má říct a odkazuje nás na svůj blogový příspěvek na Line Endings.

Řekl bych to důrazněji. Protože `core.autocrlf` je nakonfigurován v rozsahu, který je pro každého uživatele, ale ovlivňuje způsob, jakým celé úložiště funguje, měly by se `.gitattributes` používat _always_.

Pokud máte potíže, pravděpodobně jde o konce řádků. Edwardovo doporučení je, aby VŠECHNY projekty zkontrolovaly .gitattributes.

Klíčem k řešení konce řádků je zajistit, aby se vaše konfigurace zapsala do úložiště pomocí .gitattributes . Pro většinu lidí je to stejně jednoduché jako vytvoření souboru s názvem .gitattributes v kořenovém adresáři vašeho úložiště, které obsahuje jeden řádek:
* text=auto

Doufám, že to pomůže!

* Psací stroj od Matunos používaný pod Creative Commons

Sponzor: Podívejte se na JetBrains Rider:multiplatformní .NET IDE. Upravujte, refaktorujte, testujte a ladte aplikace ASP.NET, .NET Framework, .NET Core, Xamarin nebo Unity. Zjistěte více a stáhněte si 30denní zkušební verzi!


Linux
  1. 3 Linuxové příkazy pro vypnutí systému a budete to moci udělat snadno

  2. Pokračování bash line po &&a || Zdokumentováno?

  3. Odstraňování problémů se sítí Linux a ladění?

  1. 8 tipů pro příkazový řádek Linuxu

  2. 10 zajímavých triků a tipů pro příkazový řádek Linuxu, které stojí za to vědět

  3. Git a pevné odkazy

  1. Tipy pro navigaci na příkazovém řádku Linuxu:základy příkazů pushd a popd

  2. 6 zdrojů a 3 tipy, které vám pomohou vstoupit do světa linuxových kontejnerů

  3. $bashpid a $$ se v některých případech liší?