“文件末尾无换行符”的意义是什么？日志？

Question

当执行 git diff 时，它显示“No newline at end of file”。

这则消息的意义是什么？它想告诉我们什么？

Answer 1

它表明文件末尾没有换行符（通常是 \n，又名 LF 或 CRLF）。

也就是说，简单来说，文件中的最后一个字节（或者如果您在 Windows 上则为字节）不是换行符。

显示该消息是因为否则无法区分末尾有换行符的文件和没有换行符的文件。无论如何，Diff 都必须输出换行符，否则结果将难以自动读取或处理。

请注意，如果文件格式允许，则在文本文件中始终将换行符作为最后一个字符是一种很好的风格。此外，例如，对于 C 和 C++ 头文件，它是语言标准所要求的。

Answer 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

最后，如果您要添加新行，它会使您的差异稍微更加嘈杂。如果您添加了第三行，它将显示对第二行的编辑以及新添加的内容。

Answer 3

唯一的原因是 Unix 历史上有一个约定，即所有人类可读的文本文件都以换行符结尾。当时，这避免了显示或加入文本文件时的额外处理，并避免以不同于包含其他类型数据（例如人类不可读的原始二进制数据）的文件的方式处理文本文件。

由于这一约定，那个时代的许多工具都期望以换行符结尾，包括文本编辑器、比较工具和其他文本处理工具。 Mac OS X 是在 BSD Unix 基础上构建的，而 Linux 是为了与 Unix 兼容而开发的，因此这两个操作系统都继承了相同的约定、行为和工具。

Windows 并不是为了与 Unix 兼容而开发的，因此它没有相同的约定，并且大多数 Windows 软件都可以很好地处理没有尾随换行符的情况。

但是，由于 Git 首先是为 Linux 开发的，并且许多开源软件是在 Linux、Mac OS X、FreeBSD 等 Unix 兼容系统上构建的，因此大多数开源社区及其工具（包括编程语言）仍在继续遵守这些约定。

技术原因在 1971 年是有意义的，但在这个时代，主要是惯例以及保持与现有工具的兼容性。

Answer 4

如果您在现有文件末尾添加新行文本，而该文件末尾还没有换行符，则差异将显示旧的最后一行：已被修改，尽管从概念上来说并没有。

这至少是在末尾添加换行符的一个充分理由。

示例

一个文件包含：

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。事实上，这就是发生的事情，但它不是概念上发生的事情，所以它可能会令人困惑。

Answer 5

该约定付诸实践的原因是，在类 UNIX 操作系统上，换行符被视为行终止符和/或消息边界（这包括进程之间的管道、行缓冲等）。

例如，考虑仅包含换行符的文件被视为单个空行。相反，长度为零字节的文件实际上是一个零行的空文件。这可以根据wc -l命令来确认。

总而言之，这种行为是合理的，因为如果 \n 字符仅仅是行分隔符而不是行终止符。因此，有效的文本文件应始终以换行符结尾。唯一的例外是文本文件是否为空（无行）。

Answer 6

它只是表明文件末尾没有换行符。这不是一场灾难，它只是一条消息，让您更清楚地知道在命令行中查看差异时不存在灾难。

Answer 7

有一点我在之前的回复中没有看到。当文件的一部分被截断时，有关无行尾的警告可能是一个警告。这可能是数据丢失的症状。

Answer 8

核心问题是你定义什么line以及是否end-on-line
字符序列是否是行的一部分。基于 UNIX 的编辑器
（例如VIM）或工具（例如Git）使用EOL字符序列作为
行终止符，因此它是行的一部分。它类似于
在 C 和 Pascal 中使用分号 (;)。在C中分号终止
语句，在 Pascal 中它将它们分开。

Answer 9

什么

在进行 git diff 时，它显示“文件末尾没有换行符”。

在某些方面，是的，但它更加微妙和微妙。

在执行 git diff 时，git 显示文件版本之间的差异，在这些文件不同的地方显示为块。这可能包括文件末尾的块。

如果文件的两个版本都不以换行符结尾，则将读取块的末尾，

\ No newline at the end of file

而如果只有一个版本不以换行符结尾，则块将以

-last line
\ No newline at the end of file
+new last line

或

-last line
+new last line
\ No newline at the end of file

为什么？

这条消息的意义是什么

原因很简单。 git diff 的主要目的之一是明确地显示更改，以便它可以用作 git apply 的输入。为此，Git 需要知道在应用 diff 时应该如何处理换行符。应该删除、保留还是更改它们？

\ No newline at the end of file 是一种实现此目的的方法。它对于想要了解此类更改的人们也很有帮助，因为在某些情况下，有或没有换行符对文件来说很重要。

它想告诉我们什么？

好吧，只是这个文件末尾没有换行符。或者说以前没有，但现在有了。或者说曾经有但现在没有了。

Answer 10

这实际上确实会导致问题，因为行结尾会自动修改，从而弄脏文件，而无需对其进行任何更改。请参阅此帖子以获取解决方案。

git 用 CRLF 替换 LF

Answer 11

源文件通常由工具连接（C、C++：头文件，Javascript：捆绑程序）。如果省略换行符，可能会引入严重的错误（其中一个源文件的最后一行与下一个源文件的第一行连接）。希望所有源代码连接工具都能在连接的文件之间插入换行符，但情况似乎并非总是如此。

问题的关键是 - 在大多数语言中，换行符具有语义含义，并且文件结尾不是换行符的语言定义替代品。因此，您应该使用换行符来终止每个语句/表达式 - 包括最后一个。

Answer 12

您的原始文件可能没有换行符。

但是，某些编辑器（例如 Linux 中的 gedit）会在文件末尾默默地添加换行符。使用此类编辑器时您无法摆脱此消息。

我试图解决这个问题是使用 Visual Studio 代码编辑器 打开文件

该编辑器清楚地显示了最后一行您可以根据需要删除该行。

Answer 13

ubuntu
gt; vi source.cpp

:set binary noeol