一个单独的用例：当文本文件受版本控制时，提交卫生。

如果将内容添加到文件末尾，则先前是最后一行的行将被编辑为包含换行符。这意味着，打开文件以了解该行最后一次编辑的时间将显示换行符添加，而不是您实际希望看到的提交。

（该示例特定于git，但同样的方法也适用于其他版本控制系统。）

除了上述实际原因之外，如果Unix的创始人（Thompson、Ritchie等人）或他们的Multics前辈意识到使用行终结符而不是行分隔符是有理论原因的，我也不会感到惊讶：使用行终结器，您可以对所有可能的行文件进行编码。使用行分隔符，零行文件和包含单个空行的文件之间没有区别；它们都被编码为包含零字符的文件。

因此，原因如下：

因为POSIX就是这样定义它的。因为有些工具期望它或没有它的“错误行为”。例如，wc-l不会计算最后的“行”，如果它不以换行结尾。因为它简单方便。在Unix上，cat只起作用，而且没有任何复杂的问题。它只复制每个文件的字节，不需要任何解释。我不认为DOS等同于猫。使用副本a+b c将最终将文件a的最后一行与文件b的第一行合并。因为零行的文件（或流）可以与一个空行的文件区分开来。

最后缺少换行符的文件还有一个实际的编程问题：read-Bash内置（我不知道其他read实现）无法按预期工作：

printf $'foo\nbar' | while read line
do
    echo $line
done

这只打印foo！原因是，当read遇到最后一行时，它将内容写入$line，但返回退出代码1，因为它已到达EOF。这打破了while循环，因此我们永远无法到达echo$line部分。如果要处理这种情况，必须执行以下操作：

while read line || [ -n "${line-}" ]
do
    echo $line
done < <(printf $'foo\nbar')

也就是说，如果由于文件末尾的非空行导致读取失败，则执行回显。当然，在这种情况下，输出中将有一个额外的换行符，而输入中没有。

这源于使用简单终端的早期。换行符用于触发传输数据的“刷新”。

今天，不再需要换行符。当然，如果没有换行符，许多应用程序仍然存在问题，但我认为这是这些应用程序中的一个错误。

然而，如果你有一个需要换行符的文本文件格式，那么你可以得到非常便宜的简单数据验证：如果文件以结尾没有换行符的行结尾，那么你就知道文件已损坏。每行只有一个额外的字节，您可以高精度地检测损坏的文件，几乎不需要CPU时间。

现在已经很晚了，但我在文件处理中遇到了一个错误，这是因为文件没有以空换行结尾。我们使用sed处理文本文件，sed省略了输出的最后一行，这导致无效的json结构，并将流程的其余部分发送到失败状态。

我们所做的就是：

有一个示例文件，比如：foo.txt，其中包含一些json内容。

[{
    someProp: value
},
{
    someProp: value
}] <-- No newline here

该文件是在寡妇计算机中创建的，窗口脚本正在使用PowerShell命令处理该文件。一切都很好。

当我们使用sed命令sed的|value|newValue|g'foo.txt>foo.txt.tmp处理同一文件时

新生成的文件是

[{
    someProp: value
},
{
    someProp: value

和boom，由于无效的JSON，它使其余过程失败。

因此，用空的新行结束文件始终是一个好的做法。

每一行都应该以换行符结尾，包括最后一行。有些程序在处理文件的最后一行时遇到问题，如果它不是换行符。

GCC对此发出警告，并不是因为它无法处理文件，而是因为它必须作为标准的一部分。

C语言标准说非空的源文件应以换行符结尾，换行符前不得紧跟反斜杠字符。由于这是一个“应”条款，我们必须发出一条违反此规则的诊断信息。这在ANSI C 1989标准第2.1.1.2节中。ISO C 1999标准（可能还有ISO C 1990标准）第5.1.1.2节。

参考：GCC/GNU邮件存档。