Zenity——Handbrake CLI 输出的进度答案

【问题标题】：Zenity --progress from Handbrake CLI outputZenity——Handbrake CLI 输出的进度
【发布时间】：2012-11-21 10:16:56
【问题描述】：

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

正常输出：

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

显示

编码：任务 1 of 1，11.97 %（72.81 fps，平均 86.78 fps，ETA 00h00m43s）

HandBrake 通过管道传输到 tr 和 cut 命令，所以我只有 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 的打印子字符串也会导致相同的延迟。

我想不通。我正在使用 zenity --progress 指示器，因为我的 HandBrake 作业被称为 MythTV 作业，我希望弹出一个进度条，以便我知道何时以及编码正在进行中。

【问题讨论】：

真的是输出延迟了吗？还是 zenity 将 % 截断为仅整数部分？您可以在 zenity 之前使用 tee /dev/stderr（或 /dev/tty）进行检查。
输出被 cut 延迟，但到了 cut 命令似乎跟不上数据的地方。我确实尝试过使用 zenity，但永远无法获得进度条的更新。我想这是因为 cut 很难跟上。
我刚刚尝试添加 | tee /tmp/pipe1 并在另一个终端执行 tail -f /tmp/pipe1。即使不使用 cut 命令，我也会得到相同的延迟输出。只需通过管道引导原始 HandBrake 输出，它不会更新，但可能每 10 秒更新一次，并且更新会逐渐落后。
所以基本上，我试图找出管道中的哪个部分正在执行缓冲或以其他方式消耗时间。
在 tr 和 cut 命令之间。 tr -s '\r' '\n' | cut -b 24-28 出tr没问题，但没出cut。

标签： bash zenity

【解决方案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

【讨论】：

最后一条命令有问题。我运行unbuffer xxd -ps /usr/bin/telnet | unbuffer -p less 并得到Missing filename ("less --help" for help)。标志-p 在您的命令中的作用是什么？我也在这里问过这个问题unix.stackexchange.com/q/212364/16920
@Masi：不，没有错。您的命令是错误的，因为您在最后一个命令中使用了unbuffer。请参阅我对您问题的回答。

【解决方案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

【讨论】：