Re: input characters echoing is broken

[Rubén Gonzalez]

Thank you for your information.

I think you pointed to the issue:
https://github.com/FFmpeg/FFmpeg/blob/7ed1e806e76092df27d7f984a554546a1cf1a175/fftools/ffmpeg.c#L219

Solution WIP.

Thank you :)


On Fri, Feb 16, 2024 at 4:02 PM Kerin Millar <kfm@plushkava.net> wrote:

> On Fri, 16 Feb 2024 15:27:28 +0100
> Rubén Gonzalez <rgonzalez@fluendo.com> wrote:
>
> > Hello
> >
> > I am a maintainer of Fluster, an open-source testing framework for video
> > decoder conformance.
> >
> > After researching a bug reported [1], we could create a simple Python
> > script that breaks bash input characters echoing.
> >
> > The Python script is in the GitHub issues. As I can not reproduce the
> issue
> > with other shells, I imagine it is related to bash. Can you help me with
> > the next steps to check? Or ideas to research?
> >
> > Thank you very much,
> > Ruben
> >
> > [1] https://github.com/fluendo/fluster/issues/147
>
> Bash should not be involved in any capacity because you execute
> subprocess.run() method without setting shell=True, although you could
> still execute bash in the case that the value of command is ["bash", "-c",
> "shell code goes here"].
>
> Regardless, any application run in a terminal - including ffmpeg - is free
> to print escape sequences that might alter the behaviour of the terminal.
> Applications may also use the standard termios(3) interface to alter the
> behaviour of the terminal. As an example, try running "stty -echo" in your
> shell. You'll find that, henceforth, your keyboard input is no longer
> echoed. That happens because stty(1) is being instructed to use said
> interface to disable ECHO for your terminal's input mode. It has nothing to
> do with the shell.
>
> In the issue, you claim that the terminal behaviour is altered even in the
> case that STDOUT and STDERR are redirected to /dev/null. That makes it
> somewhat unlikely that escape sequences are to blame, though it's still
> possible for an application to open and write to /dev/tty directly. As an
> experiment, you could try redirecting STDIN with </dev/null. Perhaps the
> behaviour of whatever it is that you are executing will vary based on
> whether the standard input is found to be a tty or not. You could also wrap
> the application with a tracing utility - such as strace - to get a better
> understanding of what it is doing.
>
> --
> Kerin Millar
>

--