What's TCMD's problem with ^e[0m?

[vefatica]

The ANSI escape sequence ^e[0m is pretty deeply ingrained in Ubuntu. And TCMD can't handle it. It makes TCMD's text black on black (while the underlying console is OK). What exactly is the problem and can it be fixed? I can't run bash or tcsh in a tab unless I re-write all the color related code in many start-up files.

 

[rconn]

The problem is not TCMD, it's a bug in the Windows 10 ANSI. It's setting the console attributes to a 0 fg and a 0 bg.

I *could* do what the console is doing and automatically convert a 0/0 to a 7/0, but that doesn't seem like a particularly desirable solution.

 

[vefatica]

The problem is not TCMD, it's a bug in the Windows 10 ANSI. It's setting the console attributes to a 0 fg and a 0 bg.

I *could* do what the console is doing and automatically convert a 0/0 to a 7/0, but that doesn't seem like a particularly desirable solution.

As mentioned before, the attributes are OK in the console screen buffer. I don't understand how the visible console and its underlying buffer can be OK while TCMD gets it wrong. But apparently that's my failure to comprehend how TCMD actually reads console output. Could you get the defaults at startup and use them instead of a hard-coded 7/0? The alternative is to change every reference to ^e[0m which would be quite hard in Linux and which would break if the defaults were changed. I think colored prompts and ls listings are the default in bash and tcsh and those shells work pretty badly in TCMD.

 

[rconn]

As mentioned before, the attributes are OK in the console screen buffer.

No, they really aren't. The difference is when those 0/0 attributes are written to a visible console window, they get converted to a 7/0. This is a recent break in the Win 10 ANSI support.

TCMD does not convert the console attributes; it displays what is actually there. TCMD gets it right, and the visible console gets it wrong.

 

[vefatica]

Are we talking about the same thing? Here's an image of a TCMD tab not showing the output of "dir /k /m *.txt" and VIEW showing the line "2019-01-13 13:30 15 greenfoo.txt" with (apparently) the correct attributes (7/0). The plugin CONIMAGE uses ReadConsoleOutput() to get the character and attributes and writes the data in raw format to a file. If I use that file and the plugin CONRESTORE (WriteConsoleOutput()) the restored text is visible in TCMD. Where are the 0/0 attributes used by TCMD coming from?

 

[rconn]

TCMD does not use ReadConsoleOutput, it uses ReadConsoleOutputCharacter and ReadConsoleOutputAttribute. And the latter does *not* autotranslate the 0/0 to a 7/0.

 

[vefatica]

TCMD does not use ReadConsoleOutput, it uses ReadConsoleOutputCharacter and ReadConsoleOutputAttribute. And the latter does *not* autotranslate the 0/0 to a 7/0.

Somewhat amazing ... the two approaches give different results when reading the same console screen buffer! Could it be the other way around? ... 7/0 is really in the console screen buffer and ReadConsoleOutputAttribute is (incorrectly) changing that to 0/0?

I ought to be able to see that for myself ... right?

 

[vefatica]

Wow! That was pretty easy to see. After I print a bright green on black "Hello ", followed by a "normal" (?) white on black "world!", like this ...

wprintf(L"\033[32;1mHello \033[0mworld!\n");

... when I read the attributes with ReadConsoleOutputAttribute() I get

10 10 10 10 10 10 0 0 0 0 0 0

When I read them with ReadConsoleOutput() I get

10 10 10 10 10 10 7 7 7 7 7 7

Does this bug exist in the release version of Windows 10?

 

[rconn]

Somewhat amazing ... the two approaches give different results when reading the same console screen buffer! Could it be the other way around? ... 7/0 is really in the console screen buffer and ReadConsoleOutputAttribute is (incorrectly) changing that to 0/0?

Seems pretty unlikely that ReadConsoleOutputAttribute would only be doing that after the ^e[0m escape sequence.

 

[rconn]

Does this bug exist in the release version of Windows 10?

AFAICT it just appeared in the preview builds. Which doesn't mean that Microsoft won't push it out in a monthly update, or fail to fix it in the spring release.

 

[vefatica]

Seems pretty unlikely that ReadConsoleOutputAttribute would only be doing that after the ^e[0m escape sequence.

I agree. But on the other hand, I figure what's in the console screen buffer reflects what you see and that would make 7 (the default) correct.

 

[rconn]

I agree. But on the other hand, I figure what's in the console screen buffer reflects what you see and that would make 7 (the default) correct.

But you don't *know* what's in the screen buffer. Different APIs return different things.

 

[vefatica]

But you don't *know* what's in the screen buffer. Different APIs return different things.

I'll go with "what you see is what's really there". Anything I manually put in the console screen buffer with attribute 0 is invisible. I haven't got a clue why I can see it while ReadConsoleOutputAttribute says it has attribute 0. Sadly, I suspect we'll never know what's going on.

 

[vefatica]

Do you give MS any feedback? I reported the issue and sent them this little test app and pic (both attached).