基本上，如果没有得到最终EOL EOF，许多程序将无法正确处理文件。

GCC警告您这一点，因为它是C标准的一部分。（第5.1.1.2节明显）

“文件末尾没有换行符”编译器警告

我一直觉得，在解析一个没有结尾换行符的文件时，这条规则是很困难的。也就是说，您最终会编写代码，其中行的结尾由EOL字符或EOF定义。假设一行以EOL结尾比较简单。

然而，我相信这个规则是从需要换行符的C编译器派生出来的。正如“文件末尾没有换行符”编译器警告所指出的，#include不会添加换行符。

这个答案是一个技术性的答案，而不是观点。

如果我们想成为POSIX纯粹主义者，我们将一行定义为：

一个由零个或多个非<换行符>字符加上一个终止<换行符]字符组成的序列。

资料来源：https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

不完整的行，如：

文件末尾的一个或多个非<换行符>字符序列。

资料来源：https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_195

文本文件为：

包含组织成零行或多行的字符的文件。这些行不包含NUL字符，长度不能超过｛LINE_MAX｝字节，包括＜换行符＞字符。虽然POSIX.1-2008没有区分文本文件和二进制文件（参见ISO C标准），但许多实用程序在操作文本文件时只产生可预测或有意义的输出。具有此类限制的标准实用程序总是在其STDIN或INPUT files部分中指定“文本文件”。

资料来源：https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397

字符串为：

一个连续的字节序列，以第一个空字节结尾并包括第一个空字符。

资料来源：https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_396

由此，我们可以得出，只有当我们处理文件的一行或文件作为文本文件的概念时，我们才可能遇到任何类型的问题（即文本文件是由零行或多行组成的组织，并且我们知道的行必须以＜newline＞结尾）。

大小写：wc-l文件名。

从wc手册中，我们了解到：

行定义为一个由＜newline＞字符分隔的字符串。

如果JavaScript、HTML和CSS文件是文本文件，那么它们的含义是什么？

在浏览器、现代IDE和其他前端应用程序中，在EOF时跳过EOL没有问题。应用程序将正确解析文件。由于并非所有操作系统都符合POSIX标准，因此非OS工具（例如浏览器）根据POSIX标准（或任何OS级标准）处理文件是不切实际的。

因此，我们可以相对确信，EOF的EOL在应用程序级别几乎不会产生负面影响——无论它是否在UNIX OS上运行。

此时，我们可以自信地说，在客户端处理JS、HTML和CSS时，在EOF中跳过EOL是安全的。实际上，我们可以声明，缩小其中任何一个不包含＜newline＞的文件都是安全的。

我们可以进一步说，就NodeJS而言，它也不能遵守POSIX标准，因为它可以在非POSIX兼容的环境中运行。

那我们还剩什么？系统级工具。

这意味着唯一可能出现的问题是那些努力使其功能符合POSIX语义的工具（例如wc中所示的行的定义）。

即使如此，并不是所有的shell都会自动遵守POSIX。例如，Bash不默认为POSIX行为。有一个开关可以启用它：POSIXLY_CORRECT。

EOL的价值值得思考：https://www.rfc-editor.org/old/EOLstory.txt

为了所有实际意图和目的，让我们继续走在工具轨道上，考虑一下：

让我们处理一个没有EOL的文件。至此，本例中的文件是一个缩小的JavaScript，没有EOL。

curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o x.js
curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o y.js

$ cat x.js y.js > z.js

-rw-r--r--  1 milanadamovsky   7905 Aug 14 23:17 x.js
-rw-r--r--  1 milanadamovsky   7905 Aug 14 23:17 y.js
-rw-r--r--  1 milanadamovsky  15810 Aug 14 23:18 z.js

请注意，cat文件大小正好是其各个部分的总和。如果JavaScript文件的连接是JS文件的一个问题，那么更合适的问题是用分号开始每个JavaScript文件。

正如其他人在本主题中提到的：如果你想抓取两个输出仅为一行而不是两行的文件，该怎么办？换句话说，猫做它应该做的事。

猫的男人只提到阅读输入到EOF，而不是＜newline＞。请注意，cat的-n开关还将打印出一个非<换行符>终止的行（或不完整的行）作为一行，即计数从1开始（根据man的说法）

-n对输出线进行编号，从1开始。

现在我们了解了POSIX是如何定义行的，这种行为变得模棱两可，或者说实际上是不合规的。

了解给定工具的用途和合规性将有助于确定使用EOL结束文件的重要性。在C、C++、Java（JARs）等中，一些标准会规定一个新的有效性标准——JS、HTML、CSS不存在这样的标准。

例如，可以不使用wc-l文件名，而是使用awk“｛x++｝END｛print x｝”文件名，并确保任务的成功不会受到我们可能要处理的文件（例如，第三方库，例如我们固化的精简JS）的影响，除非我们的目的是真正按照POSIX兼容的方式计算行数。

结论

在现实生活中，对于某些文本文件（如JS、HTML和CSS），在EOF时跳过EOL会产生负面影响（如果有的话）。如果我们依赖于＜newline＞的存在，我们将工具的可靠性限制在我们编写的文件上，并将自己暴露在第三方文件引入的潜在错误中。

故事的寓意：工程师工具没有依赖EOF中EOL的弱点。

请随意发布用例，因为它们适用于JS、HTML和CSS，我们可以在其中检查跳过EOL是如何产生不利影响的。

最后缺少换行符的文件还有一个实际的编程问题：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')

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

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

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

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

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

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

1 first line
2 middle line
3 last line
4

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

因此，原因如下：

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