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

May 20, 2008
9,274
62
Syracuse, NY, USA
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.
 
May 20, 2008
9,274
62
Syracuse, NY, USA
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

Administrator
Staff member
May 14, 2008
10,975
97
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.
 
May 20, 2008
9,274
62
Syracuse, NY, USA
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?

1548464427964.png
 
May 20, 2008
9,274
62
Syracuse, NY, USA
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?
 
May 20, 2008
9,274
62
Syracuse, NY, USA
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 ...
Code:
wprintf(L"\033[32;1mHello \033[0mworld!\n");
... when I read the attributes with ReadConsoleOutputAttribute() I get
Code:
10 10 10 10 10 10 0 0 0 0 0 0
When I read them with ReadConsoleOutput() I get
Code:
10 10 10 10 10 10 7 7 7 7 7 7
Does this bug exist in the release version of Windows 10?
 

rconn

Administrator
Staff member
May 14, 2008
10,975
97
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.
 
May 20, 2008
9,274
62
Syracuse, NY, USA
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.
 
May 20, 2008
9,274
62
Syracuse, NY, USA
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.