Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

ECHOERR and VT colors?

vefatica

vefatica

May
13,834
211
This (third one below) happens every time. Why?

1737733864676.webp
 
rconn said:
Not reproducible here.

Do you have something defined for error colors (OPTION / Command Line)? Or ANSI disabled in that section?

And are you doing this in a console window, a Terminal window, or a TCMD tab window?
Click to expand...
Yes, error colors are red on default (black). But the same thing happens regardless of that setting. Here's default on default.

1737740514520.webp


It's the same in all three places, console, WT, TCMD
 
It seems more related to the ECHOERR command itself than to stderr. This is OK (stderr normally red).

1737741900301.webp
 
Have the same behaviour as Vince described in posting #1 (3rd is failing) ...

echoerr-prob.webp


Code: 
1>&2 echo ^e[91mfoo^e[0m
is here in red (as Rex posted).

red-text.webp
 
rconn said:
it uses console APIs to write the text & attributes directly to the screen.
Click to expand...

What does that mean?

In my experience, if VT processing is enabled the sequences are honored (period!). Is ECHOERR setting the console output mode?

ECHOERR is OK with this INI line commented.

Code: 
;ErrorColors=Red on Black

In InitializePlugin, all of these (first 3 foos below) work.

Code: 
    fwprintf(stderr, L"\x01b[32;1mfoo\x01b[0m\n");
    WriteConsoleW(GetStdHandle(STD_ERROR_HANDLE), L"\x01b[32;1mfoo\x01b[0m\n", 15, NULL, NULL);
    HANDLE h = CreateFileW(L"CONOUT$", GENERIC_WRITE, FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, 0, nullptr);
    WriteConsoleW(h, L"\x01b[32;1mfoo\x01b[0m\r\n", 16, nullptr, nullptr);
    CloseHandle(h);

1737745015094.webp
 
vefatica said:
What does that mean?

In my experience, if VT processing is enabled the sequences are honored (period!). Is ECHOERR setting the console output mode?

ECHOERR is OK with this INI line commented.

Code: 
;ErrorColors=Red on Black

In InitializePlugin, all of these (first 3 foos below) work.

Code: 
    fwprintf(stderr, L"\x01b[32;1mfoo\x01b[0m\n");
    WriteConsoleW(GetStdHandle(STD_ERROR_HANDLE), L"\x01b[32;1mfoo\x01b[0m\n", 15, NULL, NULL);
    HANDLE h = CreateFileW(L"CONOUT$", GENERIC_WRITE, FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, 0, nullptr);
    WriteConsoleW(h, L"\x01b[32;1mfoo\x01b[0m\r\n", 16, nullptr, nullptr);
    CloseHandle(h);

View attachment 4926
Click to expand...

What it means is that VT processing is only enabled in Windows for one of the console APIs (WriteConsole), and for WriteFile if you're writing to STDOUT / STDERR. Period.

VT sequences are ignored in all of the other console output APIs -- like WriteConsoleOutputCharacter / FillConsoleOutputAttribute, which are used by ECHOERR to write colored text.

This is very old TCC behavior.
 
rconn said:
VT sequences are ignored in all of the other console output APIs -- like WriteConsoleOutputCharacter / FillConsoleOutputAttribute, which are used by ECHOERR to write colored text.

This is very old TCC behavior.
Click to expand...
Oh! Is there any chance that the behavior will change?
 
vefatica said:
Oh! Is there any chance that the behavior will change?
Click to expand...

Change how? You're telling TCC to do two different things at the same time; how did you want it to decide? (And no, I don't think that having TCC parse your string to determine if it's a VT sequence is a good idea.)

Or did you mean you want me to rewrite all of the Windows console APIs to support VT sequences?
 
I think of it as overriding my usual red on bla.

I was thinking of something other than WriteConsoleOutputCharacter / FillConsoleOutputAttribute. Can't you momenrtarily change the output attributes and use WriteConsole?
 
rconn said:
Ahhh - no. How would TCC know it was supposed to do that?
Click to expand...
Maybe I'm missing something. We're still talking about ECHOERR, right? An INI spec for ErrorColors could be a signal (yes/no?).
 
rconn said:
This doesn't make sense. You are already specifying an INI value for ErrorColors (red on black). You want to specify another INI value saying TCC should ignore the first INI value you set?
Click to expand...

Yes. I think of it more as overriding the INI directive (perhaps to call more attention, add bold, italics, underline ...). TCC can still set the text attributes to the INI spec, but the control sequences will have last say and override them. I suppose I could change them temporarily with OPTION but I can't do the other things I just mentioned.

A question: In a little testing (more to come), it seemed that Qprintf(GetStdHandle() ... takes the console out of VT mode. Is that right?
 
vefatica said:
Yes. I think of it more as overriding the INI directive (perhaps to call more attention, add bold, italics, underline ...). TCC can still set the text attributes to the INI spec, but the control sequences will have last say and override them. I suppose I could change them temporarily with OPTION but I can't do the other things I just mentioned.
Click to expand...

As I said, that's not going to happen. I do not plan to scan all output for VT sequences.

vefatica said:
A question: In a little testing (more to come), it seemed that Qprintf(GetStdHandle() ... takes the console out of VT mode. Is that right?
Click to expand...

No. Qprintf never changes the console mode. It just determines whether the text should be passed to WriteConsole or WriteFile or to the console APIs that write characters and attributes directly to the screen.
 
I'm not asking that you scan for VT sequences, just to make sure they reach the the VT-enabled console.

I noticed that these

Code: 
#define str L"\x1b[92mfoo\x1b[0m\r\n"
    Qprintf(GetStdHandle(STD_ERROR_HANDLE),  L"1" str);
    Qprintf(GetStdHandle(STD_OUTPUT_HANDLE), L"2" str);

produce this.

1737757966812.webp


How'd you do that?
 
Are you saying that Qprintf checks to see if the handle is a stderr handle?

Well, if I need this, I can

1737759961808.webp
 
I understand Rex as saying that writing to printing error messages with ErrorColors set does not use the write-to-handle APIs. It isn't using STD_ERROR_HANDLE at all. What Qprintf() can do with that handle isn't relevant; it's a different set of APIs.
 
Charles Dye said:
I understand Rex as saying that writing to printing error messages with ErrorColors set does not use the write-to-handle APIs. It isn't using STD_ERROR_HANDLE at all. What Qprintf() can do with that handle isn't relevant; it's a different set of APIs.
Click to expand...
How do you suppose these

Code: 
#define str L"\x1b[92mfoo\x1b[0m\r\n"
Qprintf(GetStdHandle(STD_ERROR_HANDLE),  L"1" str);
Qprintf(GetStdHandle(STD_OUTPUT_HANDLE), L"2" str);

produce this. It certainly seems to depend on the handle.

1737757966812.webp
 
You must log in or register to reply here.
Back
Top