xargs的：标准输出重定向到并行模式下的文件时丢失输出 [英] xargs: losing output when redirecting stdout to a file in parallel mode

问题描述

我在并行模式下使用GNU的xargs（版本4.2.2），我似乎重定向到一个文件时，能够可靠地失去输出。当重定向到一个管道，它似乎正常工作。

下面的shell命令演示最小的，完整的和可核查的例子的问题。我用生成数字2550 的xargs 将其分割成100 ARGS每个共26行，其中26号线只包含50 args来行。

 ＃产生1 2550数字，每个数字都是其自己的行
$序列1 2550＆GT;的/ tmp / NUMS
$厕所-l / tmp目录/ NUMS
2550的/ tmp / NUMS＃管路WC是准确的：26线，2550 ARGS
$ xargs的-P20 -n 100℃的/ tmp / NUMS |厕所
     26 2550 11643＃重定向到一个文件显然是不准确的：22线，2150 ARGS
$ xargs的-P20 -n 100℃的/ tmp / NUMS＆GT;的/ tmp /输出;厕所的/ tmp /输出
     22 2150 10043的/ tmp /输出
 

我相信，因为命令执行之前shell将执行重定向并等待xargs的完成问题不涉及到底层的外壳。在这种情况下，我推测是xargs的刷新缓冲区前完成。但是，如果我的假设是正确的，我不知道为什么写管道时这个问题并不明显。

编辑：

使用它时，会出现＆GT;＆GT; （创建/附加到文件）的外壳，看起来问题不体现：

 ＃附加到文件
$＆GT;的/ tmp /输出
$ xargs的-P20 -n 100℃的/ tmp / NUMS＆GT;＆GT;的/ tmp /输出;厕所的/ tmp /输出
     26 2550 11643＃创建和附加到文件
$ RM / TMP /输出
$ xargs的-P20 -n 100℃的/ tmp / NUMS＆GT;＆GT;的/ tmp /输出;厕所的/ tmp /输出
     26 2550 11643
 

解决方案

您的问题是由于来自不同的进程输出混合。它如下所示：

 平行的perl -e'\\ $ A = \\{1} \\x10000000 \\;打印\\ \\ $ A，\\\\\\ñ\\''＆GT;' {} ::: A B C D E F
ls -l命令A B C D E F
平行-kP4 -n1 grep的1＆GT; out.par ::: A B C D E F
回声B C D E F | xargs的-P4 -n1 grep的1＆GT; out.xargs-unbuf
回声B C D E F | xargs的-P4 -n1 grep的--line缓冲1＆GT; out.xargs-linebuf
回声B C D E F | xargs的grep的-n1 1 GT; out.xargs串行
ls -l命令出*
MD5SUM出*
 

的解决方案是缓冲来自每个作业的输出 - 无论是在内存或TMPFILES（像GNU并行那样）

。

I am using GNU xargs (version 4.2.2) in parallel mode and I seem to be reliably losing output when redirecting to a file. When redirecting to a pipe, it appears to work correctly.

The following shell commands demonstrates a minimum, complete, and verifiable example of the issue. I generate 2550 numbers using xargs to split it into lines of 100 args each totalling 26 lines where the 26th line contains only 50 args.

# generate numbers 1 to 2550 where each number is on its own line
$ seq 1 2550 > /tmp/nums
$ wc -l /tmp/nums
2550 /tmp/nums

# piping to wc is accurate: 26 lines, 2550 args
$ xargs -P20 -n 100 </tmp/nums | wc
     26    2550   11643

# redirecting to a file is clearly inaccurate: 22 lines, 2150 args
$ xargs -P20 -n 100 </tmp/nums >/tmp/out; wc /tmp/out
     22  2150 10043 /tmp/out

I believe the problem is not related to the underlying shell since the shell will perform the redirection before the commands execute and wait for xargs to complete. In this case, I hypothesize xargs is completing before flushing the buffer. However if my hypothesis is correct, I do not know why this problem doesn't manifest when writing to a pipe.

Edit:

It appears when using >> (create/append to file) in the shell, the problem doesn't seem to manifest:

# appending to file
$ >/tmp/out
$ xargs -P20 -n 100 </tmp/nums >>/tmp/out; wc /tmp/out
     26    2550   11643

# creating and appending to file
$ rm /tmp/out
$ xargs -P20 -n 100 </tmp/nums >>/tmp/out; wc /tmp/out
     26    2550   11643

解决方案

Your problem is due to the output from different processes being mixed. It is shown here:

parallel perl -e '\$a=\"1{}\"x10000000\;print\ \$a,\"\\n\"' '>' {} ::: a b c d e f
ls -l a b c d e f
parallel -kP4 -n1 grep 1 > out.par ::: a b c d e f
echo a b c d e f | xargs -P4 -n1 grep 1 > out.xargs-unbuf
echo a b c d e f | xargs -P4 -n1 grep --line-buffered 1 > out.xargs-linebuf
echo a b c d e f | xargs -n1 grep 1 > out.xargs-serial
ls -l out*
md5sum out*

The solution is to buffer the output from each job - either in memory or in tmpfiles (like GNU Parallel does).

这篇关于xargs的：标准输出重定向到并行模式下的文件时丢失输出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！