git_terminal_prompt fixes and Unicode support

[kblees]

Followup to #74 mintty issues / @dscho's d56d2f8

• Fixes a few minor issues with git_terminal_prompt (see individual fixup commits)
• Use read -s instead of stty echo (for fewer processes and MSys1 compatibility)
• Drop CONIN$ / CONOUT$ in favor of the shell based solution (for Unicode support) see discussion
• Drop unnecessary SetConsoleCP() from git-wrapper see PR git-wrapper: don't set the console input code page #142

Tested with git-bash, git-cmd, bash in native console, and MSys1 bash (with compat/terminal.c backported to msysgit/git/master).

[dscho]

I am sympathetic to your aim to support Unicode better, but please let me restate my ultimate goal for Git for Windows: I want it to be independent from any Shell or Perl. Ideally, Git for Windows is a pure, monolithic executable (or at least a bunch of executables and libraries bundled in a small installer). Therefore it pains me to see that we will probably have to increase our dependency on Bash rather than decrease it as I really wish we could.

Having said that, after the concerns I raised, I will accept those changes (preferably as two, separate Pull Requests) because you make a strong point why it is better to rely on the shell rather than the Win32 API to access the console.

Thank you so much for your valuable work, I hope I manage to help make the changes better by my feedback.

[kblees]

For background, I wanted to run tests with the dash instead of bash ... Now, we might be able to patch in support for the -s option

I'd rather not start patching up yet another utility...

I kinda don't want to break compatibility with MSys1

stty (and tty) is available in the MSys1 coreutils package, we just don't have it in msysgit/msysgit yet. So we could do stty -echo && read -r && stty echo. I'll change that patch to just reduce the number of sh invocations.

We still test for this "xterm" part of TERM.

IMO TERM=xterm* is not a good way to check whether we run in an MSys pty or a native console window, especially as /etc/profile unconditionally sets TERM=xterm-256color.

I've played around with checking the terminal from native code (similar to checking pipe names in PR #102), but MSys2 manages the controlling terminal of a program group in a shared memory section. So this is basically a dead end, as the binary format may change with each release (see winsup/cygwin/shared_info.h / shared.cc).

Possible alternatives would be:

• Check if sh -c tty returns /dev/cons* or /dev/pty*.
• Use a small msys-compiled C-program that does all the work for us (basically the HAVE_DEV_TTY branch of compat/terminal.c, i.e. using the termios API to control the terminal).

I really want to limit our dependence on a shell.

With the long-term goal to provide a minimal Git distribution, we should also try to limit dependency on MSys(2) and MinTTY, right?

Why?

I moved the code in a separate commit to improve legibility of the subsequent patch.

Sorry, we cannot do that. As you can see here, Git for Windows is not the only user of compat/terminal.c.

The HAVE_DEV_TTY branch should work as before, I just eliminated the GIT_WINDOWS_NATIVE specific stuff.

But I agree that its better to keep the CONIN$/CONOUT$ variant, to support potential future minimal Git distros.

[dscho]

For background, I wanted to run tests with the dash instead of bash ... Now, we might be able to patch in support for the -s option

I'd rather not start patching up yet another utility...

I was not asking you to do that ;-) It's just that it really affects performance that we have to use shell so much in the test suite. The difference is truly stunning between running the test suite on Linux and on Windows.

I kinda don't want to break compatibility with MSys1

stty (and tty) is available in the MSys1 coreutils package, we just don't have it in msysgit/msysgit yet. So we could do stty -echo && read -r && stty echo. I'll change that patch to just reduce the number of sh invocations.

Oh, I meant to express clearly that you do not need to change that patch. We will not switch away from Bash anytime soon and you are correct that it is better to reduce the number of shell commands.

I really want to limit our dependence on a shell.

With the long-term goal to provide a minimal Git distribution, we should also try to limit dependency on MSys(2) and MinTTY, right?

There are two layers to Git for Windows: The git.exe executable and all it calls, and the option to run scripts on top of it. I would like the former ("core Git") to be as self-contained as possible, i.e. eventually not even requiring a sh.exe. The latter, however, is what I need for my own workflows: I use a metric ton of shell scripts on top of Git, some even more complicated than the shears.sh script; To support those, I need an interactive shell, and if I already have a shell, I also want a powerful xterm-like console window as MinTTY offers it. So even if nobody else would want to use MinTTY, I would still support it for myself.

That does not mean that I want to force every Git user to use a Bash and MinTTY. I want them to have the liberty to choose to use it, or to choose not to.

Sorry, we cannot do that. As you can see here, Git for Windows is not the only user of compat/terminal.c.

The HAVE_DEV_TTY branch should work as before, I just eliminated the GIT_WINDOWS_NATIVE specific stuff.

But I agree that its better to keep the CONIN$/CONOUT$ variant, to support potential future minimal Git distros.

Thank you.

[kblees]

I hope I addressed all your concerns.

• I changed sh to bash to ensure that read -s is supported.
• Instead of checking TERM=xterm, we fall back to CONIN/OUT if bash is not on the PATH. So this should already work with a potential bash-less Git distro.

[dscho]

This is excellent; Very good idea to fall back to Win32 API only if bash was not found!