No hay nueva línea al final del archivo

No es solo un mal estilo, puede conducir a un comportamiento inesperado cuando se utilizan otras herramientas en el archivo.

Aquí está test.txt:

first line
second line

No hay un carácter de nueva línea en la última línea. Veamos cuántas líneas hay en el archivo:

$ wc -l test.txt
1 test.txt

Tal vez eso es lo que quieres, pero en la mayoría de los casos probablemente esperarías que hubiera 2 líneas en el archivo.

Además, si desea combinar archivos, puede que no se comporte de la manera que esperaría:

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

Finalmente, haría que sus diferencias un poco más ruidoso si fueras a añadir una nueva línea. Si agregaste una tercera línea, mostraría una edición a la segunda línea, así como la nueva adición.

Solo indica que el final del archivo no tiene una nueva línea. No es una catástrofe, es solo un mensaje para dejar más claro que no hay uno cuando se mira una diferencia en la línea de comandos.

Si agrega una nueva línea al final del archivo existente que no tiene una nueva línea al final ya, la diferencia mostrará la última línea antigua también como modificada, cuando conceptualmente no es.

Al menos una buena razón para añadir una nueva línea al final.

La única razón es que Unix históricamente tenía una convención de todos los archivos de texto legibles por humanos que terminaban en una nueva línea. En ese momento, esto evitaba el procesamiento adicional al mostrar o unir archivos de texto, y evitaba tratar los archivos de texto de manera diferente a los archivos que contienen otros tipos de datos (por ejemplo, datos binarios sin procesar que no son legibles por humanos).

Debido a esta convención, muchas herramientas de esa época esperan la nueva línea final, incluidos los editores de texto, las herramientas de diferencia y otras herramientas de procesamiento de texto. Mac OS X fue construido en Unix BSD, y Linux fue desarrollado para ser compatible con Unix, por lo que ambos sistemas operativos han heredado la misma convención, comportamiento y herramientas.

Windows no fue desarrollado para ser compatible con Unix, por lo que no tiene la misma convención, y la mayoría del software de Windows se ocupará muy bien con ninguna nueva línea final.

Pero, desde que Git fue desarrollado para Linux primero, y una gran cantidad de software de código abierto está construido en sistemas compatibles con Unix como Linux, Mac OS X, FreeBSD, etc, la mayoría de las comunidades de código abierto y sus herramientas (incluidos los lenguajes de programación) siguen aplicando estas convenciones.

Hay razones técnicas que tenían sentido en 1971, pero en esta era es principalmente convención y mantener la compatibilidad con las herramientas existentes.

El problema principal es lo que define la línea y si end-on-line secuencia de caracteres es parte de la línea o no. Editores basados en UNIX (como VIM) o herramientas (como Git) utilizan secuencia de caracteres EOL como terminador de línea, por lo tanto es una parte de la línea. Es similar a uso de punto y coma (;) en C y Pascal. En C punto y coma termina declaraciones, en Pascal los separa.

Esto realmente causa un problema porque los finales de línea se modifican automáticamente ensuciando archivos sin hacer ningún cambio en ellos. Ver este post para la resolución.

Git reemplazando LF con CRLF

Hay una cosa que no veo en las respuestas anteriores. Advertencia sobre no end-of-line podría ser una advertencia cuando una porción de un archivo ha sido truncada. Podría ser un síntoma de datos perdidos.

Su archivo original probablemente no tenía carácter de nueva línea.

Sin embargo, algunos editores como gedit en linux agregan silenciosamente una nueva línea al final del archivo. No puedes deshacerte de este mensaje mientras usas este tipo de editores.

Lo que intenté superar este problema es abrir el archivo con visual studio code editor

Este editor muestra claramente la última línea y puede eliminar la línea como desee.

Los archivos fuente son a menudo concatenados por herramientas (C, C++: header files, Javascript: bundlers). Si omite el carácter de nueva línea, podría introducir errores desagradables (donde la última línea de una fuente está concatenada con la primera línea del siguiente archivo fuente). Esperemos que todas las herramientas de concat de código fuente por ahí insertar una nueva línea entre los archivos concatenados de todos modos, pero que no siempre parece ser el caso.

El quid de la cuestión es-en la mayoría de los idiomas, las líneas nuevas tienen un significado semántico y end-of-file no es una alternativa definida por el lenguaje para el carácter de nueva línea. Así que debe terminar cada sentencia / expresión con un carácter de nueva línea including incluyendo la última.

Por si sirve de algo, me encontré con esto cuando creé un proyecto IntelliJ en un Mac, y luego moví el proyecto a mi máquina Windows. Tuve que abrir manualmente cada archivo y cambiar la configuración de codificación en la parte inferior derecha de la ventana IntelliJ. Probablemente no le suceda a la mayoría si alguno que lea esta pregunta, pero eso podría haberme ahorrado un par de horas de trabajo...

La razón por la que esta convención entró en práctica es porque en sistemas operativos tipo UNIX un carácter de nueva línea es tratado como un terminador de línea y/o límite de mensaje (esto incluye canalización entre procesos, buffering de línea, etc.).).

Considere, por ejemplo, que un archivo con solo un carácter de nueva línea se trata como una sola línea vacía. Por el contrario, un archivo con una longitud de cero bytes es en realidad un archivo vacío con cero líneas. Esto se puede confirmar de acuerdo con el wc -l comando.

En conjunto, este comportamiento es razonable porque no habría otra manera de distinguir entre un archivo de texto vacío versus un archivo de texto con una sola línea vacía si el carácter \n era simplemente un separador de líneas en lugar de un terminador de líneas. Por lo tanto, los archivos de texto válidos siempre deben terminar con un carácter de nueva línea. La única excepción es si el archivo de texto está destinado a estar vacío (sin líneas).