Re: git_getpass regression?

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Jul 3, 2012, 16:28 UTC
Message-ID: <CABPQNSZGcReC4CgaYcmwsXyGSqzQgHKQceZ2M5D=zQmyAs8_Ug@mail.gmail.com>
In-Reply-To: <CABPQNSYP6mUZb-1dCifytRxqP7_grzYzON2bjevK2zsGawb-yg@mail.gmail.com>

On Sat, Jun 30, 2012 at 10:15 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:

Show 26 quoted lines

> On Sat, Jun 30, 2012 at 8:36 PM, Jeff King <peff@peff.net> wrote:
>> On Sat, Jun 30, 2012 at 01:27:09PM +0200, Erik Faye-Lund wrote:
>>> +     if (!echo) {
>>> +             hconin = CreateFile("CONIN$", GENERIC_READ | GENERIC_WRITE,
>>> +                 FILE_SHARE_READ, NULL, OPEN_EXISTING,
>>> +                 FILE_ATTRIBUTE_NORMAL, NULL);
>>> +             if (hconin == INVALID_HANDLE_VALUE) {
>>> +                     fclose(input_fh);
>>> +                     fclose(output_fh);
>>> +                     return NULL;
>>> +             }
>>> +             GetConsoleMode(hconin, &cmode);
>>> +             if (!SetConsoleMode(hconin, cmode & (~ENABLE_ECHO_INPUT)))
>>> {
>>> +                     fclose(input_fh);
>>> +                     fclose(output_fh);
>>> +                     return NULL;
>>> +             }
>>
>> The HAVE_DEV_TTY version takes care to reset this on signal death or
>> premature exit (so if you ^C out of the program, your terminal is not
>> left in a funny state). You might want to do something similar here.
>>
>
> Good point. I'll look into adding a Ctrl+C handler routine that cleans up.
>

Actually, it seems the shells (at least CMD.exe and MSYS bash) sets the console mode to something sane when the process exits, so in reality this doesn't seem to matter much. But I'd like to play nice with the system if I can.

Adding a Control-handler that simply restores the console-mode only made it behave slightly worse for me. A control-handler in Windows runs from a separate thread *without halting the other threads*. Combine that with the fact that the IO-call returns EOF when Ctrl+C is entered, the result is that the calling thread and the Control-handler thread race to restore the console-mode. The result is a correctly restored terminal, but with a sporadous "could not read"-error based on who wins the race.

But there are more gotchas: Ctrl+C is sent to all processes that share the console on Windows. And it seems that Bash actually terminate it's child-process when it receive Ctrl+C! This can happen *before* we even get the Ctrl+C handler in our process, preventing us from restoring the console mode. Luckily this doesn't seem to cause any harm, because Bash seems to set a sane console mode itself.

Is there some other way of getting EOF from the console than Ctrl+C? If not, perhaps we can disable the Ctrl+C handling altogether for the current process, and restore the console mode on EOF? That only leaves the "Bash kills our process"-case, but Bash seems to set a sane console mode anyway.