假设文件正在被处理，而文件仍由另一个进程生成。

可能与此有关？指示文件已准备好处理的标志。

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

因此，原因如下：

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

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

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

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

这可能与以下两者之间的差异有关：

文本文件（每行应该以行尾结尾）二进制文件（没有真正的“行”可言，必须保留文件的长度）

如果每一行都以行尾结尾，这就避免了，例如，连接两个文本文件会使第一行的最后一行与第二行的第一行对齐。

此外，编辑器可以在加载时检查文件是否以行尾结尾，将其保存在本地选项“eol”中，并在写入文件时使用该选项。

几年前（2005年），许多编辑（ZDE、Eclipse、Scite…）确实“忘记”了最后的EOL，这并不是很受欢迎。不仅如此，他们还错误地将最后的EOL解释为“开始一行”，实际上开始显示另一行，就好像它已经存在一样。与在上述编辑器之一中打开文本文件相比，这在“适当”的文本文件中是非常明显的，该文件具有良好的文本编辑器（如vim）。它在文件的最后一行下面显示了一行。你会看到这样的情况：

1 first line
2 middle line
3 last line
4

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

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

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

我个人喜欢源代码文件末尾的新行。

它可能起源于Linux或所有UNIX系统。我记得有编译错误（如果我没弄错的话是gcc），因为源代码文件没有以空的新行结尾。为什么会这样呢。