Support GNU environment variable TERM in Windows

[WSLUser]

Description of the new feature/enhancement

From https://www.gnu.org/software/gettext/manual/html_node/The-TERM-variable.html:

The environment variable TERM contains a identifier for the text window’s capabilities. You can get a detailed list of these capabilities by using the infocmp command, using man 5 terminfo as a reference.

Defining this environment variable on Windows will allow all terminal emulators on Windows to set this based on their capabilities as reported by terminfo. It will need to be established in a way that would allow multiple terminal emulators to set their own value within the variable (similar to how the PATH variable works). By default, conhost will report its terminfo features. When Windows Terminal eventually is shipped by default on Windows, it's terminfo will also be reported by default as well. Furthermore the command specified by GNU infocmp should be available to all terminals include the default conhost and Windows Terminal to list the terminal capabilities.

The biggest gain from this will be from the use of scripts/utilities/applications that require knowledge of the terminal capabilities that already use this environment variable on other systems (Linux, MacOS, etc.).

Proposed technical implementation details (optional)

We now have a Powershell script that determines the VT support #1884. Perhaps it could be adapted to also report the terminfo capabilities set by the TERM env variable in Windows for conhost and Windows Terminal.

Also very related but not quite the same based on what I saw from the discussion: #1040.

[zadjii-msft]

I'd rather not.

Our goal with conhost has always been "be as close to xterm-256coloras possible". When we started working on WSL 5 years ago, we had basically no VT support. However, by setting the TERM for wsl to xterm (then later to xterm-256color), this made it possible for us to identify the shortcomings of conhost as far as VT support was concerned. Had we defined our own TERM, and populated our own infocmp, then conhost would have just eeked along with whatever support we had given it, and client apps that used tput and the termcap database would have worked alright given what we supported at the time.

That wasn't the goal though - the goal was to make conhost a capable terminal emulator, and that's still our goal. If there are things in xterm-256color that we don't support, or support in a buggy fashion, I'd rather the bugs land here, so we can fix them and maintain parity, rather than codify what we do and don't support. With how fast we iterate on the Terminal and conhost, it would be disingenuous to codify what level of VT support we have into a infocmp database. We'd almost need one for each and every version of Windows 10 that's included VT support, and then one for each version of the Terminal - it's just not a sustainable feature.

Plus, I'm very reluctant to add TERM based terminal detection to the Terminal. That discussion is already being had in #1040 though, so I won't fork it into this thread as well.

PLUS, there's just no infocmp infrastructure on Windows at all, and there aren't remotely any plans to add it. Nor are there plans to port Windows Terminal to platforms where there is such infra. Sure, the Terminal can be used to connect to ssh sessions, or WSL apps, where there is such support, but again, I'd rather have parity with xterm256-color. I believe WSL still sets TERM to xterm-256color, and I'd imagine that Win32-OpenSSH does as well.

[WSLUser]

Yes WSL does set it to xterm-256color. I agree we should ensure parity with xterm256-color. I would agree we'd need to do it by Windows release but I'm not so sure we need to do it by Windows Terminal release. We release a new stable every other release and I haven't seen any documentation stating we'd support every release ever produced. We should only support stable for now until we get to a point where Windows Terminal can support doing LTS (and imo we're not quite there yet despite how great Windows Terminal is already.)

[DHowett]

This is very similar to the discussion in #8303. The curses project shipped a ms-terminal TERM entry that causes us some trouble. It causes us trouble for the exact reasons Mike mentioned above 😄

[WSLUser]

Yes that issue was what inspired me to create this one. I was thinking about how users could manually tell programs what's supported and I didn't see much from the Windows side, just Linux. So maybe I can update it in WSL but then I'd need WSL for remote connections instead simply having a quick powershell ssh profile.

[DHowett]

I'm gonna close this one out as a simultaneous /duplicate of #1040 and #8303. Thanks for bringing it up!

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!