c语言警告文件末尾没有换行符,为什么文本文件应该以换行符结尾？

德玛西亚99

这个答案是一种技术性的回答，而不是意见。如果我们想成为POSIX纯粹主义者，我们定义一条线为：零个或多个非字符加上终止字符的序列.资料来源：https：/pubs.opengroup.org/onlinepubs/9699919799/base/v1_头03.html#tag_03_206不完整的一行，如：文件末尾一个或多个非字符的序列。资料来源：https：/pubs.opengroup.org/onlinepubs/9699919799/base/v1_头03.html#tag_03_195文本文件，如：包含组织成零行或多行的字符的文件。这些行不包含NUL字符，任何一行的长度都不能超过{line_max}字节，包括字符。虽然POSIX.1-2008没有区分文本文件和二进制文件(参见ISO C标准)，但许多实用程序在对文本文件进行操作时只产生可预测或有意义的输出。具有这种限制的标准实用程序总是在其STDIN或输入文件部分中指定“文本文件”。资料来源：https：/pubs.opengroup.org/onlinepubs/9699919799/base/v1_头03.html#tag_03_397字符串，如：由第一个空字节结束并包含的连续字节序列。资料来源：https：/pubs.opengroup.org/onlinepubs/9699919799/base/v1_头03.html#tag_03_396由此，我们可以推导出潜在遇到任何类型的问题都是如果我们处理的概念线将文件或文件作为文本文件(因为那是一个文本文件是一个零行或多行的组织，我们知道的行必须以结束)。例如：wc -l filename.从wc我们读的手册：行定义为由字符分隔的字符串。JavaScript、HTML和CSS文件的含义是什么？文本档案？在浏览器、现代IDE和其他前端应用程序中，跳过EOF的EOL没有问题。应用程序将正确地解析文件。因为并不是所有的操作系统都符合POSIX标准，所以非OS工具(例如浏览器)按照POSIX标准(或任何OS级别的标准)处理文件是不切实际的。因此，我们可以相对自信地认为，EOF的EOL在应用程序级别几乎不会产生任何负面影响-不管它是否运行在UNIX操作系统上。此时，我们可以自信地说，在客户端处理JS、HTML、CSS时，跳过EOF的EOL是安全的。实际上，我们可以声明，缩小这些文件中的任何一个，不包含任何都是安全的。我们可以更进一步，就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文件。正如其他人在这篇文章中提到的：如果你想cat两个文件的输出变成一行而不是两个？换句话说，cat做它应该做的事。这个man的cat只提到读取到EOF的输入，而不是。注意，-n切换cat还将打印出非终止行(或不完全线)作为线-伯爵从1(根据man.)-n对输出行编号，从1开始。现在我们已经了解了POSIX如何定义线，这种行为变得模棱两可，或者实际上是不符合规定的。了解给定工具的用途和遵从性将有助于确定使用EOL结束文件的重要性。在C，C+，Java(JAR)等.有些标准会为有效性规定一个换行符-JS、HTML、CSS不存在这样的标准。例如，与其使用wc -l filename一个人可以做到awk '{x++}END{ print x}' filename，请放心，任务的成功不会受到我们可能不想处理的文件的影响(例如，第三方库，比如我们缩小的JS)。curl(D)-除非我们的意图是真正计算线在符合POSIX的意义上。结语对于某些文本文件(如JS、HTML和CSS)，在EOF跳过EOL的实际用例将很少有负面影响-如果有的话。如果我们依赖于存在的，那么我们将工具的可靠性限制在我们所创建的文件上，并打开自己以避免第三方文件引入的潜在错误。故事的寓意：工程师工具，它没有依赖EOF的EOL的弱点。可以随意发布用例，因为它们适用于JS、HTML和CSS，在这里我们可以检查跳过EOL是如何产生不利影响的。