Improve IS_WINDOWS_SYSTEM check

[umarcor]

I submitted a PR to fix colour support on MSYS2/MINGW: #538.

The Python installation available on my Windows 10 machine was installed through pacman (MSYS' package manager). I'm using VUnit from MINGW32/MINGW64 shells, where ghdl is installed from a PKGBUILD file. Hence, everything works as expected in these environments.

Nonetheless, I found that the same Python installation can be used from either cmd or powershell, because C:\msys64\usr\bin is available in the PATH. Surprisingly, in these contexts os.name == 'posix'. Therefore, I'd say that VUnit won't work as expected. I am unsure, because I have not tried with any simulator yet.

For completeness, I think that the current check (IS_WINDOWS_SYSTEM = os.name == 'nt') is only valid for cmd/poweshell as long as 'regular' Python artifacts are used (https://www.python.org/downloads/release/python-374/). I checked that python-3.7.4-embed-amd64.zip returns os.name == 'nt' indeed.

As a result, I'd say that VUnit might need to be revisited/fixed to support 'mixed' environemtns:

• cmd/powershell with Python and ghdl installed through MSYS/MINGW. These environments should return IS_WINDOWS_SYSTEM = true and use Win32ColorPrinter. I think this is not the case.
• MSYS/MINGW with 'regular' Python artifacts. These environments should return IS_WINDOWS_SYSTEM = true and use LinuxColorPrinter. I think this is correct after merging fix: use LinuxColorPrinter if MSYSTEM envvar is set #538.

[ryanfitzsimon]

I have yet another use case to consider. From Git bash (a variant of MSYS/MINGW) I run the normal Windows python installation through winpty.

In this scenario, VUnit should act exactly as it would running with CMD, but since #539 MSYSTEM is detected and unprocessed Linux escape codes are displayed instead.

[umarcor]

@ryanfitzsimon, that's interesting... I'd say that Git bash is "the same" as MSYS/MINGW. Therefore, your case should be the same as MSYS/MINGW with 'regular' Python artifacts. On the one hand, I'd like to know which simulator are you testing this with. On the other hand, would you mind checking the following?

• The content of os.name (https://github.com/VUnit/vunit/blob/master/vunit/ostools.py#L36).
• Should you have MSYS2, apart from Git bash:
  • Is there any difference?
  • If so, can we tell them apart?

We should fill the following tables:

os.name	cmd	powershell	mingw	git bash
native	nt	nt	nt *1	nt *1
pacman	posix	posix	nt

os.environ['TERM']	cmd	powershell	mingw	git bash
native	unset	unset	unset *1	*1
pacman	cygwin	cygwin	xterm

ColorPrinter	cmd	powershell	mingw	git bash
native	Win32	Win32	*1	Win32 *1
pacman			Linux

*1 winpty required

[ryanfitzsimon]

@umarcor

I'd say that Git bash is "the same" as MSYS/MINGW. Therefore, your case should be the same as MSYS/MINGW with 'regular' Python artifacts.

I agree. In the context of this issue, I think Git bash and MSYS2 should be effectively identical.

Sorry if I didn't make this clear, but the important point of difference is the use of winpty.

I run the normal Windows python installation through winpty.

Running under Git bash means that the environment variable MSYSTEM is set to MINGW64 and
since it's a windows installation, python reports os.name is nt.

The issue is that when running under winpty, VUnit should behave as it would in CMD even though it's actually being run from Git bash (i.e. Win32ColorPrinter should be used despite the presence of MSYSTEM).

[umarcor]

Sorry if I didn't make this clear, but the important point of difference is the use of winpty.

Actually, I had to use winpty to mingw-native, and I forgot to mention it. I edited the tables now.

Running under Git bash means that the environment variable MSYSTEM is set to MINGW64 and
since it's a windows installation, python reports os.name is nt.

The issue is that when running under winpty, VUnit should behave as it would in CMD even though it's actually being run from Git bash (i.e. Win32ColorPrinter should be used despite the presence of MSYSTEM).

The point is: how can we know when is python being executed under winpty? Both, mingw-native and mingw-pacman, return 'nt', and MSYSTEM is set in both contexts.

[umarcor]

It seems that winpty unsets TERM because "The child program isn't directly running under the terminal, though. It's running inside a Windows console" (rprichard/winpty#140 (comment)).

@ryanfitzsimon can you try if IS_WINDOWS_SYSTEM and ('TERM' not in os.environ):?

[ryanfitzsimon]

can you try if IS_WINDOWS_SYSTEM and ('TERM' not in os.environ):?

This does work in my specific environment, but I don't know if relying on the absence of TERM will be very robust. Further thought is probably warranted.

Perhaps additional option/s could be added to allow forcing a specific color printer, extending or replacing the existing --no-color?

Most programs I'm familiar with treat empty/unset environment variables the same way, so could
'MSYSTEM' not in os.environ be changed to not os.environ.get('MSYSTEM')?
This would at least allow the problem to be easily worked around by launching with MSYSTEM= winpty python run.py.

[umarcor]

but I don't know if relying on the absence of TERM will be very robust. Further thought is probably warranted.

We can check both MSYSTEM and TERM, so that TERM is only used to detect when winpty is being used. Anyway, let's ping @kraigher.

Perhaps additional option/s could be added to allow forcing a specific color printer, extending or replacing the existing --no-color?

To preserve backwards compatibility, --color can be defined, which would accept lin, win or none. Then, --no-color would be an alias of --color none.

could 'MSYSTEM' not in os.environ be changed to not os.environ.get('MSYSTEM')?

I do think so. It would preserve the current behaviour. Do you want to submit a PR?

[eine]

We are hitting a similar issue when using tox on windows. See #536, tox-dev/tox#1468 and tartley/colorama#230.

[GlenNicholls]

I found that the terminal colors on Windows 10/Git Bash is fine. However, on Windows 7/Git Bash, they appear in the terminal like so:

←[0m←[m===============================================================================================
←[0m←[32;1mpass←[0m←[m 1 of 1
←[0m←[m===============================================================================================
←[0m←[mTotal time was 4.3 seconds
←[0m←[mElapsed time was 4.3 seconds
←[0m←[m===============================================================================================
←[0m←[32;1mAll passed!←[0m←[m

In both cases, os.name='nt'