ANSI?

[vefatica]

No plugins, no INI file, no TCSTART, grep and sed are from Cygwin. Why does this happen?

 

[rconn]

TCC doesn't do ANSI, that's done by Windows. Or not, in your case.

 

[vefatica]

For a fair comparison I used this command instead.

for /l %x in (1,1,10) 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'

TCC screws it up (randomly, more or less as pictured) when running in a console, in TCMD, and in WindowsTerminal.

The same command run by CMD never screws up in any of those three scenarios.

I don't believe it's Windows's fault.

 

[vefatica]

With the command below, I can do the same in Powershell. Powershell behaves OK in a console, in TCMD, and in WindowsTerminal.

for ($var = 1; $var -le 100; $var++) {echo "My dog has fleas." | d:\c64\grep dog | d:\c64\sed -e 's/\(dog has\)/\x1B[32;41;1m\1\x1B[0m/g'}

 

[rconn]

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.

 

[vefatica]

I wish I had something better to say. I see a problem in TCC that I don't see using other command interpreters to do the same thing.

 

[rconn]

Check your console settings.

 

[vefatica]

Check your console settings.

What am I looking for? If it's console settings, they're changing randomly.

 

[rconn]

What am I looking for? If it's console settings, they're changing randomly.

Your console properties are changing randomly??? Probably time to reinstall Windows ...

 

[rconn]

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.

 

[vefatica]

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?).

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.

 

[rconn]

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.

 

[vefatica]

ANSI is/was checked in the OPTION dialog.

 

[rconn]

Is this something new in v30?

Does it work if you do it the way CMD does? I.e.:

for /l %x in (1,1,1000) do @echo My dog has fleas. | cmd /c d:\c64\grep dog | cmd /c d:\c64\sed -e 's/\(dog has\)/\x1B[32;41;1m\1\x1B[0m/g'

 

[vefatica]

Is this something new in v30?

Does it work if you do it the way CMD does? I.e.:

for /l %x in (1,1,1000) do @echo My dog has fleas. | cmd /c d:\c64\grep dog | cmd /c d:\c64\sed -e 's/\(dog has\)/\x1B[32;41;1m\1\x1B[0m/g'

No, it goes back to at least v24.

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

 

[rconn]

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.

 

[Eric Pement]

Hello Vince,

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.

Hope this helps.

 

[vefatica]

Double quotes don't help. I think sed parses it's own command line.

 

[ClioCJS]

The problem definitely goes way, way, way back.

I took my test and changed it slightly to work under cmd.exe:

the first line is the cmd, 2nd line is the .btm

tasklist /v |c:\cygwin\bin\grep --text --color=always "opera.exe.*Console"|c:\cygwin\bin\cut.exe -c1-80
tasklist /o /l|c:\cygwin\bin\grep --text --color=always "[0-9][^tc]*opera "|c:\cygwin\bin\cut.exe -c1-%@EVAL[%_COLUMNS-1]

The commands are not quite identical. CMD doesn't have %_COLUMNS and it very well may be that that part is important for the test.

But as it is with this test, the error reproduces in TCC but not in CMD.