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

Ответ 1

Это означает, что у вас нет новой строки (обычно '\n', иначе CR или CRLF) в конце файла.

То есть, просто, последний байт (или байты, если вы в Windows) в файле не является символом новой строки.

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

Обратите внимание, что это хороший стиль, который всегда ставит символ новой строки как последний символ, если он разрешен форматом файла. Кроме того, например, для заголовочных файлов C и С++ требуется стандарт языка.

Ответ 2

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

Вот 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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Это как минимум одна веская причина добавить новую строку в конце.

пример

Файл содержит:

A() {
    // do something
}

HexDump:

00000000: 4128 2920 7b0a 2020 2020 2f2f 2064 6f20  A() {.    // do 
00000010: 736f 6d65 7468 696e 670a 7d              something.}

Вы теперь редактируете это

A() {
    // do something
}
// Useful comment

HexDump:

00000000: 4128 2920 7b0a 2020 2020 2f2f 2064 6f20  A() {.    // do 
00000010: 736f 6d65 7468 696e 670a 7d0a 2f2f 2055  something.}.// U
00000020: 7365 6675 6c20 636f 6d6d 656e 742e 0a    seful comment..

Git diff покажет:

-}
\ No newline at end of file
+}
+// Useful comment.

Другими словами, это показывает больший различие, чем концептуально произошло. Он показывает, что вы удалили строку } и добавили строку }\n. Фактически это то, что произошло, но это не то, что концептуально произошло, так что это может сбить с толку.

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

git замена LF на CRLF

Ответ 11

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

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

Что я пытался решить эту проблему, так это открыть файл с визуальный редактор кода студии

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

Ответ 12

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