vi 是否会在文件末尾默默添加换行符 (LF)？

Question 1

POSIX 需要这种行为，所以它没有任何异常。

输入文件

有关 vi 命令支持的输入文件的说明，请参阅 ex 命令的输入文件部分。

输入文件

输入文件应为文本文件或将是文本文件的文件，但不完整的最后一行长度不超过 {LINE_MAX}-1 字节且不包含 NUL 字符。默认情况下，任何不完整的最后一行都应被视为有尾随 <newline>。 ex 实现可以选择允许编辑其他形式的文件。

vi 手册的输出文件部分也重定向到 ex：

输出文件

ex 的输出应为文本文件。

一对 POSIX 定义：

3.397 文本文件

包含组织成零行或多行的字符的文件。这些行不包含 NUL 字符，且长度不能超过 {LINE_MAX} 个字节，包括 <newline> 字符。尽管 POSIX.1-2008 不区分文本文件和二进制文件（请参阅 ISO C 标准），但许多实用程序在操作文本文件时仅产生可预测或有意义的输出。具有此类限制的标准实用程序始终在其 STDIN 或 INPUT FILES 部分中指定“文本文件”。

3.206线

零个或多个非 <newline> 字符加上终止 <newline> 字符的序列。

这些手册页摘录上下文中的这些定义意味着，虽然一致的 ex/vi 实现必须接受格式错误的文本文件（如果该文件的唯一缺陷是最终换行符缺失），但在写入该文件的缓冲区时，结果必须是有效的文本文件。

虽然这篇文章引用了 2013 版 POSIX 标准，相关规定也出现在更早的1997年版本中。

最后，如果您发现 ex 的换行符不受欢迎，您会感到第七版 UNIX (1979) 的不宽容 ed 严重侵犯了您。来自手册:

读取文件时，ed 会丢弃 ASCII NUL 字符以及最后一个换行符之后的所有字符。它拒绝读取包含非 ASCII 字符的文件。

Answer

POSIX 需要这种行为，所以它没有任何异常。

来自POSIX vi 手册:

输入文件

有关 vi 命令支持的输入文件的说明，请参阅 ex 命令的输入文件部分。

循着小道来到POSIX 前手册:

输入文件

输入文件应为文本文件或将是文本文件的文件，但不完整的最后一行长度不超过 {LINE_MAX}-1 字节且不包含 NUL 字符。默认情况下，任何不完整的最后一行都应被视为有尾随 <newline>。 ex 实现可以选择允许编辑其他形式的文件。

vi 手册的输出文件部分也重定向到 ex：

输出文件

ex 的输出应为文本文件。

一对 POSIX 定义：

3.397 文本文件

包含组织成零行或多行的字符的文件。这些行不包含 NUL 字符，且长度不能超过 {LINE_MAX} 个字节，包括 <newline> 字符。尽管 POSIX.1-2008 不区分文本文件和二进制文件（请参阅 ISO C 标准），但许多实用程序在操作文本文件时仅产生可预测或有意义的输出。具有此类限制的标准实用程序始终在其 STDIN 或 INPUT FILES 部分中指定“文本文件”。

3.206线

零个或多个非 <newline> 字符加上终止 <newline> 字符的序列。

这些手册页摘录上下文中的这些定义意味着，虽然一致的 ex/vi 实现必须接受格式错误的文本文件（如果该文件的唯一缺陷是最终换行符缺失），但在写入该文件的缓冲区时，结果必须是有效的文本文件。

虽然这篇文章引用了 2013 版 POSIX 标准，相关规定也出现在更早的1997年版本中。

最后，如果您发现 ex 的换行符不受欢迎，您会感到第七版 UNIX (1979) 的不宽容 ed 严重侵犯了您。来自手册:

读取文件时，ed 会丢弃 ASCII NUL 字符以及最后一个换行符之后的所有字符。它拒绝读取包含非 ASCII 字符的文件。

Question 2

这是预期的vi行为。

您的文件的最后一行不完整，因此严格来说（即根据 POSIX 标准），它不是文本文件，而是二进制文件。

vi这是一个文本文件编辑器，而不是二进制文件编辑器，在保存时可以优雅地修复它。

这允许其他文本文件工具（如wc、sed等）提供预期的输出。请注意，并vi没有对这个问题保持沉默：


$ printf "one\ntwo" >file     # Create a unterminated file
$ cat file                    # Note the missing newline before the prompt
one
two$ wc -l file               # wc ignores the incomplete last line
       1 file
$ sed '' file > file1
$ cat file1                   # so does a legacy sed
one
$ PATH=$(getconf PATH) sed  '' file
one                           # while a POSIX conformant sed warns you:
sed: Missing newline at end of file file.
two
$ vi file
one
two
~
~
~                             # vi tells you too about the issue
"file" [Incomplete last line] 2 lines, 7 characters

:w

"file" 2 lines, 8 characters  # and tells it writes two lines
                              # You'll even notice it writes one more
                              # character if you are a very shrewd observer :-)
:q
$ cat file                    # the file is now valid text
one
two
$ wc -l file                  # wc reports the expected number of lines
       2 file
$ sed '' file > file1         # sed works as expected
$ cat file1
one
two

请注意，要获取有关vi您正在运行的版本的一些线索，您可以使用该:ve命令。它显示这里我正在使用旧版 SVR4，绝对不是vim：

:ve
Version SVR4.0, Solaris 2.5.0

显然，你的说法是：

:ve
Version 3.10

这可能意味着 AIXvi基于 SVR3 源代码。

无论如何，这种行为和[Incomplete last line]警告消息至少从 1979 年起就一直存在于 Bill Joy 的遗留vi源代码中，据我所知，保留在从 System V 源代码版本创建的所有分支中，并从中构建了专有的 Unix（如 AIX）。

从时间顺序来看，这种行为并不是 POSIX 一致性的结果，而更多的是 Bill Joy 最初决定帮助用户编辑虚假文本文件的结果，然后，十年后，POSIX 委员会决定保持这种宽容。

如果您使用ed而不是vi，您会注意到前者对于该问题更加详细，至少如果您ed来自 SVR3 或更新的源分支：

$ ed file
'\n' appended
8
q

另请注意，空文件是恰好包含零行的有效文本文件。由于没有未终止的行需要修复，因此vi在保存文件时不会附加换行符。

Answer