Colour support and winpty redirection broken

[perlun]

This is a followup to #284 (comment).

Background

The installation experience on Windows has historically been a bit lacking; see #107 for more details. I fixed this in #278, or so I thought.

After adding ANSI colors in #284, I tested the new version on Windows - only to realize that ANSI colors did not work as expected:

I also found out that in Git Bash (i.e. mingw-based bash on Windows), the fix I did in #278 does not work. Do note how the ANSI colors work in this case, though:

This issue exists to dig further into this and try to understand why this happens, and find a mitigation.

[perlun]

Interestingly enough, when building a Debug build in Rider (on Windows), I get this:

In other words:

1. Debug builds, running on "Any CPU" seems to properly detect input being redirected. I've tested a Release build (built from Rider) and it behaves exactly the same.
2. When executed via winpty, ANSI colours do not seem to work. (Could there be a workaround to this? 🤔)

Either way, we need to figure out why these release-oriented builds work differently than the locally built Debug/Release builds.

[perlun]

2. When executed via winpty, ANSI colours do not seem to work. (Could there be a workaround to this? 🤔)

This could be a variation of rprichard/winpty#140 we're seeing. I'll ask a question there to see if anyone has any ideas.

[perlun]

Hmm, interesting. I was using a slightly older version Git for Windows, where the provided MSYS2 version was too old (3.0.7-338.x86_64) to support the more modern ConPTY mode introduced in Windows 10. @mintty helped me debug this in rprichard/winpty#140 (comment) (thanks 🙏).

After upgrading to a more recent version of Git for Windows, it worked flawlessly with the existing Perlang version. No changes were required (but we can probably drop the WinPTY re-execution call now since there's little need for it anymore):

Important things to notice

ConPTY support is not enabled in the "Bash Git" included in Git for Windows by default. It must be enabled either by setting the MSYS env variable to enable_pcon before launching Git Bash, or by checking this setting during installation:

[perlun]

For some odd reason, colours still doesn't work entirely correct when Git Bash is executed in the new, cool Windows Terminal. I think I'll leave this as a "known glitch" for now. 🤷‍♂️

[perlun]

For some odd reason, colours still doesn't work entirely correct when Git Bash is executed in the new, cool Windows Terminal.

Could be some variation of git-for-windows/git#2483, will ask in that repo to see if anyone has any ideas. 🤔

[perlun]

No response yet [correction: I got some suggestions but none that helped]. I'll leave this as a "known defect" in 0.1.0 for now, bumping this to 0.2.0. It would be nice to at least have a workaround for bash on Windows (MSYS2 or MINGW64) for this.

[perlun]

Still an open issue, to the best of my knowledge. Bumping to 0.3.0.

[perlun]

Still an open issue. I don't think this should block 0.3.0 though, so bumping once again.

[perlun]

For some odd reason, colours still doesn't work entirely correct when Git Bash is executed in the new, cool Windows Terminal. I think I'll leave this as a "known glitch" for now. 🤷‍♂️

Interestingly enough, with the changes coming in #389, this is no longer the case - colours do work in the Windows Terminal:

...however, digging deeper, I tested with another build (893c5be), and it works equally well. 🤔

I tested with 0.3.0 (i.e. e8c28e2) and it also worked equally well. 🤷 I guess we can consider this fixed then. Since it's unclear whether this is really:

• a fix on our side, or
• a fix in Windows Terminal/conpty, or
• a configuration change in the way I'm running Git Bash now vs previously

...I think we'll leave this out of the release notes for now. Regardless, closing issue.