关闭管道中的缓冲

我有一个脚本，它调用两个命令：

long_running_command | print_progress

该long_running_command打印进度，但我不开心吧。我print_progress用来使其更美观（即，我将进度打印在一行中）。

问题：将管道连接到stdout还会激活4K缓冲区，到漂亮的打印程序不会得到任何东西……没有任何东西……没有任何东西 ……:)

如何禁用4K缓冲区long_running_command（不，我没有源）？

您可以使用unbuffer命令（expect软件包附带的命令），例如

unbuffer long_running_command | print_progress

unbuffer连接到long_running_command经由一伪终端（PTY），这使得该系统把它作为一个互动的过程，因此不使用在管道即延迟的可能原因的4 KIB缓冲。

对于更长的管道，您可能必须取消缓冲每个命令（最后一个命令除外），例如

unbuffer x | unbuffer -p y | z

这只猫的另一种使用方法是使用该stdbuf程序，该程序是GNU Coreutils的一部分（FreeBSD也有自己的程序）。

stdbuf -i0 -o0 -e0 command

这将完全关闭针对输入，输出和错误的缓冲。对于某些应用程序，出于性能原因，行缓冲可能更适合：

stdbuf -oL -eL command

_{请注意，它仅适用于动态链接的应用程序的stdio缓冲（printf()，fputs()...），并且仅在该应用程序自身不调整其标准流的缓冲的情况下才起作用，尽管这应涵盖大多数应用程序。}

为开启行缓冲输出模式的另一种方法long_running_command是使用在伪终端（pty）script中运行your 的命令long_running_command。

script -q /dev/null long_running_command | print_progress      # FreeBSD, Mac OS X
script -c "long_running_command" /dev/null | print_progress    # Linux

对于grep，sed并且awk可以强制输出为行缓冲。您可以使用：

grep --line-buffered

强制输出进行行缓冲。默认情况下，当标准输出为端子时，输出为行缓冲，否则为块缓冲。

sed -u

使输出线缓冲。

有关更多信息，请参见此页面：http : //www.perkin.org.uk/posts/how-to-fix-stdio-buffering.html

如果在输出未到达终端时libc修改其缓冲/刷新存在问题，则应尝试socat。您可以在几乎任何类型的I / O机制之间创建双向流。其中之一是与伪tty对话的分叉程序。

 socat EXEC:long_running_command,pty,ctty STDIO 

它的作用是

• 创建一个伪tty
• 用pty的从属端将std / stdout派生为long_running_command
• 在pty的主端和第二个地址（此处为STDIO）之间建立双向流

如果此输出与相同long_running_command，则可以继续使用管道。

编辑：哇没有看到unbuffer答案！好吧，无论如何，socat是一个很棒的工具，所以我可能会留下这个答案

您可以使用

long_running_command 1>&2 |& print_progress

问题在于libc在标准输出到屏幕时将行缓冲，而在标准输出到文件时将全缓冲。但是对于stderr没有缓冲。

我不认为这是管道缓冲区的问题，而全是关于libc的缓冲区策略的。

过去是这种情况，也许仍然是这样，当标准输出写入终端时，默认情况下它是行缓冲的-写入换行符时，该行就会写入终端。当标准输出发送到管道时，它将被完全缓冲-因此，仅当标准I / O缓冲区已满时，数据才会发送到管道中的下一个进程。

这就是麻烦的根源。我不确定在不修改写入管道的程序的情况下是否可以做很多修复工作。您可以将setvbuf()函数与_IOLBF标志一起使用，以无条件地stdout进入行缓冲模式。但是我看不到在程序上强制执行此操作的简便方法。或者该程序可以fflush()在适当的时候执行（在输出的每一行之后），但是适用相同的注释。

我想如果用伪终端替换管道，那么标准I / O库将认为输出是终端（因为它是终端的一种），并且会自动进行行缓冲。但是，那是处理事物的复杂方式。

我知道这是一个古老的问题，已经有了很多答案，但是如果您想避免缓冲区问题，请尝试以下操作：

stdbuf -oL tail -f /var/log/messages | tee -a /home/your_user_here/logs.txt

这将实时输出日志，并将它们保存到logs.txt文件中，并且缓冲区将不再影响tail -f命令。

我认为问题不在于管道。听起来您长时间运行的进程没有足够频繁地刷新其自己的缓冲区。更改管道的缓冲区大小将是解决问题的办法，但我认为不重建内核是不可能的-您不希望这样做，因为它可能会影响许多其他进程。

根据此处的这篇文章，您可以尝试将管道ulimit减少到一个512字节块。它当然不会关闭缓冲，但是512字节小于4K：3

与chad的回答类似，您可以编写一个小的脚本，如下所示：

# save as ~/bin/scriptee, or so
script -q /dev/null sh -c 'exec cat > /dev/null'

然后使用此scriptee命令代替tee。

my-long-running-command | scriptee

las，我似乎无法获得在Linux上完美运行的版本，因此似乎仅限于BSD风格的Unix。

在Linux上，这已经关闭了，但是完成时您不会得到提示（直到按Enter等）。

script -q -c 'cat > /proc/self/fd/1' /dev/null

我找到了这个聪明的解决方案： (echo -e "cmd 1\ncmd 2" && cat) | ./shell_executable

这可以解决问题。cat会读取其他输入（直到EOF为止），然后在echo将其参数放入的输入流后将其传递给管道shell_executable。

根据该管道缓冲区大小，似乎在内核中进行设置，并会要求你重新编译内核来改变。