Cos'è una carrozza e perché sta tornando? Feed linea ritorno carrello COSA SIGNIFICA TUTTO!?!
La carta su una macchina da scrivere viaggia orizzontalmente su un carrello. Il Carriage Return o CR era un carattere di controllo non stampabile che riportava la macchina da scrivere all'inizio della riga di testo.
Tuttavia, un ritorno carrello sposta indietro il carrello ma non fa avanzare la carta di una riga. Il carrello si muove sugli assi X...
E Line Feed o LF è il carattere di controllo non stampabile che ruota la Platina (il cilindro di gomma principale) di una linea.
Quindi, ritorno a capo e avanzamento riga. Due azioni e, per anni, due personaggi di controllo.
Ogni sistema operativo sembra codificare un EOL (fine linea) in modo diverso. I sistemi operativi alla fine degli anni '70 utilizzavano tutti CR LF insieme letteralmente perché si interfacciavano quotidianamente con macchine da scrivere/stampanti.
Windows utilizza CRLF perché DOS utilizzava CRLF perché CP/M utilizzava CRLF come cronologia.
Mac OS ha utilizzato CR per anni fino a quando OS X non è passato a LF.
Unix utilizzava solo un singolo LF su CRLF e lo ha fatto sin dall'inizio, probabilmente perché sistemi come Multics hanno iniziato a utilizzare solo LF intorno al 1965. Il salvataggio di un singolo byte OGNI LINEA è stato un grosso problema sia per l'archiviazione che per la trasmissione.
Avanti veloce al 2018 ed è forse giunto il momento che Windows passi anche all'utilizzo di LF come carattere EOL per i file di testo.
Come mai? Per cominciare, Microsoft ha finalmente aggiornato Blocco note per gestire i file di testo che utilizzano LF.
MA
Sarebbe possibile un simile cambiamento? Probabilmente no, spaccherebbe il mondo. Ecco NewLine su .NET Core.
public static String NewLine {
get {
Contract.Ensures(Contract.Result() != null);
#if !PLATFORM_UNIX
return "\r\n";
#else
return "\n";
#endif // !PLATFORM_UNIX
}
} Indipendentemente da ciò, se usi regolarmente Windows e WSL (Linux su Windows) e Linux insieme, vorrai essere consapevole e consapevole di CRLF e LF.
Mi sono imbattuto in una situazione interessante di recente. Per prima cosa, esaminiamo cosa fa Git
Puoi configurare .gitattributes per dire a Git come trattare i file, individualmente o per estensione.
Quando
git config --global core.autocrlf true
è impostato, git convertirà automaticamente i file in modo silenzioso in modo che vengano estratti in un modo specifico del sistema operativo. Se sei su Linux e fai il checkout, otterrai LF, se sei su Windows otterrai CRLF.
Viola su Twitter offre un importante chiarimento:
"gitattributes controlla il comportamento di fine riga per un repository, git config (specialmente con --global) è un'impostazione per utente."
Il 99% delle volte il sistema e le opzioni disponibili funzionano alla grande.
Tranne quando condividi file system tra Linux e Windows. Uso Windows 10 e Ubuntu (tramite WSL) e tengo le cose in /mnt/c/github.
Tuttavia, se estraggo da Windows 10 ottengo CRLF e se estraggo da Linux posso LF, quindi i miei script di shell POSSONO O NON FUNZIONANO mentre sono in Ubuntu.
Ho scelto di creare un file .gitattributes che imposta sia gli script di shell che gli script di PowerShell su LF. In questo modo quegli script possono essere utilizzati, condivisi ed ESEGUITI tra i sistemi.
*.sh eol=lf *.ps1 eol=lf
Hai molte scelte. Anche in questo caso il 99% delle volte autocrlf è la cosa giusta.
Dai documenti di GitHub:
Noterai che i file corrispondono:*.c , *.sln , *.png --, separato da uno spazio, quindi data un'impostazione--text , text eol=crlf , binary . Esamineremo alcune possibili impostazioni di seguito.
text=auto- Git gestirà i file nel modo che riterrà migliore. Questa è una buona opzione predefinita.
text eol=crlf- Git convertirà sempre le terminazioni di riga in
CRLFalla cassa. Dovresti usarlo per i file che devono mantenereCRLFfinali, anche su OSX o Linux.
- Git convertirà sempre le terminazioni di riga in
text eol=lf- Git convertirà sempre le terminazioni di riga in
LFalla cassa. Dovresti usarlo per i file che devono mantenere le terminazioni LF, anche su Windows.
- Git convertirà sempre le terminazioni di riga in
binary- Git capirà che i file specificati non sono di testo e non dovrebbe tentare di cambiarli. Il
binarysetting è anche un alias per-text -diff.
- Git capirà che i file specificati non sono di testo e non dovrebbe tentare di cambiarli. Il
Anche in questo caso, le impostazioni predefinite sono probabilmente corrette. MA - se stai facendo cose strane, condividendo file o file system su più sistemi operativi, dovresti essere consapevole.
Edward Thomson, un co-maintainer di libgit2, ha questo da dire e ci indica il suo post sul blog su Line Endings.
Lo direi più forte. Poiché `core.autocrlf` è configurato in un ambito per utente, ma influisce sul modo in cui funziona l'intero repository, `.gitattributes` dovrebbe _sempre_ essere utilizzato.
Se hai problemi, probabilmente sono le terminazioni di riga. La raccomandazione di Edward è che TUTTI i progetti controllino un .gitattributes.
La chiave per gestire le terminazioni di riga è assicurarsi che la configurazione sia salvata nel repository, utilizzando .gitattributes . Per la maggior parte delle persone, questo è semplice come creare un file chiamato .gitattributes nella radice del tuo repository che contiene una riga:
* text=auto
Spero che questo aiuti!
* Macchina da scrivere di Matunos utilizzata sotto Creative Commons
Sponsor: Dai un'occhiata a JetBrains Rider:un IDE .NET multipiattaforma. Modifica, refactoring, verifica ed esegui il debug di applicazioni ASP.NET, .NET Framework, .NET Core, Xamarin o Unity. Scopri di più e scarica una versione di prova di 30 giorni!