Matthew Stickney <mtstickney@gmail.com> writes:
> On Tue, May 22, 2018 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> But perhaps it's worth adding logic to deal with failure of the call?
> I think it would be sufficient to check whether the SetConsoleMode
> call fails, because that can fail even on a valid handle (e.g. if you
> don't have a handle with write access). That would catch the case
> where opening termin fails, too, although that might deserve it's own
> check to get better error information.
> simple_prompt seems to be used in a lot of different utilities for
> different reasons; there seem to be a number of conventions for
> reporting errors in src/port/ code, but it looks like other
> interactive utilities generally print a message to stderr, and return
> a basic success/failure value. Does that sound like the right
> approach? I'm not sure if it's obvious how to handle errors in the
> other utilities, but I can take a look.
Well, the question that ought to be answered first is whether to do
anything at all, beyond not-crashing. It doesn't seem to me that
refusing to accept a password if we can't disable echo is a net win,
so I'm inclined to think it's okay to silently ignore failure to
turn off echo.
The other aspect of this code that maybe needs consideration is the
silent fallback to use stdin/stderr if we can't open the console.
It seems like that could be a really bad idea if stdin is a pipe.
But on the other hand, maybe somebody is depending on it somewhere?
I'm not sure I'd want to back-patch a change in that behavior, anyway.
regards, tom lane
