How to? TCC/LE colour not working with RSpec

[Tim Rowe]

I'm trying out TCC under Windows 8.1 as part of my Ruby development environment, but I find that RSpec's --color option doesn't work in TCC/LE -- I see the control codes instead of the colours. I have ANSI colour enabled in TCC. Colour works fine in an Ansicon console (so the problem doesn't seem to be with RSpec), but I see Ansicon is not compatible with TCC.

Is there any way to get RSpec working properly with TCC, or do I have to drop the idea of using TCC?

 

[Steve Fabian]

Close to 10 years since JP Software implemented its own subset of X3.64, since Microsoft refused to include its own. Enabling "ANSI color" in TCC (both LE and licensed version) sends TCC output through this; it cannot work for other programs ANSICON is another implementation. Did you try to disable TCC's "ANSI color" ?

 

[Tim Rowe]

TCC doesn't respond to RSpec's colour output whether the TCC ANSI-color option is on or off.

I realise that ANSICON is another shell implementation -- it's the one I'm having to use because TCC doesn't seem to work properly.

 

[Charles Dye]

TCC's ANSI support only works for ANSI sequences generated by TCC itself. It doesn't (can't) affect other programs which happen to be running in the same console.

(Adding: ) If the program is not interactive -- if it just runs and sends its output to stdout -- then you can pipe the output through TYPE. That way, TCC can see and expand any ANSI sequences. I know nothing of RSPEC, whether it's interactive or not.

 

[Tim Rowe]

@Charles Dye That doesn't make any sense at all. The whole point of the ANSI control sequences is that any console application can send them to the console -- and RSpec is sending the control sequences to the console (I can see them), but the console isn't respecting them. All the Linux shells I know of can (and do) do it, and so does Ansicon.

RSpec is not interactive at all. It's a pure command-line application -- you give it parameters on the command line; it writes its results to STDOUT; TCC fouls up the output that RSpec has written by ignoring the ANSI control sequences.

[edit: piping through TYPE makes no difference whatsoever]

 

[Charles Dye]

@Charles Dye That doesn't make any sense at all. The whole point of the ANSI control sequences is that any console application can send them to the console -- and RSpec is sending the control sequences to the console (I can see them), but the console isn't respecting them. All the Linux shells I know of can (and do) do it, and so does Ansicon.

That's as I would expect. Microsoft's console knows nothing of ANSI sequences. If RSpec sends ANSI sequences to the console, then the console will display gribble. TCC isn't involved, doesn't see RSpec's output and can't interpret it. (Just the same as running RSpec from CMD.EXE.)

[edit: piping through TYPE makes no difference whatsoever]

That is a surprise to me. If RSpec's output goes to stdout, then piping through TYPE ought to find and interpret the ANSI sequences, provided ANSI support is enabled.

If you redirect RSpec's output to a file with >OUTFILE.TXT, does the file contain the expected output, including escape sequences? And does TYPE then display it as expected, including colors?

 

[Tim Rowe]

@Charles Dye Sorry, I still don't understand. Where does the Microsoft console come into it? I'm running RSpec from the TCC command line, I don't have a microsoft console running at all. And if I have ANSI colours enabled in TCC, doesn't that make it an ANSI-aware console like KDE Konsole or Ansicon?

No, if I redirect the output to outfile.txt (ok, I'd already done it and called it ansi_test.bin) it strips the control sequences out completely.

Here's what the same command (rspec --color) looks like in ansicon and TCC, together with a hex dump of the redirected file showing that the control characters have been stripped.

 

[vefatica]

@Charles Dye Sorry, I still don't understand. Where does the Microsoft console come into it? I'm running RSpec from the TCC command line, I don't have a microsoft console running at all.

TCC's console **is** Microsoft's console, the same console that every non-windowed program gets by default. TCC (like CMD, PowerShell, et c.) does not create the window you see. ANSICON is a windowed program. It creates its own window and implements console features in that window.

 

[Charles Dye]

@Charles Dye Sorry, I still don't understand. Where does the Microsoft console come into it? I'm running RSpec from the TCC command line, I don't have a microsoft console running at all.

Microsoft's console code is called whenever you run a console program, whether CMD.EXE, RSpec, or TCC. These are all Windows console programs.

And if I have ANSI colours enabled in TCC, doesn't that make it an ANSI-aware console like KDE Konsole or Ansicon?

Nope. Same old Microsoft console, with the same annoying limitations.

No, if I redirect the output to outfile.txt (ok, I'd already done it and called it ansi_test.bin) it strips the control sequences out completely.

Ah, that explains why my TYPE trick fails. Apparently RSpec is smart enough to know when its output is being redirected, and modifies its output accordingly.

The good news is that -- based on about 20 seconds of intensive testing -- ANSICON seems to work okay with TCC/LE. (At least in its default mode of launching a subshell; I didn't test the -P option.) So you can have the best of both worlds.

 

[Charles Dye]

ANSICON is a windowed program. It creates its own window and implements console features in that window.

I was completely unaware of ANSICON until Tim brought it to my attention. (Strange; I've used some of Jason Hood's other programs before.) But it looks like ANSICON modifies Microsoft's console support via DLL injection. Pretty cool.

 

[vefatica]

I have successfully built ANSICON.DLL as a TCC plugin. If I recall correctly, with this plugin and TCC's "ANSI=No" you'd get what you want. I'll look for it, test it a bit, and make it available if you want to try it.

 

[Charles Dye]

I have successfully built ANSICON.DLL as a TCC plugin. If I recall correctly, with this plugin and TCC's "ANSI=No" you'd get what you want. I'll look for it, test it a bit, and make it available if you want to try it.

After some cursory testing, ANSICON.EXE -P also seems to work in TCC. Would a plugin offer any advantage over loading it that way?

 

[vefatica]

After some cursory testing, ANSICON.EXE -P also seems to work in TCC. Would a plugin offer any advantage over loading it that way?

Plugins are loaded automatically (and ANSICON.EXE is not needed). Your way ... does ANSICON.EXE remain running?

 

[Charles Dye]

Plugins are loaded automatically (and ANSICON.EXE is not needed). Your way ... does ANSICON.EXE remain running?

I think it just injects the DLL, but you know more about it than I do. (I just read the README.TXT. One of the names in the acknowledgments looks familiar, somehow....)

 

[vefatica]

I think it just injects the DLL, but you know more about it than I do. (I just read the README.TXT. One of the names in the acknowledgments looks familiar, somehow....)

Well, I tried it with CMD. With "-P" it starts a new CMD and ANSICON.EXE persists. But with "-p" it injects the DLL into the current CMD and does not persist. You're right ... it only needs to inject the DLL, nothing at all more. In fact, if I inject the DLL with my own, gereric, INJECTDLL.EXE, it works just as well.

I had forgotten about my little contribution, which came from a discussion, here, about TCC's ANSI.