Нет новой строки в конце файла

это не просто плохой стиль, это может привести к неожиданному поведению при использовании других инструментов в файле.

здесь test.txt:

first line
second line

в последней строке нет символа новой строки. Давайте посмотрим, сколько строк в файле:

$ wc -l test.txt
1 test.txt

может быть, это то, что вы хотите, но в большинстве случаев вы, вероятно, ожидаете, что в файле будет 2 строки.

кроме того, если вы хотите объединить файлы, он может вести себя не так, как вы бы ожидайте:

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

наконец, это сделает ваши различия немного более шумными, если вы добавите новую строку. Если вы добавили третью строку, она покажет редактирование второй строки, а также новое добавление.

Это просто означает, что конец файла не строки. Это не катастрофа, это просто сообщение, чтобы сделать его более ясным, что его нет, когда вы смотрите на разницу в командной строке.

Если вы добавите новую строку в конце существующего файла, который уже не имеет новой строки в конце, diff покажет старую последнюю строку также как измененную, когда концептуально ее нет.

по крайней мере одна хорошая причина, чтобы добавить новую строку в конце.

единственная причина заключается в том, что Unix исторически имел соглашение всех удобочитаемых текстовых файлов, заканчивающихся новой строкой. В то время это позволило избежать дополнительной обработки при отображении или соединении текстовых файлов и избежать обработки текстовых файлов по-разному с файлами, содержащими другие виды данных (например, необработанные двоичные данные, которые не читаются человеком).

из-за этого соглашения многие инструменты той эпохи ожидают окончания новой строки, включая текстовые редакторы, различные инструменты и другой текст инструменты обработки. Mac OS X был построен на BSD Unix, а Linux был разработан для совместимости с Unix, поэтому обе операционные системы унаследовали одно и то же соглашение, поведение и инструменты.

Windows не был разработан, чтобы быть Unix-совместимым, поэтому он не имеет того же соглашения, и большинство программного обеспечения Windows будет иметь дело просто отлично без конечной новой строки.

но, так как Git был разработан для Linux сначала, и много программного обеспечения с открытым исходным кодом построено на Unix-совместимых системах, таких как Linux, Mac OS X, FreeBSD и т. д. Большинство сообществ с открытым исходным кодом и их инструменты (включая языки программирования) продолжают следовать этим соглашениям.

есть технические причины, которые имели смысл в 1971 году, но в эту эпоху это в основном конвенция и поддержание совместимости с существующими инструментами.

основная проблема заключается в том, что вы определяете line и является ли end-on-line последовательность символов является частью строки или нет. Редакция ОС UNIX (например, VIM) или инструменты (например, Git) используют последовательность символов EOL в качестве линия Терминатор, поэтому это часть линии. Это похоже на использование точки с запятой (;) в C и Pascal. В C точка с запятой заканчивается утверждения, в Паскале он их разделяет.

Это на самом деле вызывает проблему, потому что окончания строк автоматически изменяются загрязняющие файлы без внесения каких-либо изменений в них. Увидеть этот пост для резолюции.

ГИТ замена LF с возврата каретки и перевода строки

есть одна вещь, которую я не вижу в предыдущих ответах. Предупреждение об отсутствии конца строки может быть предупреждением, когда часть файла была усечена. Это может быть признаком отсутствия данных.

ваш исходный файл, вероятно, не было символа новой строки.

однако некоторые редакторы любят gedit в linux молча добавляет новую строку в конце файла. Вы не можете избавиться от этого сообщения при использовании такого рода редакторов.

Что я пытался преодолеть эту проблему, чтобы открыть файл с редактор кода visual studio

этот редактор явно показывает последнюю строку, и вы можете удалить строку, как вы хотите.

исходные файлы часто объединяются инструментами (C, C++: заголовочные файлы, Javascript: bundlers). Если вы опустите символ новой строки, вы можете ввести неприятные ошибки (где последняя строка одного источника связана с первой строкой следующего исходного файла). Надеюсь, все средства, Источник конкатенацию код там все равно вставить новую строку между аудио файлы, но это не всегда представляется случай.

суть проблемы - в большинстве языков, новые строки имеют семантическое значение и конец файла не является определяемой языком альтернативой для символа новой строки. Таким образом, вы должны завершить каждый оператор / выражение символом новой строки-включая последний.

для чего это стоит, я столкнулся с этим, когда я создал проект IntelliJ на Mac, а затем переместил проект на свою машину Windows. Мне пришлось вручную открыть каждый файл и изменить настройку кодировки в правом нижнем углу окна IntelliJ. Вероятно, это не происходит с большинством, если кто-то читает этот вопрос, но это могло бы сэкономить мне пару часов работы...

причина, по которой это соглашение вступило в силу, заключается в том, что в UNIX-подобных операционных системах символ новой строки рассматривается как признак конца строки и/или границы сообщения (это включает в себя конвейер между процессами, буферизацию строк и т. д.).

рассмотрим, например, что файл только с символом новой строки обрабатывается как одна пустая строка. И наоборот, файл с длиной в ноль байт на самом деле является пустым файлом с нулевыми строками. Это может быть подтверждено в соответствии с wc -l команда.

в целом, такое поведение является разумным, потому что не было бы никакого другого способа отличить пустой текстовый файл от текстового файла с одной пустой строкой, если \n символ был просто разделителем строк, а не Терминатором строк. Таким образом, допустимые текстовые файлы всегда должны заканчиваться символом новой строки. Единственное исключение - если текстовый файл должен быть пустым (без строк).