我有 4 个文本文件，每个文件约有 1700 万行（或行，如果你愿意的话）。这些文件分别命名为 1.txt、2.txt、3.txt 和 4.txt。文本文件 1.txt 包含以下示例数据；
0,0:
1,0:
2,0:
3,0:
只是一对用逗号和冒号分隔的数字。文本文件 2.txt 包含以下示例数据；
(0,0,0)
(0,0,257)
(0,0,514)
只是由逗号分隔的三个数字的组，开头和结尾都有开括号和闭括号。文本文件 3.txt 包含以下示例数据；
#000000
#000001
#000002
仅包含 6 个字符的十六进制数字，开头带有井号。最后，文本文件 4.txt 包含以下示例数据；
srgb(0,0,0)
srgb(0,0,1)
srgb(0,0,2)
我一直试图将四个文本文件合并为一个，并用制表符分隔。输出应如下所示；
0,0: (0,0,0) #000000 srgb(0,0,0)
1,0: (0,0,257) #000001 srgb(0,0,1)
2,0: (0,0,514) #000002 srgb(0,0,2)
3,0: (0,0,771) #000003 srgb(0,0,3)
我努力了
paste -d "\t" 1.txt 2.txt 3.txt 4.txt> final.txt
但我得到了一些奇怪的结果，其中的一个示例看起来像
0,0: (0,0,0) #000000
srgb(0,0,0)
1,0: (0,0,257) #000001
srgb(0,0,1)
2,0: (0,0,514) #000002
srgb(0,0,2)
3,0: (0,0,771) #000003
srgb(0,0,3)
问题是第四列跳过了一个新行，这对我来说是意料之外的。有什么解决方案可以解决这个问题吗？我在 Windows 8.1 上，并且安装了 Git 来运行 Linux 命令。
答案1
我的猜测是3.txt（或者可能4.txt）使用CR+LF 行尾（DOS/Windows 风格），其他文件使用唯一的LF（Unix 风格）。paste期望以 结尾的行LF，它将被视为CR常规字符。实际上，您得到的是CR输出中每个预期行的中间部分。
一些文本编辑器很灵活，它们在检测到CR+ LF、 soleCR或 sole后会转到下一行LF。这样，CR当您检查文件时，多余的字符会生成额外的行：在示例中，您看到的不是四行，而是八行。许多 Linux 工具仍会在那里感知到四行。
在 Linux 中file *.txt会告知您有关外来行结尾的信息；dos2unix 3.txt并会修复它们。
其中一个文件包含CR+的原因LF可能是您使用某些 Windows 工具生成了它，该文件来自 Windows 世界。
还要注意 POSIX 要求所有行都以 结尾LF，而在 Windows 中（我认为）最后一行可能不以CR+结尾LF。我知道dos2unix不会LF在最后添加缺失值（其他转换器可能会）。不完整的最后一行可能会使 Linux 工具抱怨或“行为不当”（例如忽略该行）。在 Linux 文本编辑器中打开文件和储蓄可能会修复它；一般来说，这取决于编辑器及其配置。