On Windows, escape sequences don't color Deno's output and display as ordinary text.
For example, an error stack trace looks like:
Uncaught SyntaxError: Unexpected string
at 鈫怺1m鈫怺3m鈫怺90mevaluate鈫怺39m鈫怺23m鈫怺22m鈫怺90m(鈫怺39m鈫怺90m$deno$/repl.ts鈫怺39m鈫怺90m:鈫怺39m鈫怺90m45鈫怺39m鈫怺90m:鈫怺39m鈫怺90m34鈫怺39m鈫怺90m)鈫怺39m
at 鈫怺1m鈫怺3m鈫怺90mObject.replLoop鈫怺39m鈫怺23m鈫怺22m鈫怺90m(鈫怺39m鈫怺90m$deno$/repl.ts鈫怺39m鈫怺90m:鈫怺39m鈫怺90m136鈫怺39m鈫怺90m:鈫怺39m鈫怺90m13鈫怺39m鈫怺90m)鈫怺39m
I hope that this can be fixed.
Have you tried using the standard library?
@cj81499 My issue isn't about how to create escape sequences, what I could use the library for, but about how to render them correctly on the screen, and doing the same with the error logs generated by Deno.
Is it possible that your terminal application doesn't support color codes? What application are you using?
I'm using cmd.exe on Win 10 (in legacy console mode), that doesn't support escape sequences by default, but Node.js managed somehow to make them work.
@piscisaureus PTAL as it's Windows issue
@fzs111 seems like you could just use a different terminal, such as Powershell or Windows Terminal.
@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...
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.
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.
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
@always90s, they are. On Windows 8 the only way to get support for it is to install PowerShell 5.
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?
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
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.
Probably the same issue as #6367
@Spoonbender, exactly the same issue :)
@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.
You'll run into this with any module that uses escape sequences which is why I think it's not worth trying to support it; console.log can have some support for web style coloring since it's in CLI but other all modules that use escape sequences wether it be in std/ or x/ are going to have this problem and users should just use a better terminal emulator IMHO.
Mostly hang around on Unix but when I do use Windows I use ConEmu because of the limitations of the default conhost as it's a common problem with portable cli programs.
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.
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.
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.
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".
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.
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/[email protected]/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.
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.
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.
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.