ANSI???

[vefatica]

I start TCC from Win+R. I see/do

In the TCMD that's started, I see/do

Why don't I see a green prompt?

 

[rconn]

This has nothing to do with TCMD, which is simply showing you what's in the hidden TCC window.

Most likely, you have different TCMD.INI files, one of which has "ANSI colors" set, and the other doesn't.

 

[vefatica]

See me second post. These are all I have.

d:\tc28> ffind /s /a: c:\tcmd.ini
C:\Users\vefatica\OneDrive\ready\tcmd.ini

d:\tc28> ffind /s /a: d:\tcmd.ini
D:\tc24\tcmd.ini
D:\tc25\tcmd.ini
D:\tc25x86\tcmd.ini
D:\tc26\tcmd.ini
D:\tc27\tcmd.ini
D:\TC28\tcmd.ini

Is there supposed to be "ANSI=" in the [TakeCommand] section? I found one there, removed it, and it made no difference.

 

[vefatica]

After these, all the console prompts are OK ...

... but the three TCMDs (background to foreground) look like this. Every once in a while I actually see the control sequences (independently of the version of the prompt).

 

[rconn]

There is no ANSI directive in the [TakeCommand] section.

There is an ANSI directive in the [4NT] section, which only determines whether to toggle the ANSI bit (with SetConsoleMode) in the console. All ANSI interpretation & display is done by Windows, not by TCC.

Something in your system (not TCC) is either not setting the ANSI directive, or turning it off in the console. (Do an "echo %_ansi" in the misbehaving console.)

 

[vefatica]

I dunno. Here's TCMD and the console after being detached.

With that prompt, I never see a green prompt in TCMD. I had done some testing and found that ^e[32;1m, ^e[92m, and ^e[38;2;0;255;0m all put that attribute 0x000A in the console screen buffer, read with either ReadConsoleOutput or ReadConsoleOutputAttribute (does TCMD use one of those?). I'll do those tests again.

Have you (or anyone else) tried ^e[38;2;0;255;0m?

As you might have guessed, it's not only the prompt. Whenever I use ^e[38;2;0;255;0m in TCMD I get the default foreground color.

 

[vefatica]

Using ReadConsoleOutput in a plugin I see (note: 0041 = 'A', 000A = BRI GRE).

With ReadConsoleOutputAttribute I see

My previous tests must have been flawed. I see that TCMD is OK. Changes in OpenConsole.exe (WindowsTerminal project) leak into CONHOST.EXE. I could ask about this in the WindowsConsole GitHub forum but I imagine it's impossible to turn a specification like ^e[38;2;R;G;Bm (24-bit color) into a 16-bit attribute in a reasonable way. There's still the question of why the two ways of getting the attrinute differ but that's of no concern here.

 

[rconn]

The Windows 10 ANSI supports 24-bit colors; there is no way that those attributes can be read using ANY of the console APIs (because they are never saved in the screen buffer).

 

[vefatica]

The Windows 10 ANSI supports 24-bit colors; there is no way that those attributes can be read using ANY of the console APIs (because they are never saved in the screen buffer).

Just as I said. :-)

Though it's still of no consequence here, ReadConsoleOutput and ReadConsoleOutputAttribute returning different values is fixed in 21H1 (to which I just painlessly upgraded).

 

[vefatica]

Though it's still of no consequence here, ReadConsoleOutput and ReadConsoleOutputAttribute returning different values is fixed in 21H1 (to which I just painlessly upgraded).

My test was faulty. That's not true.