Re: Regression: 'read -s' does not disable echo

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Tue, Jan 2, 2024 at 9:05 AM Peter Stephenson
<p.w.stephenson@xxxxxxxxxxxx> wrote:
>
> > On 02/01/2024 15:25 GMT Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx> wrote:
> >
> > Folks, there's a regression on git mainline such that `read -s` does not
> > suppress terminal echo.
>
> That's not very friendly.  I guess it's to do with the way
> readfd is handled.  Something like this, or more general?

This dates from workers/51969 (commit aa85564), which means this may
have affected the -d option as well.  At the time I said "would
appreciate another eyeball" but never got one ...

> -    if (OPT_ISSET(ops,'s') && SHTTY == readfd) {
> +    if (OPT_ISSET(ops,'s') &&
> +       (SHTTY == readfd || (readfd == 0 && isatty(0)))) {

Previous tests here were for (SHTTY != -1) which was causing incorrect
calls to gettyinfo() when shell input was not closed but stdin was
redirected.  I'm now unsure whether (SHTTY == readfd) is ever true
here?  I expect the original code was trying to avoid the overhead of
isatty().

However, there may be a deeper problem:  gettyinfo() always reads the
state of the controlling TTY, but it's possible that "read -s" has
been called with input and output redirected from a different tty
device.