为什么当我期望1时，tail -n 1在该文件上返回两行

Question

this gist中的文件有两行。

• 当我在其上运行http://localhost:5000/时，两行都将返回（我希望只有最后一行）。
• 当我在其上运行tail -n 1时，仅返回第一行（按预期）。
• 当我在其上运行head -n 1时，它返回1（我希望是2）。

如果我从第一行或第二行中删除一个字符，则某些情况会发生变化：

• [DIFFERENT]当我在其上运行wc -l时，仅返回最后一行（按预期）。
• [SAME]当我在其上运行tail -n 1时，仅返回第一行（按预期）。
• [SAME]当我在其上运行head -n 1时，它返回1（我希望是2）。

这是怎么回事？为什么wc -l和tail的行为与我对该文件的期望不符？

我正在OSX 10.14.2上，一位同事能够在另一台计算机上重现相同的行为。

Answer 1

使用十六进制转储工具查看文件后，看起来文件末尾没有新行。有趣的是，gnu coreutils可以正常处理，但bsd coreutils（MacOS随附）不能。可以在this stackexchange post.

中找到更多信息。

  

本应在文本文件上运行的实用程序可能无法很好地应对   不以换行符结尾的文件；历史上的Unix实用程序   例如，可能会忽略最后一个换行符之后的文本。 GNU   实用程序的策略是对非文本文件表现得体面，并且   大多数其他现代公用事业也是如此，但您仍然可能会遇到奇怪的情况   缺少最后一个换行符¹的文件的行为。

$ hexdump file-with-2-lines.txt
0000000 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
*
0001820 61 61 61 61 61 61 61 61 61 61 61 61 0a 62 62 62
0001830 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62
*
0003000 62
0003001

在编辑文件后（不进行任何更改，仅使用在文件末尾强制使用新行的编辑器）。

$ hexdump file-with-2-lines.txt
0000000 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
*
0001820 61 61 61 61 61 61 61 61 61 61 61 61 0a 62 62 62
0001830 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62
*
0003000 62 0a
0003002

0a是换行符。