为什么`tail -n 1`在这个文件中返回两行，当我期望1

Question

this gist中的文件有两条长行。

• 当我在它上面运行tail -n 1时，两行都返回（我希望只有最后一行）。
• 当我在其上运行head -n 1时，只返回第一行（如预期的那样）。
• 当我在它上面运行wc -l时，它返回1（我希望2）。

如果我从第一行或第二行删除一个字符，那么有些东西会改变：

• [不同]当我在其上运行tail -n 1时，只返回最后一行（如预期的那样）。
• [相同]当我在其上运行head -n 1时，只返回第一行（如预期的那样）。
• [相同]当我在它上面运行wc -l时，它返回1（我希望2）。

这里发生了什么？为什么tail和wc的表现不如我在这个档案上所期望的那样？

我在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是换行符。