¿Qué es un carro y por qué regresa? Retorno de carro Avance de línea ¡¿QUÉ SIGNIFICA TODO ESTO?!
El papel de una máquina de escribir se desplaza horizontalmente sobre un carro. El retorno de carro o CR era un carácter de control no imprimible que reiniciaba la máquina de escribir al principio de la línea de texto.
Sin embargo, un retorno de carro mueve el carro hacia atrás pero no hace avanzar el papel ni una línea. El carro se mueve sobre los ejes X...
Y Line Feed o LF es el carácter de control no imprimible que gira la platina (el cilindro de goma principal) en una línea.
Por lo tanto, Retorno de carro y Avance de línea. Dos acciones, y durante años, dos personajes de control.
Cada sistema operativo parece codificar un EOL (fin de línea) de manera diferente. Todos los sistemas operativos de finales de los 70 usaban CR LF juntos literalmente porque se conectaban con máquinas de escribir/impresoras a diario.
Windows usa CRLF porque DOS usó CRLF porque CP/M usó CRLF porque el historial.
Mac OS usó CR durante años hasta que OS X cambió a LF.
Unix usó solo un solo LF sobre CRLF y lo ha hecho desde el principio, probablemente porque los sistemas como Multics comenzaron a usar solo LF alrededor de 1965. Guardar un solo byte CADA LÍNEA fue un gran problema tanto para el almacenamiento como para la transmisión.
Avance rápido hasta 2018 y tal vez sea hora de que Windows también cambie a solo usar LF como el carácter EOL para archivos de texto.
¿Por qué? Para empezar, Microsoft finalmente actualizó el Bloc de notas para manejar archivos de texto que usan LF.
PERO
¿Sería posible tal cambio? Probablemente no, rompería el mundo. Aquí está NewLine en .NET Core.
public static String NewLine {
get {
Contract.Ensures(Contract.Result() != null);
#if !PLATFORM_UNIX
return "\r\n";
#else
return "\n";
#endif // !PLATFORM_UNIX
}
} Independientemente, si usa regularmente Windows y WSL (Linux en Windows) y Linux juntos, querrá ser consciente de CRLF y LF.
Me encontré con una situación interesante recientemente. Primero, revisemos lo que hace Git
Puede configurar .gitattributes para decirle a Git cómo tratar los archivos, ya sea individualmente o por extensión.
cuando
git config --global core.autocrlf true
está configurado, git convertirá automáticamente los archivos en silencio para que se desprotejan de una manera específica del sistema operativo. Si está en Linux y paga, obtendrá LF, si está en Windows obtendrá CRLF.
Viola en Twitter ofrece una aclaración importante:
"gitattributes controla el comportamiento de final de línea para un repositorio, git config (especialmente con --global) es una configuración por usuario".
El 99% del tiempo el sistema y las opciones disponibles funcionan muy bien.
Excepto cuando comparte sistemas de archivos entre Linux y Windows. Uso Windows 10 y Ubuntu (a través de WSL) y guardo cosas en /mnt/c/github.
Sin embargo, si lo saco de Windows 10, obtengo CRLF y si lo saco de Linux, puedo LF, por lo que mis scripts de shell PUEDEN O NO FUNCIONAR mientras esté en Ubuntu.
Elegí crear un archivo .gitattributes que establece tanto los scripts de shell como los scripts de PowerShell en LF. De esta manera, esos scripts se pueden usar, compartir y EJECUTAR entre sistemas.
*.sh eol=lf *.ps1 eol=lf
Tienes muchas opciones. Una vez más, el 99% de las veces autocrlf es lo correcto.
De los documentos de GitHub:
Notará que los archivos coinciden:*.c , *.sln , *.png --, separados por un espacio, luego con una configuración--text , text eol=crlf , binary . A continuación, repasaremos algunos ajustes posibles.
text=auto- Git manejará los archivos de la manera que considere mejor. Esta es una buena opción predeterminada.
text eol=crlf- Git siempre convertirá los finales de línea a
CRLFen caja Debe usar esto para archivos que deben mantenerCRLFterminaciones, incluso en OSX o Linux.
- Git siempre convertirá los finales de línea a
text eol=lf- Git siempre convertirá los finales de línea a
LFen caja Debe usar esto para archivos que deben mantener terminaciones LF, incluso en Windows.
- Git siempre convertirá los finales de línea a
binary- Git entenderá que los archivos especificados no son texto y no debería intentar cambiarlos. El
binaryla configuración también es un alias para-text -diff.
- Git entenderá que los archivos especificados no son texto y no debería intentar cambiarlos. El
Una vez más, los valores predeterminados probablemente sean correctos. PERO, si está haciendo cosas raras, compartiendo archivos o sistemas de archivos entre sistemas operativos, debe tener cuidado.
Edward Thomson, comantenedor de libgit2, tiene esto que decir y nos remite a su publicación de blog sobre finales de línea.
Diría esto con más fuerza. Debido a que `core.autocrlf` está configurado en un ámbito que es por usuario, pero afecta la forma en que funciona todo el repositorio, `.gitattributes` debe usarse _siempre_.
Si tiene problemas, probablemente sean los finales de línea. La recomendación de Edward es que TODOS los proyectos verifiquen un .gitattributes.
La clave para lidiar con los finales de línea es asegurarse de que su configuración esté confirmada en el repositorio, usando .gitattributes . Para la mayoría de las personas, esto es tan simple como crear un archivo llamado .gitattributes en la raíz de su repositorio que contiene una línea:
* text=auto
¡Espero que esto ayude!
* Máquina de escribir de Matunos usada bajo Creative Commons
Patrocinador: Consulte JetBrains Rider:un IDE .NET multiplataforma. Edite, refactorice, pruebe y depure aplicaciones ASP.NET, .NET Framework, .NET Core, Xamarin o Unity. Obtenga más información y descargue una versión de prueba de 30 días.