Add "ansi" to supported gtest_color values

[sergio-nsk]

Fixes uncolored output on Windows PowerShell with CTest (#2930)

Fixes uncolored output on GitHub and other Windows terminals.

CTest writes googlest standard output and error streams to standard output and a file. Windows _isatty() returns 0 in this case and ShouldUseColor() returns false. Windows PowerShell supports ANSI escape sequences.

Reviewed-by: Nathan Moinvaziri nathan@nathanm.com
Reviewed-by: steve-tucker steve-tucker@users.noreply.github.com

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[sergio-nsk]

GitHub log before with GTEST_COLOR: 1

GitHub log after with GTEST_COLOR: ansi

[dinord]

Instead of adding an API for forcing ANSI, could we detect whether the output terminal supports it or not?
For example, by updating the ifndef around it, checking some environment variable, etc.

[sergio-nsk]

Instead of adding an API for forcing ANSI, could we detect whether the output terminal supports it or not? For example, by updating the ifndef around it, checking some environment variable, etc.

I doubt it's possible on Windows.

If it does not run on Windows, it uses $TERM to detect if the output terminal supports ANSI colors. It works even if the output stream is redirected to a file or a pipe like | tee does it.

If it runs on Windows, it is able to detect if the output terminal supports colors. But it does not work if the output stream is redirected to a file or a pipe, what exactly happens if ctest, GitHub runners or | tee are used.

--gtest_color=ansi just enables ANSI colors regardless of $TERM or Win32 _istty(). It works in all modern terminals and Windows PowerShell.

[dinord]

I'm worried about the difference between yes and ansi. Both of these are used to turn on colors, but in different ways. If we were to design GoogleTest from scratch, we'd probably want to provide a flag with possible values such as ansi, no, auto, and not_ansi (probably something more informative for the last one).

Instead of expanding the existing flag, could we add another one for using ANSI color escape sequences? I'm okay with it being a force flag (on/off) or a feature flag (on/off/auto).

[sergio-nsk]

The enum is made with the logic 0 - coloring is disabled, !0 - coloring is enabled, 1 or 2 - it's a detail how it is enabled.

[sergio-nsk]

I could make another flag --gtest_color_ansi and keep --gtest_color unchanged, but did not want to add yet another environment variable and to make a larger changeset.

[dinord]

I'd recommend adding another flag, e.g. something like --gtest_use_ansi_color and keep the existing one unchanged.
Most users shouldn't care about the new flag, but by providing it, we leave an escape hatch for those that fail to auto-detect ANSI colors.

[sergio-nsk]

keep the existing one unchanged.

The behavior of the flag --gtest_color and the environment variable GTEST_COLOR with the existing values is unchanged. Nothing is changes for the existing use cases, most users shouldn't care about the new flag - it is kept so, until they start using the new value ansi.

[tanzislam]

I believe #3049 fixes this problem without introducing any options.

[sergio-nsk]

I believe #3049 fixes this problem without introducing any options.

Unfortunately it does not fix the coloring issues.

• gtest_host.exe --gtest_help --gtest_color=yes > out.txt
• gtest_host.exe --gtest_help --gtest_color=yes | tee out.txt
• Git hub test run logs

Neither above is able to color the output. Running them in Windows PowerShell additionally produces UTF-16 uncolored outputs. #3049 is showing the working redirection >test.txt, but I can't confirm it. Tested in Windows PowerShell, Git Bash (MINGW64), cmd.exe.

[tanzislam]

@sergio-nsk I've now rebased #3049 on the latest main branch; could you please try again? When built with MinGW's GCC, if --gtest_color=yes is supplied (or GTEST_COLOR=yes is exported) it should emit colors using ANSI escape sequences when stdout isn't a TTY (e.g. when redirected or piped).

Which compiler are you using on Windows? My PR has the logic only for MinGW toolchain, although I contemplated generalizing it to all Windows compilers.

I've also confirmed the color output (using ANSI escape sequences) working in a PowerShell window with both > out.txt and | tee out.txt redirection. However, the text file does end up getting UTF-16LE encoding under PowerShell, even if colors weren't used -- this seems to be a peculiarity of the PowerShell environment, and as per this page I was able to fix this by running $PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'.