主页 / unix / 问题 / 550315
Accepted
golimar
Asked: 2019-11-05 06:43:23 +0800 CST

多个进程使用 > 重定向到同一个文件

  • 772

这不是“如何附加而不是覆盖”的问题。我不是在寻找结合了两个命令的输出的文件。这只是我犯的一个错误，我想了解系统为什么会这样做

我使用一个命令（在远程 ssh 命令行上）需要很长时间才能完成并将数据（每隔几秒逐行）输出到标准输出，所以我将它重定向到一个文件：

command > file.out &

有时远程会话会断开连接，但命令会继续在后台运行。我不知道这一点，所以我在第一个命令完成之前再次运行相同的命令：

command > file.out &

当两个进程都完成后，我希望（在阅读了这个站点的一些答案之后）有一个文件，其中两个命令的行都搞砸了，但输出文件只有两个执行之一的输出。

为什么文件没有两个输出交织在一起（如这里的评论中警告的那样）？最终文件属于 2 个输出中的哪一个？

编辑：

删除了其中一个问题（为什么输出文件没有被锁定以进行写入？），正如这里所解释的那样

bash

1 个回答

  1. Best Answer

    当您使用>重定向打开一个文件进行写入时，该文件被截断，即它被完全清空。但是，它不会被删除和重新创建。

    如果一个命令从截断文件开始，然后向其中写入一些内容，并且如果另一个命令随后执行相同操作，则第一个命令在文件中的位置不会改变。这意味着您有两个命令在两个独立的位置写入同一个文件，一个可能会覆盖另一个的输出，具体取决于写入的顺序和正在写入的数据量。

    所以，是的，文件中的数据很可能是两个程序的输出交织在一起，但这取决于写入文件的顺序，以及写入的数据量和截断的时间。文件。

    这是一个将来自两个命令的数据交织在一起的示例：

    #!/bin/sh

( { echo hello; sleep 2; echo world; } | cat >file ) &
sleep 1
echo 123 >file &

wait

    这是此脚本中发生的情况：

    1. 第一个命令打开文件进行写入并截断它。它写给hello\n它。
    2. 一秒钟后，第二个命令截断文件并写入文件123\n。此时，第一个命令的文件指针仍然指向文件的某个偏移量。
    3. 第一个命令继续写入world\n文件。

    结果是一个中间有一段 nul 字符的文件：

    $ hexdump -C file
00000000  31 32 33 0a 00 00 77 6f  72 6c 64 0a              |123...world.|
0000000c

    nuls（00在上面的输出中）来自这样一个事实，即第一个命令的文件指针没有被第二个命令的文件截断重置，因此创建了一个“洞”。第二个命令只写入123\n但如果写入更多数据就会覆盖 nuls：

    $ hexdump -C file
00000000  31 32 33 35 36 37 77 6f  72 6c 64 0a              |123567world.|
0000000c

    在这里，我做了第二个命令echo 1234567890，但1234567文件中只剩下了。world\n这是因为在第二个命令完成写入之后，第一个命令在其文件指针所在的点继续写入。

    • 10

相关问题