Bug Report: ANSI Color Sequences not having effect when running through cygwin bash

[chorman0773]

Environment

Windows build number: 18985 (Most Recent Windows Insider, Fast Track, Update)
Windows Terminal version (if applicable): Unknown, Installed from Windows Store on 08-31-2019

Any other software? 
Running cygwin bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)
Linking `cygwin1.dll`, `uname -a` in bash results in "CYGWIN_NT-10.0 <hostname hidden for privacy reason> 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin"

Steps to reproduce

Using cygwin bash,
Execute the following shell command: printf "\033[38;2;255;0;0mHi\033[0m".
Similar behavior is achieved from the C function printf in a standalone application, when compiled using a cygwin compiler, and linking the C function printf with the one defined by cygwin1.dll.

Other shells running in cygwin have not been tested, and lack of known functionality in cmd.exe and Powershell have made testing the shell command directly difficult. Tests of the C function, when compiled using Microsoft Visual Studio, have proved positive on all tested shells.

Expected behavior

Execution of the shell command on both native linux bash and cygwin bash when run through mintty.exe (cygwin tty host executable) prints Hi in bright red, the expected behavior.

Actual behavior

The "Hi" is printed correctly and the escape sequences are not printed in any form, however the color is not applied.

Additional Notes

I do not believe this is a bash issue, as it works correctly in both mintty provided by cygwin and in the bash shell run in a native linux environment. The likely cause is some disparity in the handling of ANSI Escape Sequences between cygwin glibc (provided by cygwin1.dll) and Windows Terminal. I will make further attempts to confirm this issue in cmd.exe and powershell using binaries linked against cygwin1.dll rather than Microsoft CRT.

[chorman0773]

I have confirmed that the issue is between Windows Terminal and cygwin1.dll, and not specifically with bash, as running a C program linked against cygwin1.dll in both cmd.exe and Powershell yields the same results as running that program in cygwin bash. I will file an additional issue with the cygwin developers

[DHowett-MSFT]

Is there a chance that Cygwin knows it’s connected to a “console” and has implemented its own SGR parser? We have seen this with other runtimes before.

[DHowett-MSFT]

Nope.

[j4james]

Is there a chance that Cygwin knows it’s connected to a “console” and has implemented its own SGR parser?

Yeah, that seems to be the case.
https://conemu.github.io/en/CygwinAnsi.html

[chorman0773]

That seems consistent with my testing, though I can't confirm for sure this is what is occuring without taking a look at the source for cygwin1. Is it correct to assume that, by default, profiles are allocated a ConhostConnection?

[DHowett-MSFT]

Yep, everything is running through conhost.

[chorman0773]

I'm looking at the code for cygwin now, but it seems that the easiest fix would be to allow the profile the ability to set the console front-end program (though I'm not sure how feasible this is), as the other fixes on the Terminal end of things would likely involve either implementing mintty within the Terminal, or making invasive calls to cygwin within the shell program's process space itself.

[DHowett-MSFT]

I think the best long-term fix is to teach Cygwin that on Windows 10 (they’ve had some time to come to terms with this 😄) they can delegate all VT rendering and almost all VT input synthesis to the windows console host. That’s what WSL does, and because of that we’re striving for pretty solid compatibility.

Right now, Terminal expects to have conhost in the way “translating” for it, because conhost has good VT support and Terminal’s isn’t quite hooked up. There’s a lot of reasons for that, the most salient of which is that it was faster to make WT a Conhost host than to do anything else. In the long term we need to fix that for connectors like Azure and SSH, but in the near term it suffices for well-behaved clients.

[DHowett-MSFT]

We’ve had this trouble before. Ever since we added 24-bit color support we’ve been running into applications that thought they were clever and that we would never add support for anything that was invented after 1980!

[DHowett-MSFT]

I'm going to close this as External and perhaps file a followup over on Cygwin.

[claudenobs]

as per msys2/MSYS2-packages#1684 (comment) this has been fixed with cygwin 3.1

[trajano]

@DHowett-MSFT seems that they fixed git for windows to have the newer packages and it fixed the ANSI sequences for Bash itself. But does not appear to do so for the processes called by bash. I'm just scanning through the bug reports to see if there was one I can attach the details I found git-for-windows/git#2483 (comment)