TCC has no internal ANSI support, and doesn't control its own output, much less output from other apps like grep & sed.
The only thing that TCC does is (if ANSI is set in TCMD.INI) call SetConsoleMode with the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag. That behavior is unchanged for the last few years.
Go to OPTION / Windows and look at "ANSI Colors". If that is unchecked, then either you *do* have a TCMD.INI that's setting ANSI=0, or you're doing an "OPTION //ansi=0" somewhere.
If it is checked, then something in your system (plugin, injected dll, console windows host) is turning off ENABLE_VIRTUAL_TERMINAL_PROCESSING in a SetConsoleMode call.
I had ANSI=No in the [TakeCommand] section (meaningful for TakeCommand? I wouldn't expect it to affect TCC outside of TCMD). I made it ANSI=Yes. There was a commented-out ";Win10ANSI" (meaningful? I removed it).
It's no better than earlier.
TCC and CMD do this FOR command differently (compatibility issue?).
Code:
for /l %x in (1,1,1000) do @echo My dog has fleas. | d:\c64\grep dog | d:\c64\sed -e 's/\(dog has\)/\x1B[32;41;1m\1\x1B[0m/g'
CMD does the piping anew every time through the FOR loop. TCC sets up the two pipes and then does the FOR command. When I use parentheses to force TCC to do it like CMD it gets slower (expected) and uglier, misbehaving most of the time.
You need the ANSI=Yes directive in the [4NT] section. It will be ignored in the [TakeCommand] section. (You didn't say whether ANSI was checked in OPTION - if it wasn't, you *are* using a TCMD.INI, because ANSI defaults to on.)
Win10ANSI is an obsolete directive; it was only necessary for the first version or two of Win 10.
Without the parentheses it's OK. But that's over in less than a second because TCC (unlike CMD, which takes >1 min) only sets up the pipes once and then does the FOR command. It's the repeated setting up of the pipes that seems to be the problem
If TCC detects it's in a child pipe process, it does not (re)set the console ANSI flag (ENABLE_VIRTUAL_TERMINAL_PROCESSING). That would be a bad thing to do.
One problem is that you're using 'single quotes', which are fine in bash, but work imperfectly in a TCC command shell. Cygwin utilities accept 'single quotes' to enclose arguments in the command tail, but TCC is not bash and therefore the arguments need "double quotes". In fact, I would even use backticks to protect the quotes, `" . . ."` like this.
Several Cygwin utilities do not play well with TCC because they expect a Cygwin environment. If you replace the Cygwin utilities with Unix tools that are compiled for Windows without Cygwin DLLs, you'll get a better response.
I was able to reproduce your problem with TCC version 23, and it hung on the last iteration:
When grep and sed point to a different compile, the output was normal and behaved as expected.
One more thing. The \(parenthesized group\) in the "s/ubsti/tution/" can be replaced with simply dog has, no grouping, and the replacement pattern can be the ampersand. This will eliminate some of the noise.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.