我想执行一个命令,并想重定向stderr和stdout,如下所示:
stderr和stdout->仅应在保持顺序的同时写入logs.log文件
stderr->应该打印到SCREEN并也写入errors.log
到目前为止,我可以将它们重定向到屏幕和文件log.txt,如下所示:
command 2>&1 | tee logs.log
但是以上不是我所需要的。
为了更清楚地说明结果是什么。
执行命令后,我只需要在屏幕上看到stderr的结果,我需要在stderr中有一个名为errors.log的文件,而在目录中需要有stdout和stderr两者都在其中的结果的另一个名为logs.log的文件。创建它们的原始顺序。
从理论上讲,如果没有一些丑陋的黑客手段,则在执行单独的重定向时保持完美的顺序是不可能的。 仅在直接写入同一文件(在O_APPEND模式下)时保留顺序。一旦您将类似的内容tee放入一个过程而不是另一个过程中,则排序保证就会消失,并且如果不保留有关以什么顺序调用了哪些系统调用的信息,就无法检索到排序保证。
tee
那么,这种黑客将是什么样子?它可能看起来像这样:
# eat our initialization time *before* we start the background process sudo 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 file sudo 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()和类似的操作将按预期工作;但是上述内容足以证明这一概念)。
fdup()
在这里,我们演示如何使用此方法仅对stderr着色,并让stdout保持不变-通过告诉sysdig生成JSON流作为输出,然后对其进行迭代:
sysdig
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),所以对于上面的代码来说,这些文件名必须是常量-可以使用所需的任何临时目录。
stdout
stderr
显然,您实际上不应执行任何此类操作。 更新程序以支持其本国语言(Java中的Log4j,Python日志记录模块等)可用的任何日志记录基础结构,以允许对其日志记录进行显式配置。