[FFmpeg-devel] Fwd: [PATCH 1/2] ffmpeg: reset tty state correctly
gajjanag at mit.edu
Mon Jul 27 15:37:47 CEST 2015
On Mon, Jul 27, 2015 at 9:33 AM, Nicolas George <george at nsup.org> wrote:
> Le nonidi 9 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit :
>> > ttyctl -f
>> Sure, but this is a command invoked once ffmpeg exits.
> This is a command that should be present in everybody's .zshrc.
Wasn't there in mine, thanks!
>> What I meant to say was that ffmpeg changes tty state,
>> and upon a sigsegv, it did not change the state back, leaving the
>> terminal messed up.
> Yes. Like all programs that change the tty state and crash. FFmpeg is not
> special, and should not act special.
>> The point of this patch is to try to fix 2964 while still not
>> clobbering the terminal.
> As I told you, 2964 would be fixed by checking only stdin when changing the
> input-related tty options.
No, since 2964 reports command:
ffmpeg -f lavfi -i testsrc -f null - 2>/dev/null
Say I change this trivially to:
</dev/null ffmpeg -f lavfi -i testsrc -f null - 2>/dev/null
Then your solution would not work.
>> BTW, I do not know whose responsibility this is (process or shell invoking it):
> Since there are uncatchable signals, it can only be the responsibility of
> the shell. Apparently, only the authors of zsh and a few users realized
>> Ok. But then you realize that there is no solution that will fix 2964
> There is no solution that will avoid leaving the tty in a changed state on a
> crash, which is perfectly normal: this is a crash.
>> Agreed completely, I do not like this ugly hack,
>> and wanted to clarify the hack needed to disable this warning.
>> BTW, it is actually more of a glibc thing,
>> as seen from the GCC bugzilla discussion:
> IIRC, the GNU guys are very fond of sending passing each other the blame to
> avoid fixing bugs.
> Nicolas George
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel