deno: Coloring with escape sequences doesn't work on Windows

I’d give them all the same advice, which is to avoid using inferior software when something better is readily available (which is exactly why people are interested in Deno over Node), but I understand your point.

@cj81499 I could use a different terminal, of course, but Deno also could be fixed, if it’s possible to fix. That’s why I reported this issue here.

Also, it isn’t just about me, but everybody who wants to use Deno with cmd.exe for some reason. If I just moved on to a different terminal, then the next one of them would have opened this issue…

Windows 7

Windows 8.1 isn’t however.

if pretty output is wanted

The problem is not “pretty output” though, output is gibberish right now as it contains control characters. The example provided here show how illegible the whole thing is.

Interesting, I would have expected it to work out of the box. On my Windows 10 installation it did. Maybe you need to enable it https://stackoverflow.com/questions/51680709/colored-text-output-in-powershell-console-using-ansi-vt100-codes

Still, it will be an issue on Windows 8.1

I tried this (Windows 8.1 too), it works for PowerShell when ran as a stand alone program. When ran as embedded in VS Code all the escape sequences keep being displayed as text (just like in the original report). I tried configuring VS Code to launch an external terminal instead of an embedded one and also tried changing the render type of the terminal (auto, canvas, dom, experimentalWebgl) but nothing helped.

@always90s, they are. On Windows 8 the only way to get support for it is to install PowerShell 5.

I’d like to second @fzs111’s concern.

The issue is not limited to Windows 10’s legacy mode but also appears on earlier Windows versions with, both, the standard command prompt and PowerShell.

@fzs111 seems like you could just use a different terminal, such as Powershell or Windows Terminal.

The whole subject is not really about colours or not colours.

Standard output on pre-Windows 10 is broken altogether and only produces gibberish.

I’m merely pointing out that Windows has a different support lifecycle than Deno. Just because some old Windows version is still supported by Microsoft, doesn’t mean Deno has to support it, too.

That is clear, hence my question if Windows 8 is a supported platform or not.

Also, as I have pointed out, “support” is a spectrum of various degrees. Deno can support Windows 8.1, but not support properly colored output in cmd.exe. Those are not contrary positions.

It is I am afraid. As I addressed earlier, if it is a support platform reported bugs should be acknowledged and fixed. If it is not supported, obviously not but that should be communicated.

Deno is an open source project. Feel free to send a PR.

Again, no offence but these standard phrases are not very helpful.

As far as I am aware, Node does not ship with a “color this string for terminal output” function. The goto package here is chalk. chalk does not call Windows Console APIs, but uses escape sequences, too.

chalk does have detailed checks for whether colors are supported, though:

// Windows 10 build 10586 is the first Windows release that supports 256 colors.
// Windows 10 build 14931 is the first release that supports 16m/TrueColor.

https://github.com/chalk/supports-color/blob/master/index.js#L70-L71

I think the “are colors supported?” checks are a good idea and something that we can add to Deno.

Personally, I think it’s not worth the trouble to implement the Windows Console APIs for color support on older systems, such as, old Windows 10 builds (we’re at 19041 now, first build with color support is 10586), Windows 8.1, 8, 7, Windows Vista, XP, etc.

Recent Windows 10 builds seems like a reasonable target to me.

That might be true, but a bug in a module does not mean it should be equally buggy everywhere else. Colour sequences are not supported on all systems and Windows is one of them.

If there is no plan to address that, then the consequence should be to officialy drop support for pre-10 versions respectively for the traditional command prompt.

I ran the following command in my windows powershell window

PS C:\Users\hrana> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      14409  1018

Do I need to downgrade to powershell 5 instead of 5.1?

Have you tried using the standard library?

Whenever a hipster software does stuff like unasked and unsuccessful printing colors to my cmd.exe, I temporarily use a console wrapper called cmder, which has other bugs, but hides these ‘←[33m’ thingies.

Of course, it would be better if software would behave more conservative regarding default console windows in second most used operating systems in the world.

Edit: I just learned, by typing deno help that an environment variable NO_COLOR=true will disable this. I take back the ‘hipster’ comment.

Edit 2: I have created a SO self answer pointing to the environment variable or console emulators.

I found a workaround, get ANSICON. Install following the instructions in the readme.txt. If you want this just for VS Code instead of a global installation you can use the following settings:

"terminal.integrated.shell.windows": "C:\\Windows\\System32\\cmd.exe",
"terminal.integrated.shellArgs.windows": ["/C", "C:\\Path\\To\\ANSICON\\x64\\ansicon.exe"],

It disables colors in all other console applications too), but all escape sequences, including e.g. cursor control, without which many interactive and some non-interactive CLI apps break.

I know, but if you don’t have a capable terminal emulator that’s pretty much expected. Not that many people bother with non vt100 capable terminal emulators. Most of cli’s available via npm rely heavily on it.

Really just boils down to if we want to support curses/conio-esque syscalls in the Deno namespace.

As mentioned by @neroux & @fzs111 this isn’t about “pretty output”, it’s about usable output. In Windows 8.1 this is the type of output received whether using cmd.exe or PowerShell (versions 4, 5.1, 7.02, 7.03 or 7.1.0):

PS C:\Users\x> deno
Deno 1.6.2
exit using ctrl+d or close()
> {k:"L"}
{ k: ←[32m"L"←[39m }
> "Hello, world"
←[32m"Hello, world"←[39m
> [1,2,3]
[ ←[33m1←[39m, ←[33m2←[39m, ←[33m3←[39m ]

PS C:\Users\x> deno eval "console.log('Hi, W')"
Hi, W
PS C:\Users\x> deno eval "console.log({g: 'Hi, W'})"
{ g: ←[32m"Hi, W"←[39m }

@caspervonb And, this isn’t just about pretty output (that one could turn off without consequences with a simple NO_COLOR=1 env variable – though it disables colors in all other console applications too), but all escape sequences, including e.g. cursor control, without which many interactive and some non-interactive CLI apps break.

Windows extended support != Deno support.

So Windows 8.1 is not a supported platform by Deno?

I don’t know whether it’s supported or not. I haven’t seen any official statements about Windows support in the docs.

I’m merely pointing out that Windows has a different support lifecycle than Deno. Just because some old Windows version is still supported by Microsoft, doesn’t mean Deno has to support it, too.

Also, as I have pointed out, “support” is a spectrum of various degrees. Deno can support Windows 8.1, but not support properly colored output in cmd.exe. Those are not contrary positions.

Simply disable the colour sequences on platforms which do not support it and we are good.

Deno is an open source project. Feel free to send a PR.

Windows extended support != Deno support.

So Windows 8.1 is not a supported platform by Deno?

AFAIK, deno eval -p “‘Hello, world!’”

No offence, but that remark is somewhat pointless 😉

I agree that Deno.noColor could automatically determine that colors are not supported on older Windows builds to disable colored formatting on such systems. That’s a simple, unintrusive fix. But implementing complicated Windows Console APIs for systems that are gonna be off extended support soon seems just plain unnecessary to me.

I never said Windows colours should be supported. Simply disable the colour sequences on platforms which do not support it and we are good.

it is a supported system

Windows extended support != Deno support.

Right now its output is useless.

AFAIK, deno eval -p "'Hello, world!'" works fine, even without colors. Even better, both std/fmt/colors and cli/js/colors respect NO_COLOR so set NO_COLOR=1& deno eval -p "(await import('https://deno.land/std@v0.60.0/fmt/colors.ts')).red('Hello, world!')" works just fine, too.

I agree that Deno.noColor could automatically determine that colors are not supported on older Windows builds to disable colored formatting on such systems. That’s a simple, unintrusive fix. But implementing complicated Windows Console APIs for systems that are gonna be off extended support soon seems just plain unnecessary to me.

End of extended support is 2023.

Exactly what I said, it is a supported system and if it is supported by Deno, bug reports should be adequately received and fixed.

Just because colors are incorrectly displayed in some terminals, doesn’t mean it’s “imcompatible”.

It pretty much is. Right now its output is useless. It also is not “some terminals” but the basic system terminals. As I said before, it is pretty easy. Either fix the issue or mark everything before 10 as unsupported.

8.1 however still is supported.

Windows 8.1 is from 2013. End of mainstream support was 2018. End of extended support is 2023. Again, I don’t think it’s worth it to invest too much time into supporting those older systems.

Then mark Deno as incompatible with Windows 8, respectively clearly state only Windows 10 is a supported platform, and you are good to go.

Just because colors are incorrectly displayed in some terminals, doesn’t mean it’s “imcompatible”.

Well, everything before 8.1 is not supported anymore anyhow, so it is not unreasonable to say Deno doesn’t support it either. 8.1 however still is supported.

Recent Windows 10 builds seems like a reasonable target to me.

Then mark Deno as incompatible with Windows 8, respectively clearly state only Windows 10 is a supported platform, and you are good to go.

As it is right now the output on Windows 8 is pretty useless.

I think the “are colors supported?” checks are a good idea and something that we can add to Deno.

That would be preferable of course.

@caspervonb, as for “abandoning legacy systems”, yes it is accurate that Microsoft is moving towards a more Unices-like formatting here, however Windows 8 doesn’t support colour sequences at all and even Windows 10 doesn’t fully support them.

Considering that Windows 8 is still a support system, which also seems to be supported by Deno, it is fair to call this a bug.

I’m getting the following results after installing Deno on my Windows 8 machine. I ran the following command from windows powershell and from vscode terminal. Seems like the escape characters are always showing up.

> 4+5
←[33m9←[39m
> 11 + 4
←[33m15←[39m
> 19 + 5
←[33m24←[39m