Git: Using Windows Terminal with a git-for-windows tab displays odd characters

Created on 18 Jan 2020  路  15Comments  路  Source: git-for-windows/git

  • [x] I was not able to find an open or closed issue matching what I'm seeing

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
git version 2.24.1.windows.2
cpu: x86_64
built from commit: 992f0773022527b1b0cb1e0c13aec97dd5248053
sizeof-long: 4
sizeof-size_t: 8 
  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
Microsoft Windows [Version 10.0.18363.592]
  • What options did you set as part of the installation? Or did you choose the
    defaults?
from C:\Program Files\Git\etc\install-options.txt
Editor Option: VIM
Custom Editor Path: 
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Interactive Add: Disabled
  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

    • I've installed arcanist to interact with phabricator and when using the "standard" bash window I have no display issues; however, when I use the Bash window as a tab in Windows Terminal I have an unexpected issue. Here is a link to arcanist in case it's helpful:

      https://secure.phabricator.com/book/phabricator/article/arcanist/

Details

  • Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

    • Windows Terminal
  • What commands did you run to trigger this issue? If you can provide a
    Minimal, Complete, and Verifiable example
    this will help us understand the issue.

    • The following commands result in showing the issue which are all Arcanist commands

      • arc diff

      • arc commit

      • arc feature

  • What did you expect to occur after running these commands?

    • The command would run without showing any unexpected characters
  • What actually happened instead?

    • The commands run; however, there are clearly unexpected characters.
  • If the problem was occurring with a specific repository, can you provide the
    URL to that repository to help us with testing?

Most helpful comment

Ok, this issue seems to consist of multiple layers.

  • you're probably calling the wrong bash
  • you're probably using the wrong php
  • the way arcanist determines wether they can use ansi colors is broken

Let me explain. You're probably using the recommended profile for Git Bash from the microsoft/terminal repo. That calls bin/bash.exe instead of git-bash.exe among other differences, this sets TERM to cygwin instead of xterm. That's the reason you can't reproduce this in standalone Git Bash.

You're probably also using a PHP for windows, not msys2 or cygwin. That means DIRECTORY_SEPARATOR is probably set to \ and posix_isatty() doesn't exist. It also doesn't handle ANSI color sequences.

arcanist disables ANSI color sequences if DIRECTORY_SEPARATOR is not / and TERM isn't cygwin or posix_isatty() exists and returns false for STANDARDOUT. There are some other cases, but these are the interesting ones for this issue.

That leads arcanist to assume it can use ANSI color sequences, but your php doesn't know what to do with them.

You could test TERM=xterm arc diff and if that works set TERM=xterm from ~/.bashrc if that works.

All 15 comments

The following commands result in showing the issue which are all Arcanist commands

* arc diff

* arc commit

* arc feature
  1. This is not a minimal example
  2. This example is about Arcanist, not about Git for Windows. If you can replicate with bare GIt for Windows, please do so and provide the details here.

@dscho
As I understand the problem based on the comments from the bug I opened (and was later closed) under the Microsoft Terminal the issue lies in...
msys/mingw/cygwin runtime

As such I was offering up the example of the commands I run in arcanist which are attempting to use aspects of color and text formating that result in odd characters.

As i listed in the other bug report with screen shots (and replicated here) I'm looking for help in addressing the way the odd characters appear in the msys/mingw/cygwin when it's used within Windows Terminal... perhaps this isn't an issue with git-for-windows then?

Image of mingw in windows terminal with odd characters:
mingw with odd characters

Image of PS Core in windows terminal running same commands without odd characters:
PS Core without odd characters

If this repo is _also_ not the right place to list this bug advise and I'll keep looking for the right place.

Thank you for your time.

I'll need a minimal reproducer to assess (and possibly fix) the issue. Not screenshots. I will not install arcanist and hunt for that reproducer myself.

Ok, this issue seems to consist of multiple layers.

  • you're probably calling the wrong bash
  • you're probably using the wrong php
  • the way arcanist determines wether they can use ansi colors is broken

Let me explain. You're probably using the recommended profile for Git Bash from the microsoft/terminal repo. That calls bin/bash.exe instead of git-bash.exe among other differences, this sets TERM to cygwin instead of xterm. That's the reason you can't reproduce this in standalone Git Bash.

You're probably also using a PHP for windows, not msys2 or cygwin. That means DIRECTORY_SEPARATOR is probably set to \ and posix_isatty() doesn't exist. It also doesn't handle ANSI color sequences.

arcanist disables ANSI color sequences if DIRECTORY_SEPARATOR is not / and TERM isn't cygwin or posix_isatty() exists and returns false for STANDARDOUT. There are some other cases, but these are the interesting ones for this issue.

That leads arcanist to assume it can use ANSI color sequences, but your php doesn't know what to do with them.

You could test TERM=xterm arc diff and if that works set TERM=xterm from ~/.bashrc if that works.

@briannipper have you tried @rimrul's suggestion? What was the outcome?

You're probably using the recommended profile for Git Bash from the microsoft/terminal repo.

(as the Terminal maintainer, I'd be happy to learn that a bunch of our problems could be resolved by recommending something different.)

@DHowett-MSFT I haven't checked: do you call bin\bash.exe -li or usr\bin\bash.exe -li? The former _should_ work correctly. The latter will miss important environment variable settings.

My apologizes for the unusually long delay in following up on this.

Thank you so much @rimrul you suggestion to use TERM=xterm FIXED all my formatting issues. Also, thank you for the additional explanation of the various layers involved, it's quite helpful to see the pieces as you outline them.

After creating the entry in ~/.bashrc all my arc problems have disappeared. :)

Our current recommendation is the former, but it looks like we're missing --login and friends. I'll fix that.

Thanks!

Yep, without --login, the environment won't be set up properly.

Perhaps it needs to be recompiled with a newer cygwin library as per https://github.com/microsoft/terminal/issues/4809#issuecomment-596249509

Perhaps it needs to be recompiled with a newer cygwin library as per microsoft/terminal#4809 (comment)

The latest snapshot includes an MSYS2 runtime based on Cygwin v3.1.5, so it is safely newer than the suggested v3.1.2. Even Git for Windows v2.27.0 comes with an MSYS2 runtime based on a newer Cygwin (namely, v3.1.4): https://github.com/git-for-windows/build-extra/blob/cd17006382667f8bccd23060fa8610591c716709/versions/package-versions-2.27.0.txt#L110

@dscho just verified with https://gist.github.com/ketan/2866a236596636311d64 and I see the full color palette now for git bash.
image
Though the processes called by git bash is still showing the escape sequences
image
so it may need more work from the Cygwin end. Is there an issue opened up on their end that discusses this?

Works well on "Git Bash" (no terminal)
image

It _might_ just be a question of setting TERM appropriately.

It _might_ just be a question of setting TERM appropriately.

I think it may be something that needs to happen in OpenJDK unless there's a per process handling.

Was this page helpful?
0 / 5 - 0 ratings