现在已经很晚了，但我在文件处理中遇到了一个错误，这是因为文件没有以空换行结尾。我们使用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，它使其余过程失败。

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

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

如果我们想成为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是如何产生不利影响的。

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

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

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

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

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

参考：GCC/GNU邮件存档。

有些工具会这样做。例如，wc期望如下：

$ echo -n "Line not ending in a new line" | wc -l
0
$ echo "Line ending with a new line" | wc -l
1

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

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