{"thread":{"id":"30928","subject":"git_getpass regression?","startedAt":"2012-06-29T10:06:31Z","lastAt":"2012-07-18T14:23:55Z","messageCount":10,"participants":["Erik Faye-Lund","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"194434","messageId":"CABPQNSa4uvgijjGCSJDXDMqHC3UkqQKKujG3xDFqnQ13LNrKdQ@mail.gmail.com","threadId":"30928","inReplyTo":null,"subject":"git_getpass regression?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-06-29T10:06:31Z","receivedAt":"2012-06-29T10:06:31Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"Since 9b4b894 (\"Makefile: linux has /dev/tty\", 2011-12-10) we're\nreading input from the terminal using strbuf_getline instead of\ngetpass. But at least on my linux-box, getpass treats the\nbackspace-key ('\\b') as an actual deletion. strbuf_getline obviously\nshouldn't do this, as it's a utility function. But I think as a\nuser-interface feature, it would be much more pleasant to be allowed\nto edit the entered text ;)\n\nI can't find anything in POSIX that standardize this behavior, but for\nmost text-input use-cases it's probably what the user intended.\n\nI guess this is technically a regression, but probably not a very important one.\n\nI think we have multiple possible solutions:\n 1) Read a character at the time, and special-case '\\r' to erase the\npreviously entered character.\n 2) Post-process the strbuf to explicitly perform the erasing.\n 3) Do nothing.\n\nI'm in favor of 2) because I'm a Windows-user, and we never had the\nerasing-behavior to begin with. And it's a nice feature, so we could\nmake the post-processing a function that can be reusable by the\nWindows-version of git_terminal_prompt. We could even use it on the\nplain getpass-fallback, to unify the user-experience across platforms.\n\nWe can probably also be do 1) in a reusable form by adding some kind\nof on_char-callback, but it's probably something that'd end up more\nconfusing than than the alternative.\n\nThoughts?\n"},{"id":"194437","messageId":"20120629173954.GA3804@sigill.intra.peff.net","threadId":"30928","inReplyTo":"CABPQNSa4uvgijjGCSJDXDMqHC3UkqQKKujG3xDFqnQ13LNrKdQ@mail.gmail.com","subject":"Re: git_getpass regression?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-06-29T17:39:55Z","receivedAt":"2012-06-29T17:39:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 29, 2012 at 12:06:31PM +0200, Erik Faye-Lund wrote:\n\n> Since 9b4b894 (\"Makefile: linux has /dev/tty\", 2011-12-10) we're\n> reading input from the terminal using strbuf_getline instead of\n> getpass. But at least on my linux-box, getpass treats the\n> backspace-key ('\\b') as an actual deletion. strbuf_getline obviously\n> shouldn't do this, as it's a utility function. But I think as a\n> user-interface feature, it would be much more pleasant to be allowed\n> to edit the entered text ;)\n> \n> I can't find anything in POSIX that standardize this behavior, but for\n> most text-input use-cases it's probably what the user intended.\n\nBackspace shouldn't be making it to git at all; it should be handled at\nthe terminal input layer, because we are not putting the terminal into\nraw mode. It works just fine for me here, both on the linux console and\nin an xterm. What terminal are you using? Are you ssh-ing to a remote\nlinux box? If that is the case, I wonder if your 'stty erase' settings\ndo not match what your terminal emulator is sending.\n\nIf you run \"stty erase ^H\" and then run git, does it work?\n\n> I think we have multiple possible solutions:\n>  1) Read a character at the time, and special-case '\\r' to erase the\n> previously entered character.\n>  2) Post-process the strbuf to explicitly perform the erasing.\n>  3) Do nothing.\n\nI assume you meant '\\b' in (1).  I think (3) is the only sane thing,\nthough. Even if we handled \\b, that is not what all terminals generate.\nIn particular, most linux terminal emulators these days will generate\nDEL (aka ^? or 0x7f) on backspace. This problem needs to be solved at\nthe terminal layer, and I suspect is just a configuration issue in your\nsetup.\n\n-Peff\n"},{"id":"194449","messageId":"20120629203001.GA12937@sigill.intra.peff.net","threadId":"30928","inReplyTo":"CABPQNSZ4NhEA1CBiCBD_YNJZcnK8u=NtQ3PeDa5c0NDROPDyrQ@mail.gmail.com","subject":"Re: git_getpass regression?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-06-29T20:30:01Z","receivedAt":"2012-06-29T20:30:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 29, 2012 at 10:14:35PM +0200, Erik Faye-Lund wrote:\n\n> > Backspace shouldn't be making it to git at all; it should be handled at\n> > the terminal input layer, because we are not putting the terminal into\n> > raw mode.\n> \n> I don't get it. How can the terminal ever interpret the backspace, when\n> we've already put the character it's supposed to erase in a strbuf? Sure,\n> the echo can be correctly dealt with (probably with the exception of the\n> border case of erasing characters from the prompt text), but once we've put\n> the characters into a buffer, the terminal cannot erase it.\n\nBecause a terminal in non-raw mode is typically line-oriented, and your\nprogram doesn't get to see any input at all until the user hits enter.\n\nTry this on your linux box:\n\n  strace -e read cat\n\nYou should be able to type characters and backspace erase them, all\nwithout seeing any activity from strace. When you hit enter, you should\nsee the full text you typed read as a single syscall.\n\nIf the backspacing doesn't work, then there is a configuration mismatch\nbetween what linux's tty driver expects and what your terminal emulator\nis sending (the former is probably expecting ^? as the erase character,\nand the latter is sending ^H).\n\n> > If that is the case, I wonder if your 'stty erase' settings\n> > do not match what your terminal emulator is sending.\n> \n> I have no idea what that even means. And having to fiddle around with\n> terminal settings just makes git feel cheap.\n\nBut it's not git that is broken. It's your configuration. Fixing git is\na band-aid, and other programs will still be broken. Of course, I may be\nmis-diagnosing your problem. Did you try this:\n\n> > If you run \"stty erase ^H\" and then run git, does it work?\n\n?\n\n> >  I think (3) is the only sane thing,\n> > though. Even if we handled \\b, that is not what all terminals generate.\n> > In particular, most linux terminal emulators these days will generate\n> > DEL (aka ^? or 0x7f) on backspace. This problem needs to be solved at\n> > the terminal layer, and I suspect is just a configuration issue in your\n> > setup.\n>\n> As I already said, I don't think this is the case. Inserting 0x7f in a\n> strbuf does not delete the preceding char...\n\nOf course not. Control characters should be handled by the terminal\ndriver, and shouldn't make it to git at all. Backspacing works perfectly\nwell on correctly configured systems, and it should not be git's\nresponsibility to care about it at all for line-oriented input (and if\nwe _did_ want to handle it ourselves, we should use a real terminal\nlibrary like readline or curses).\n\n-Peff\n"},{"id":"194451","messageId":"CABPQNSY3hJse6J7fDo0S5=ySZA4_7=JisfzLBUu135gR2nSF-w@mail.gmail.com","threadId":"30928","inReplyTo":"20120629203001.GA12937@sigill.intra.peff.net","subject":"Re: git_getpass regression?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-06-30T11:27:09Z","receivedAt":"2012-06-30T11:27:09Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Jun 29, 2012 at 10:30 PM, Jeff King <peff@peff.net> wrote:\n> On Fri, Jun 29, 2012 at 10:14:35PM +0200, Erik Faye-Lund wrote:\n>\n>> > Backspace shouldn't be making it to git at all; it should be handled at\n>> > the terminal input layer, because we are not putting the terminal into\n>> > raw mode.\n>>\n>> I don't get it. How can the terminal ever interpret the backspace, when\n>> we've already put the character it's supposed to erase in a strbuf? Sure,\n>> the echo can be correctly dealt with (probably with the exception of the\n>> border case of erasing characters from the prompt text), but once we've put\n>> the characters into a buffer, the terminal cannot erase it.\n>\n> Because a terminal in non-raw mode is typically line-oriented, and your\n> program doesn't get to see any input at all until the user hits enter.\n>\n> Try this on your linux box:\n>\n>  strace -e read cat\n>\n> You should be able to type characters and backspace erase them, all\n> without seeing any activity from strace. When you hit enter, you should\n> see the full text you typed read as a single syscall.\n>\n\nThanks for the explanation.\n\n> If the backspacing doesn't work, then there is a configuration mismatch\n> between what linux's tty driver expects and what your terminal emulator\n> is sending (the former is probably expecting ^? as the erase character,\n> and the latter is sending ^H).\n>\n\nThe only thing I actually tested, was that getpass behaved correctly.\nI just assumed fgetc returned the input right away. I had no idea that\nfgetc didn't fetch characters until a whole line was entered. I guess\nyou learn something every day ;)\n\nI have now written a small test-application that confirms that the\nprompt works just fine; I was making conclusions without testing\nproperly, my bad. So I'm sorry for the noise. But please read on ;)\n\n>> > If that is the case, I wonder if your 'stty erase' settings\n>> > do not match what your terminal emulator is sending.\n>>\n>> I have no idea what that even means. And having to fiddle around with\n>> terminal settings just makes git feel cheap.\n>\n> But it's not git that is broken. It's your configuration. Fixing git is\n> a band-aid, and other programs will still be broken. Of course, I may be\n> mis-diagnosing your problem. Did you try this:\n>\n>> > If you run \"stty erase ^H\" and then run git, does it work?\n>\n> ?\n>\n\nI'm sorry, I didn't have access to a box at that time, that's why I\ndidn't answer that part.\n\nBut now, I see that \"stty erase ^H\" makes the terminal behave all\nstrange when it comes to the backspace character; it starts printing\n\"^?\" instead.\n\n>> >  I think (3) is the only sane thing,\n>> > though.\n\nYes, you are right. But perhaps with one exception: we probably want\nto piggy-back on those terminal-handling goodies on Windows. If only\nto get git to behave more consistently with other applications.\n\nSo perhaps we should do something like this?\n\n---8<---\ndiff --git a/compat/terminal.c b/compat/terminal.c\nindex 53c5166..2f44fb5 100644\n--- a/compat/terminal.c\n+++ b/compat/terminal.c\n@@ -76,18 +76,58 @@ char *git_terminal_prompt(const char *prompt, int echo)\n char *git_terminal_prompt(const char *prompt, int echo)\n {\n \tstatic struct strbuf buf = STRBUF_INIT;\n+\tint r;\n+\tFILE *input_fh, *output_fh;\n+\tDWORD cmode = 0;\n+\tHANDLE hconin;\n+\n+\tinput_fh = fopen(\"CONIN$\", \"r\");\n+\tif (!input_fh)\n+\t\treturn NULL;\n+\n+\toutput_fh = fopen(\"CONOUT$\", \"w\");\n+\tif (!output_fh) {\n+\t\tfclose(input_fh);\n+\t\treturn NULL;\n+\t}\n\n-\tfputs(prompt, stderr);\n-\tstrbuf_reset(&buf);\n-\tfor (;;) {\n-\t\tint c = _getch();\n-\t\tif (c == '\\n' || c == '\\r')\n-\t\t\tbreak;\n-\t\tif (echo)\n-\t\t\tputc(c, stderr);\n-\t\tstrbuf_addch(&buf, c);\n+\tif (!echo) {\n+\t\thconin = CreateFile(\"CONIN$\", GENERIC_READ | GENERIC_WRITE,\n+\t\t    FILE_SHARE_READ, NULL, OPEN_EXISTING,\n+\t\t    FILE_ATTRIBUTE_NORMAL, NULL);\n+\t\tif (hconin == INVALID_HANDLE_VALUE) {\n+\t\t\tfclose(input_fh);\n+\t\t\tfclose(output_fh);\n+\t\t\treturn NULL;\n+\t\t}\n+\t\tGetConsoleMode(hconin, &cmode);\n+\t\tif (!SetConsoleMode(hconin, cmode & (~ENABLE_ECHO_INPUT))) {\n+\t\t\tfclose(input_fh);\n+\t\t\tfclose(output_fh);\n+\t\t\treturn NULL;\n+\t\t}\n \t}\n-\tputc('\\n', stderr);\n+\n+\tfputs(prompt, output_fh);\n+\tfflush(output_fh);\n+\n+\tr = strbuf_getline(&buf, input_fh, '\\n');\n+\tif (!echo) {\n+\t\tputc('\\n', output_fh);\n+\t\tfflush(output_fh);\n+\n+\t\tSetConsoleMode(hconin, cmode);\n+\t\tCloseHandle(hconin);\n+\t}\n+\n+\tif (buf.buf[buf.len - 1] == '\\r')\n+\t\tstrbuf_setlen(&buf, buf.len - 1);\n+\n+\tfclose(input_fh);\n+\tfclose(output_fh);\n+\n+\tif (r == EOF)\n+\t\treturn NULL;\n \treturn buf.buf;\n }\n\n---8<---\n\nNotice how this looks very similar to the HAVE_TTY code-path, with the\nexception of needing two file handles instead of one, and the actual\nenabling/resetting of the prompt-setting. So the code-paths can\nprobably be refactored to share code...\n\n>> As I already said, I don't think this is the case. Inserting 0x7f in a\n>> strbuf does not delete the preceding char...\n>\n> Of course not. Control characters should be handled by the terminal\n> driver, and shouldn't make it to git at all. Backspacing works perfectly\n> well on correctly configured systems, and it should not be git's\n> responsibility to care about it at all for line-oriented input (and if\n> we _did_ want to handle it ourselves, we should use a real terminal\n> library like readline or curses).\n\nYes, I absolutely agree. Sorry for getting confused and wasting your\ntime with unfounded accusations.\n\nBut perhaps something good came from it; the Windows-prompt doesn't\nsupport erasing until the patch above is applied. I don't know if you\ncare or not, but I certainly do ;)\n"},{"id":"194452","messageId":"20120630183607.GA19739@sigill.intra.peff.net","threadId":"30928","inReplyTo":"CABPQNSY3hJse6J7fDo0S5=ySZA4_7=JisfzLBUu135gR2nSF-w@mail.gmail.com","subject":"Re: git_getpass regression?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-06-30T18:36:07Z","receivedAt":"2012-06-30T18:36:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 30, 2012 at 01:27:09PM +0200, Erik Faye-Lund wrote:\n\n> > If the backspacing doesn't work, then there is a configuration mismatch\n> > between what linux's tty driver expects and what your terminal emulator\n> > is sending (the former is probably expecting ^? as the erase character,\n> > and the latter is sending ^H).\n> \n> The only thing I actually tested, was that getpass behaved correctly.\n> I just assumed fgetc returned the input right away. I had no idea that\n> fgetc didn't fetch characters until a whole line was entered. I guess\n> you learn something every day ;)\n\nI think this is one of those places where unix people like me take it\nfor granted that the world works one way, but it is completely foreign\nfor people coming from other systems. :)\n\n> >> > If you run \"stty erase ^H\" and then run git, does it work?\n> [...]\n> But now, I see that \"stty erase ^H\" makes the terminal behave all\n> strange when it comes to the backspace character; it starts printing\n> \"^?\" instead.\n\nOK. Then that implies your terminal is sending ^?, which is reasonable.\nSo I take it that everything is now working on your Linux box? Did you\nfigure out what caused the problems before?\n\n> >> >  I think (3) is the only sane thing,\n> >> > though.\n> \n> Yes, you are right. But perhaps with one exception: we probably want\n> to piggy-back on those terminal-handling goodies on Windows. If only\n> to get git to behave more consistently with other applications.\n\nYeah, that makes sense. The idea of abstracting git_terminal_prompt was\nto do whatever would make the most sense for user input on the given\nplatform; I just had no idea how to do that on Windows.\n\n> So perhaps we should do something like this?\n\nThat looks like a good direction overall. I'm not really qualified to\ncomment on the Windows-specific bits, of course, but:\n\n> +\tif (!echo) {\n> +\t\thconin = CreateFile(\"CONIN$\", GENERIC_READ | GENERIC_WRITE,\n> +\t\t    FILE_SHARE_READ, NULL, OPEN_EXISTING,\n> +\t\t    FILE_ATTRIBUTE_NORMAL, NULL);\n> +\t\tif (hconin == INVALID_HANDLE_VALUE) {\n> +\t\t\tfclose(input_fh);\n> +\t\t\tfclose(output_fh);\n> +\t\t\treturn NULL;\n> +\t\t}\n> +\t\tGetConsoleMode(hconin, &cmode);\n> +\t\tif (!SetConsoleMode(hconin, cmode & (~ENABLE_ECHO_INPUT))) {\n> +\t\t\tfclose(input_fh);\n> +\t\t\tfclose(output_fh);\n> +\t\t\treturn NULL;\n> +\t\t}\n\nThe HAVE_DEV_TTY version takes care to reset this on signal death or\npremature exit (so if you ^C out of the program, your terminal is not\nleft in a funny state). You might want to do something similar here.\n\n> +\tr = strbuf_getline(&buf, input_fh, '\\n');\n> +\tif (!echo) {\n> +\t\tputc('\\n', output_fh);\n> +\t\tfflush(output_fh);\n> +\n> +\t\tSetConsoleMode(hconin, cmode);\n> +\t\tCloseHandle(hconin);\n> +\t}\n> +\n> +\tif (buf.buf[buf.len - 1] == '\\r')\n> +\t\tstrbuf_setlen(&buf, buf.len - 1);\n\nThis will read random memory if buf.len == 0 (no clue if that can ever\nhappen on Windows, but it's nice to be defensive).\n\n> Notice how this looks very similar to the HAVE_TTY code-path, with the\n> exception of needing two file handles instead of one, and the actual\n> enabling/resetting of the prompt-setting. So the code-paths can\n> probably be refactored to share code...\n\nI'd be OK with leaving them separate, too. The shared parts are small\nenough (and are mostly in strbuf_getline) that I think it might end up\nless readable. But I'd withhold my judgement until seeing how good or\nbad the refactored version looked. :)\n\n> Yes, I absolutely agree. Sorry for getting confused and wasting your\n> time with unfounded accusations.\n> \n> But perhaps something good came from it; the Windows-prompt doesn't\n> support erasing until the patch above is applied. I don't know if you\n> care or not, but I certainly do ;)\n\nNo problem at all. Progress usually starts with somebody wondering\nwhether and how something is broken.\n\n-Peff\n"},{"id":"194529","messageId":"CABPQNSZGcReC4CgaYcmwsXyGSqzQgHKQceZ2M5D=zQmyAs8_Ug@mail.gmail.com","threadId":"30928","inReplyTo":"CABPQNSYP6mUZb-1dCifytRxqP7_grzYzON2bjevK2zsGawb-yg@mail.gmail.com","subject":"Re: git_getpass regression?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-07-03T16:28:11Z","receivedAt":"2012-07-03T16:28:11Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Sat, Jun 30, 2012 at 10:15 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:\n> On Sat, Jun 30, 2012 at 8:36 PM, Jeff King <peff@peff.net> wrote:\n>> On Sat, Jun 30, 2012 at 01:27:09PM +0200, Erik Faye-Lund wrote:\n>>> +     if (!echo) {\n>>> +             hconin = CreateFile(\"CONIN$\", GENERIC_READ | GENERIC_WRITE,\n>>> +                 FILE_SHARE_READ, NULL, OPEN_EXISTING,\n>>> +                 FILE_ATTRIBUTE_NORMAL, NULL);\n>>> +             if (hconin == INVALID_HANDLE_VALUE) {\n>>> +                     fclose(input_fh);\n>>> +                     fclose(output_fh);\n>>> +                     return NULL;\n>>> +             }\n>>> +             GetConsoleMode(hconin, &cmode);\n>>> +             if (!SetConsoleMode(hconin, cmode & (~ENABLE_ECHO_INPUT)))\n>>> {\n>>> +                     fclose(input_fh);\n>>> +                     fclose(output_fh);\n>>> +                     return NULL;\n>>> +             }\n>>\n>> The HAVE_DEV_TTY version takes care to reset this on signal death or\n>> premature exit (so if you ^C out of the program, your terminal is not\n>> left in a funny state). You might want to do something similar here.\n>>\n>\n> Good point. I'll look into adding a Ctrl+C handler routine that cleans up.\n>\n\nActually, it seems the shells (at least CMD.exe and MSYS bash) sets\nthe console mode to something sane when the process exits, so in\nreality this doesn't seem to matter much. But I'd like to play nice\nwith the system if I can.\n\nAdding a Control-handler that simply restores the console-mode only\nmade it behave slightly worse for me. A control-handler in Windows\nruns from a separate thread *without halting the other threads*.\nCombine that with the fact that the IO-call returns EOF when Ctrl+C is\nentered, the result is that the calling thread and the Control-handler\nthread race to restore the console-mode. The result is a correctly\nrestored terminal, but with a sporadous \"could not read\"-error based\non who wins the race.\n\nBut there are more gotchas: Ctrl+C is sent to all processes that share\nthe console on Windows. And it seems that Bash actually terminate it's\nchild-process when it receive Ctrl+C! This can happen *before* we even\nget the Ctrl+C handler in our process, preventing us from restoring\nthe console mode. Luckily this doesn't seem to cause any harm, because\nBash seems to set a sane console mode itself.\n\nIs there some other way of getting EOF from the console than Ctrl+C?\nIf not, perhaps we can disable the Ctrl+C handling altogether for the\ncurrent process, and restore the console mode on EOF? That only leaves\nthe \"Bash kills our process\"-case, but Bash seems to set a sane\nconsole mode anyway.\n"},{"id":"194531","messageId":"20120703171121.GA3294@sigill.intra.peff.net","threadId":"30928","inReplyTo":"CABPQNSZGcReC4CgaYcmwsXyGSqzQgHKQceZ2M5D=zQmyAs8_Ug@mail.gmail.com","subject":"Re: git_getpass regression?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-07-03T17:11:22Z","receivedAt":"2012-07-03T17:11:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 03, 2012 at 06:28:11PM +0200, Erik Faye-Lund wrote:\n\n> Is there some other way of getting EOF from the console than Ctrl+C?\n> If not, perhaps we can disable the Ctrl+C handling altogether for the\n> current process, and restore the console mode on EOF? That only leaves\n> the \"Bash kills our process\"-case, but Bash seems to set a sane\n> console mode anyway.\n\nOn unix systems, you can generally send EOF on a terminal using Ctrl+D\n(and strbuf_getline should handle it properly).  I have no clue if that\nworks on a Windows console, though. Also, I wonder if these kind of\nterminal issues are different based on the terminal emulator you are\nusing (e.g., msys bash window versus something like pterm).\n\n-Peff\n"},{"id":"194535","messageId":"CABPQNSZjZtRxf1=cdKqgp3FwP6Fw2W876si9=OpyHmZ6mjHRsw@mail.gmail.com","threadId":"30928","inReplyTo":"20120703171121.GA3294@sigill.intra.peff.net","subject":"Re: git_getpass regression?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-07-03T17:37:23Z","receivedAt":"2012-07-03T17:37:23Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Jul 3, 2012 at 7:11 PM, Jeff King <peff@peff.net> wrote:\n> On Tue, Jul 03, 2012 at 06:28:11PM +0200, Erik Faye-Lund wrote:\n>\n>> Is there some other way of getting EOF from the console than Ctrl+C?\n>> If not, perhaps we can disable the Ctrl+C handling altogether for the\n>> current process, and restore the console mode on EOF? That only leaves\n>> the \"Bash kills our process\"-case, but Bash seems to set a sane\n>> console mode anyway.\n>\n> On unix systems, you can generally send EOF on a terminal using Ctrl+D\n> (and strbuf_getline should handle it properly).  I have no clue if that\n> works on a Windows console, though.\n\nNope. On Windows, Ctrl+D seens to give EOT (0x4).\n\n> Also, I wonder if these kind of\n> terminal issues are different based on the terminal emulator you are\n> using (e.g., msys bash window versus something like pterm).\n\nNo, they should not. Windows doesn't have a concept of different\nterminal emulators. There's only ever one, which is built into\nwindows.\n"},{"id":"195245","messageId":"7vtxx5wr6v.fsf@alter.siamese.dyndns.org","threadId":"30928","inReplyTo":"CABPQNSZjZtRxf1=cdKqgp3FwP6Fw2W876si9=OpyHmZ6mjHRsw@mail.gmail.com","subject":"Re: git_getpass regression?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-18T05:53:28Z","receivedAt":"2012-07-18T05:53:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ping on seemingly stalled discussion.\n"},{"id":"195289","messageId":"CABPQNSa1wd8TzQ5-H7HQaVD586POWotMhOWLvC5Y90nBAn4fUQ@mail.gmail.com","threadId":"30928","inReplyTo":"7vtxx5wr6v.fsf@alter.siamese.dyndns.org","subject":"Re: git_getpass regression?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-07-18T14:23:55Z","receivedAt":"2012-07-18T14:23:55Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Jul 18, 2012 at 7:53 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ping on seemingly stalled discussion.\n\nJust to recap quickly from my point of view:\n1. There's no regression.\n2. There's room for improvement of the prompting on Windows.\n3. I'm not entirely confident that I've found a safe way of improving\nthe Windows prompt yet.\n4. I've been busy with other stuff, but I'll get back to hacking soon :)\n"}]}