Program execution that use Cygwin utilities disable Ansi sequence (cmd.exe terminal)

[progamateur]

Windows 10 21H1 cmake version 3.21.4 VSC 2019 - 16.11.6 / MSVC v142 / kit SDK Windows 10 (10.0.19041.0)

install Cygwin/mingw64 if necessary

try this script:

import os

echo '\x1B[31m' + ' Hello foo: before c++/\msys64 use ' + '\x1B[0m'
os.exec('C:\\msys64\\mingw64\\bin\\c++ --version')
echo '\x1B[32m' + ' Hello foo:  after c++/\msys64 use ' + '\x1B[0m'

echo ""
echo '\x1B[31m' + ' Hello foo: before c++/cygwin use ' + '\x1B[0m'
os.exec('C:\\cygwin64\\bin\\c++ --version')
echo '\x1B[32m' + ' Hello foo:  after c++/cygwin use ' + '\x1B[0m'

result:

Hello foo: before c++/\msys64 use 
Hello foo:  after c++/\msys64 use 

Hello foo: before c++/cygwin use 
←[32m Hello foo:  after c++/cygwin use ←[0m

P.S. easier to test the 'bug': download wgrib2.exe and all cygwin dll at: https://ftp.cpc.ncep.noaa.gov/wd51we/wgrib2/Windows10/v3.0.2/

echo '\x1B[31m' + ' Hello foo: before wgrib2 use ' + '\x1B[0m'
os.exec('path_to_wgrib2\\wgrib2 --version')
echo '\x1B[32m' + ' Hello foo:  after wgrib2 use ' + '\x1B[0m'

[mcfriend99]

Is this build based on MinGW or Visual Studio??

[progamateur]

Visual Studio

[mcfriend99]

Either way, the output is valid. Using python to print the same string gave the same result. And it is working fine in the MSYS/MinGW64 console.

The ← character you are seeing is due to character decoding. Blade can print Unicode and Extended character sets encoded within strings so long as the terminal supports it.

[mcfriend99]

Either way, the output is valid. Using python to print the same string gave the same result. And it is working fine in the MSYS/MinGW64 console.

The ← character you are seeing is due to character decoding. Blade can print Unicode and Extended character sets encoded within strings so long as the terminal supports it.

It's important to note that the behavior reported is the default for Windows Command Prompt.

[progamateur]

Can you explain why the Ansi sequences are not treated the same way depending on the use of Cygwin tools?

Note that the problem does not occur in JavaScript:

Try this JS script:

const { execSync } = require('child_process')
const os_exec = (cmd) => execSync(cmd, {encoding: 'utf8'})

console.log('\x1B[31m' + ' Hello foo: before c++/\msys64 use ' + '\x1B[0m')
os_exec('C:\\msys64\\mingw64\\bin\\c++ --version')
console.log('\x1B[32m' + ' Hello foo:  after c++/\msys64 use ' + '\x1B[0m')

console.log("")
console.log('\x1B[31m' + ' Hello foo: before c++/cygwin use ' + '\x1B[0m')
os_exec('C:\\cygwin64\\bin\\c++ --version')
console.log('\x1B[32m' + ' Hello foo:  after c++/cygwin use ' + '\x1B[0m')

Result:

Hello foo: before c++/msys64 use 
Hello foo:  after c++/msys64 use 

Hello foo: before c++/cygwin use 
Hello foo:  after c++/cygwin use 

[mcfriend99]

The NodeJS version works because NodeJS has ANSI sequence enabled by default for Windows. However, by default it is disabled and that is why Blade (and Python as well as many others) have it disabled by default. Python does have a terminal that ships with the official Windows version that enables it by default though.

For Blade, the escape sequences works perfectly fine when you use them on an OS where they are supported by default.

You can try this to enable it by default in all your terminals on Windows 10+

In Regedit, Add a new DWORD VirtualTerminalLevel to HKEY_CURRENT_USER\Console and set it's value to 1. Exit all cmd and Powershell instances and run the code again. This time you'll see it works perfectly.

We can start a feature request to have it enabled by default.

[progamateur]

VirtualTerminalLevel was already set to 1. the workarounds I found was to use either Conemu terminal instead of cmd.exe or install ansicon (https://github.com/adoxa/ansicon/releases/tag/v1.89) and run ansicon -i)

cf. : https://stackoverflow.com/questions/16755142/how-to-make-win32-console-recognize-ansi-vt100-escape-sequences

[mcfriend99]

It works for me with just the VirtualTerminalLevel set to 1. You can raise a new feature request if you really want to see this mode enabled by default in Blade for Windows OS.

I'll be closing this issue for now.

[progamateur]

For me VirtualTerminalLevel is set to 1 by default. When running the following script:

echo os.exec('reg query HKCU\\Console /v VirtualTerminalLevel')
echo '\x1B[31m' + ' Hello foo: before wgrib2 use ' + '\x1B[0m'
echo os.exec('wgrib2 --version & reg query HKCU\\Console /v VirtualTerminalLevel')
echo '\x1B[32m' + ' Hello foo:  after wgrib2 use ' + '\x1B[0m'

you get:

HKEY_CURRENT_USER\Console
    VirtualTerminalLevel    REG_DWORD    0x1

 Hello foo: before wgrib2 use 
v3.1.0 10/2021  Wesley Ebisuzaki, Reinoud Bokhorst, John Howard, Jaakko
Hyvätti, Dusan Jovic, Daniel Lee, Kristian Nilssen, Karl Pfeiffer, Pablo Romero, Manfred Schwarb, Gregor Schee, Arlindo da 
Silva, Niklas Sondell, Sam Trahan, George Trojan, Sergey Varlamov

HKEY_CURRENT_USER\Console
    VirtualTerminalLevel    REG_DWORD    0x1

←[32m Hello foo:  after wgrib2 use ←[0m

you can see that VirtualTerminalLevel is set to 1 before and after executing wgrib2.exe (that uses cygwin dlls). No need to go further on this problem for the moment (I'll install ansicon permanently)

[mcfriend99]

I just tested and can confirm. I think it still boils down to not having to depend on a tweak to your OS to get ANSI escapes working. If there is a request to have it as a default in Blade, I'm sure we could look at it together and hope you'll make out time to test such feature if voted.

[progamateur]

Ok. Thanks for the time spent on this problem.