从理论上讲，如果没有一些丑陋的黑客手段，则在执行单独的重定向时保持完美的顺序是不可能的。
仅在直接写入同一文件（在O_APPEND模式下）时保留顺序。一旦您将类似的内容
tee放入一个过程而不是另一个过程中，则排序保证就会消失，并且如果不保留有关以什么顺序调用了哪些系统调用的信息，就无法检索到排序保证。
那么，这种黑客将是什么样子？它可能看起来像这样：
# eat our initialization time *before* we start the background processsudo sysdig-probe-loader# now, start monitoring syscalls made by children of this shell that write to fd 1 or 2# ...funnel content into our logs.log filesudo sysdig -s 32768 -b -p '%evt.buffer' "proc.apid=$$ and evt.type=write and (fd.num=1 or fd.num=2)" > >(base64 -i -d >logs.log) & sysdig_pid=$!# Run your-program, with stderr going both to console and to errors.log./your-program >/dev/null 2> >(tee errors.log)
也就是说，这仍然是丑陋的骇客：它只捕获直接写入FD 1和FD
2的消息，并且不会跟踪可能发生的任何进一步重定向。（可以通过执行对FIFO的写操作，并使用sysdig跟踪对这些FIFO的写操作来改善这一点；这种方式
fdup()和类似的操作将按预期工作；但是上述内容足以证明这一概念）。
明确进行 单独处理 __
在这里，我们演示如何使用此方法仅对stderr着色，并让stdout保持不变-通过告诉
sysdig生成JSON流作为输出，然后对其进行迭代：
exec {colorizer_fd}> >( jq --unbuffered --arg startColor "$(tput setaf 1)" --arg endColor "$(tput sgr0)" -r ' if .["fd.filename"] == "stdout" then ("STDOUT: " + .["evt.buffer"]) else ("STDERR: " + $startColor + .["evt.buffer"] + $endColor) end ')sudo sysdig -s 32768 -j -p '%fd.filename %evt.buffer' "proc.apid=$$ and evt.type=write and proc.name != jq and (fd.num=1 or fd.num=2)" >&$colorizer_fd & sysdig_pid=$!# Run your-program, with stdout and stderr going to two separately-named destinations./your-program >stdout 2>stderr因为我们要取消输出文件名（
stdout和
stderr），所以对于上面的代码来说，这些文件名必须是常量-可以使用所需的任何临时目录。
显然，您实际上不应执行任何此类操作。
更新程序以支持其本国语言（Java中的Log4j，Python日志记录模块等）可用的任何日志记录基础结构，以允许对其日志记录进行显式配置。
