On Sat, Jun 30, 2012 at 10:15 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote:
> On Sat, Jun 30, 2012 at 8:36 PM, Jeff King <peff@xxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html