从手刹CLI输出的zenity --progress [英] Zenity --progress from Handbrake CLI output
问题描述
我的目标是创建具有HandBrakeCLI使用的zenity --progress输出GTK的进度条。我已经遇到了一些碰壁，我想知道如果有人知道一个更好的方式，也可以帮助我，现在我在做什么。
My goal is to create a gtk progress bar with the output of HandBrakeCLI using zenity --progress. I've ran into some snags and I'm wondering if someone knows of a better way or can help me with what I'm currently doing.
正常输出：
HandBrakeCLI -i infile -o outfile --preset=iPad
显示
：任务1中1，11.97％（72.81帧，平均86.78帧，ETA 00h00m43s）
Encoding: task 1 of 1, 11.97 % (72.81 fps, avg 86.78 fps, ETA 00h00m43s)
手刹管道输送到TR和切割指令，所以我只有那个百分比的zenity将期待。
HandBrake piped to tr and cut commands so I only have the percentages that zenity will expect.
HandBrakeCLI -i infile -o outfile --preset=iPad 2>&1 | tr -s '\r' '\n' | cut -b 24-28
结果是我所期望的：
Results in what I would expect:
1.05
1.06
1.10
1.10
不过，输出被延迟了很多，有时甚至不会显示。如果我只用我的TR前pression我得到上面的输出上每一行，但它的整体输出，包括编码：任务......
But, the output is delayed a lot and sometimes won't even display. If I only use my tr expression I get the output above on each line but it's the whole output including "Encoding: task......".
这就像剪切命令不能与性病了手刹跟上。我在使用命名管道读了起来，创造了一个和指导手刹的输出管道然后在另一端试图TR和通过管道切割命令，它会导致相同的延迟。
It's like the cut command can't keep up with the std out of Handbrake. I read up on using named pipes, created one and directed HandBrake's output to the pipe then in another terminal tried the tr and cut command via the pipe and it results in the same delay.
使用awk的打印子也会导致相同的延迟。
Using awk's print substring also results in the same delay.
我不明白。我的的zenity --progress指标后，我因为我的工作手刹被称为一个MythTV的工作，我想一个进度条，弹出，所以我知道什么时候和一间code是过程。
I can't figure it out. I'm after the zenity --progress indicator because my HandBrake job is called as a MythTV job and I'd like a progress bar to pop up so I know when and an encode is in process.
推荐答案
您可以使用该解决方案，回答的在这里stackexchange 。
You can use the solutions answered here on stackexchange.
例如：
的 stdbuf 程序，它是GNU的coreutils的一部分。
The stdbuf program which is part of the GNU coreutils.
stdbuf -i0 -o0 -e0 command
另一个例子是 期望 命令<一HREF =http://expect.sourceforge.net/example/unbuffer.man.html相对=nofollow> 无缓冲 ，如：
unbuffer long_running_command | print_progress
无缓冲通过伪终端（PTY），这使得系统把它作为一个互动的过程连接到 long_running_command 因此不使用在管道是这样的延迟的可能原因的4- KIB缓冲
unbuffer connects to long_running_command via a pseudoterminal (pty), which makes the system treat it as an interactive process, therefore not using the 4-kiB buffering in the pipeline that is the likely cause of the delay.
对于更长的管道，你可能要无缓冲每个命令（除最后一个），例如
For longer pipelines, you may have to unbuffer each command (except the final one), e.g.
unbuffer x | unbuffer -p y | z
这篇关于从手刹CLI输出的zenity --progress的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
