bug#17839: 24.4.50; read-passwd echoes password input in non-interactive sessions

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@iro.umontreal.ca,  schwab@suse.de,  17839@debbugs.gnu.org,  swiesner@lunaryorn.com
> Date: Fri, 11 Jul 2014 16:57:40 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The result is not 100% satisfactory, as one needs to press RET twice
> > to finish the input, and it looks like some garbage is left in the
> > input buffer, since the following (normal) input gets something
> > strange.  A workaround is to press C-z, which produces EOF, instead of
> > RET, when password entry is finished.
> 
> Maybe because just "\n" is sent by fprintf()? In the Windows case,
> "\r\n" might be the better choice?

I don't think so.  The problem is not what is printed, the problem is
that the loop is not exited on the 1st RET, and in fact it looks like
nothing is returned by getchar until you press the 2nd RET.

> And maybe we must handle the case, that RET sends 2 characters, which
> must be handled by a double call of getchar()?

It doesn't look like it sends 2 characters: the next call to getchar
after exiting the loop waits for more input.

> When I've read the code of read_minibuf_noninteractive for the first
> time, I've seen that just CR was used for finishing input

You mean, just the newline, right?

> and I've thought that nobody ever used this for MS Windows.

That code worked perfectly well with cooked input mode, since then RET
is converted to a newline by the stdio machinery (as it uses text
mode).

And that just gave me an idea: switch stdin to binary when not echoing
input.  Which solved the problem of double RET (and now it's clear why
it was being eaten up).

Thanks.