Question

我的目标是使用zenity --progress创建一个带有HandBrakeCLI输出的gtk进度条。我遇到了一些障碍，我想知道是否有人知道更好的方法，或者可以帮助我解决我目前正在做的事情。

正常输出：

HandBrakeCLI -i infile -o outfile --preset=iPad

显示

编码：任务1的1,1.9.9％（72.81 fps，平均86.78 fps，ETA 00h00m43s）

HandBrake用管道传输tr并削减命令，所以我只有zenity所期望的百分比。

HandBrakeCLI -i infile -o outfile --preset=iPad 2>&1 | tr -s '\r' '\n' | cut -b 24-28

我期望的结果：

但是，输出延迟很多，有时甚至不会显示。如果我只使用我的tr表达式，我会在每一行上面得到输出，但它是整个输出，包括“编码：任务......”。

这就像cut命令无法跟上Handbrake的标准。我读到了使用命名管道，创建了一个并将HandBrake的输出定向到管道然后在另一个终端通过管道尝试了tr和cut命令，它会导致相同的延迟。

使用awk的print子字符串也会导致相同的延迟。

我无法理解。我追求zenity --progress指标，因为我的HandBrake工作被称为MythTV工作，我想要一个进度条弹出，所以我知道什么时候和编码正在进行中。

Answer 1

您可以使用已解答的解答here on stackexchange。

例如：

stdbuf程序，它是GNU coreutils的一部分。

stdbuf -i0 -o0 -e0 command

另一个例子是expect命令unbuffer，例如

unbuffer long_running_command | print_progress

unbuffer通过伪终端（pty）连接到long_running_command，这使得系统将其视为交互式进程，因此不会在管道中使用4-kiB缓冲，这可能是延迟。

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

unbuffer x | unbuffer -p y | z

Answer 2

使用erik建议的UNBUFFER与你的第一篇文章一起使用，以下命令可以解决这个问题：

( HandBrakeCLI -i infile -o outfile --preset=iPad | 
        unbuffer -p grep -i "encoding: task " | 
        unbuffer -p cut -c24-25 ) | 
        zenity --progress --auto-close

Zenity - 来自Handbrake CLI输出的进展

2 个答案: