tee command cancels colors

[old coot]

[C:\batch]type foo.btm
color red on bri yel
echo plain echo
echo to file > file
echo pipe to sort | sort /o sortfile
echo pipe to tee | tee teefile
echo my colors were canceled

[C:\batch]foo
color red on bri yel
echo plain echo
plain echo
echo to file > file
echo pipe to sort
echo pipe to tee
pipe to tee
echo my colors were canceled
my colors were canceled

[C:\batch]

It's a bit of a nuisance, as I'm putting out error messages both to the console and to an error file. But I can work around it by just doing two separate echo statements.

 

[Kachupp]

You'll have to use ansi sequences

 

[rconn]

What version of TCMD and Windows are you running?

Do you have ANSI Colors enabled in TCMD.INI? (See OPTION / Windows).

TCMD doesn't control colors, that's done in the console session (TCC in this case) and simply mirrored in TCMD. And in the console session, TCC doesn't control the display of characters & colors, that's done by Windows. Win 10 & 11 display colors using ANSI, so you need to set that option in TCC.

 

[vefatica]

I think this has to do with another TCC being started to handle the pipe. I believe that under some circumstances, TCC momentarily takes the console out of VT mode (and with the new console, I think color attributes are handled internally with VT sequences). The consequences of piped instances and VT mode have been discussed a little but nothing has come of it. This does it too.

So does this.

 

[old coot]

TCmd 28.01.14 x64
Win 10 Pro 21H1
TCmd.INI:
[TakeCommand] ANSI=No
[4NT] ANSI=Yes
In the windowed options inside TCC, the ANSI box is checked.

I tried changing that one setting in TCmd.INI to Yes. Made no difference.

 

[vefatica]

Note that it does not happen when piping to an external.

 

[rconn]

TEE is incapable of setting (or unsetting) colors; the issue would be with the second instance of TCC you're starting, which does not have any colors set.

 

[vefatica]

It's different at the command line. There, it seems that any pipe cancels the colors.

 

[old coot]

Not pipe to sort.

 

[vefatica]

Another telltale example.

Not pipe to sort.
View attachment 3500

Old coot, I don't understand that test. Here,

Likewise,

 

[old coot]

Interesting. These two command sets produce different results:

color bri yel on gre
echo foo | sort /o trash & echo foo

color bri yel on gre
echo foo | sort /o trash
echo foo

The first one changes the output color; the second does not.

 

[vefatica]

If you have ^e[0m in your prompt, it'll reset the colors.

 

[old coot]

I sincerely hope you have a life outside this forum...

 

[Kachupp]

With a comment like that it's unlikely you're be getting any free help in the future from one of the most knowledgeable users on this site.

I'm offended by it

 

[old coot]

I'm really sorry you feel that way, Kachupp. I fully realize the esteem in which Vince is held here, and I feel honored that he has (and takes!) the time to deal with piddling little posts like mine. After a 50-year career in IT, including plenty of nights spent at work with a sleeping bag, I know how it feels to have precious little time for other activities. And I didn't mind a bit, being on the receiving end of similar comments.

Vince, if you took offense, I apologize.

Bret Sutton

 

[Alpengreis]

I really don't think that old coot meant that offended, that was ironical, that's all.

But I know, sometimes it's difficult to see the ironical point in internet (postings) or something like that.

Take it easy, Kachupp.

 

[vefatica]

And these two differ. That really surprises me.

 

[rconn]

A command like "color yel on gre" doesn't use the Win 10/11 ANSI; it simply sets the default console text attribute via the SetConsoleTextAttribute command. This will be overwritten by the next ANSI sequence (e.g., in the prompt).

If you have a default output color set in OPTION / Windows (the StdColor directive in TCMD.INI), TCC will call SetConsoleTextAttribute when it starts (including in a child pipe process). The only other place TCC will set the colors is if you specify the /Txx startup option.

 

[rconn]

And these two differ. That really surprises me.

View attachment 3504

WAD - in the first instance, TCC sees there's a command following SORT (which SORT won't know how to handle), so it has to call a child TCC process to run SORT and then the ECHO FOO:

tcc /c sort /o trash & echo foo

 

[vefatica]

WAD - in the first instance, TCC sees there's a command following SORT (which SORT won't know how to handle), so it has to call a child TCC process to run SORT and then the ECHO FOO:

tcc /c sort /o trash & echo foo

Hmmm! I have always thought that an unqualified '&' was enough to signal that what comes after it is not part of the command before it. In fact (being quite naive) I have thought that one of the first things done was to separate a compound command at the command separators.

 

[rconn]

Hmmm! I have always thought that an unqualified '&' was enough to signal that what comes after it is not part of the command before it. In fact (being quite naive) I have thought that one of the first things done was to separate a compound command at the command separators.

Well, that'd be (1) incompatible with every other command interpreter, and (2) break almost every batch file that uses pipes. Or compound commands. Or conditional commands.

In your simple (but not real-world useful) example, the "echo foo" could reasonably be executed at the parent process level, not in the child pipe process. (Though there isn't any benefit in trying to pass it back to the parent.) But what about:

cmd1 | cmd2 | cmd3

Cmd3 can't be executed by cmd1, because (1) cmd2 already ate all the output, and (2) cmd3 expects the output to be coming from cmd2.

Similar problems exist with && and || - they need to be the result of the preceding command, not the parent.

So what you're asking is for the parser to automagically determine whether anything on the right side of a separator (&, &&, |, or ||) *might* not have any interaction with the command immediately preceding it. Without knowing what the command (especially an external) is going to do. And what would be the benefit - not having to worry about whether you redefined colors just before executing a pipe?

The current (correct!) behavior is how it's worked for the last 25 years or so. If you want everything executed in the same shell, use DOS pipes.

 

[vefatica]

I wasn't thinking of '|' as a command separator.

 

[Kachupp]

I'm really sorry you feel that way, Kachupp. I fully realize the esteem in which Vince is held here, and I feel honored that he has (and takes!) the time to deal with piddling little posts like mine. After a 50-year career in IT, including plenty of nights spent at work with a sleeping bag, I know how it feels to have precious little time for other activities. And I didn't mind a bit, being on the receiving end of similar comments.

Vince, if you took offense, I apologize.

Bret Sutton

All good Bret. The condescending tones are not!
This isn't appropriate forum for further comments. Anyway I'm over it.

 

[vefatica]

You can workaround this difficulty by using in-process pipes. It also works around other things getting lost when a pipe instance of TCC momentarily removes the console's ENABLE_VIRTUAL_TERMINAL_PROCESSING mode (like tabstop settings and underlining). Much to my surprise, and contrary to the help, in-process pipes seem, almost always, to be faster than out-of-process pipes, sometimes a lot faster. Here are a couple timing comparisons. If others compare times, I'd like to hear the results.

v:\> timer (do i=1 to 100 (echo foo | ffind /k /m /t"bar"))
Timer 1 on: 18:08:48
Timer 1 off: 18:08:57  Elapsed: 0:00:09.544

v:\> timer (do i=1 to 100 (echo foo |! ffind /k /m /t"bar"))
Timer 1 on: 18:09:03
Timer 1 off: 18:09:08  Elapsed: 0:00:04.675

v:\> timer (do i=1 to 100 (echo foo | findstr bar))
Timer 1 on: 18:09:35
Timer 1 off: 18:09:42  Elapsed: 0:00:06.422

v:\> timer (do i=1 to 100 (echo foo |! findstr bar))
Timer 1 on: 18:09:47
Timer 1 off: 18:09:52  Elapsed: 0:00:05.200

Here's a pic of it working where it failed with a normal pipe..

 

[Joe Caverly]

e:\utils>timer (do i=1 to 100 (echo foo | ffind /k /m /t"bar"))
Timer 1 on: 19:58:20
Timer 1 off: 19:58:49  Elapsed: 0:00:29.367

e:\utils>timer (do i=1 to 100 (echo foo |! ffind /k /m /t"bar"))
Timer 1 on: 19:59:25
Timer 1 off: 19:59:29  Elapsed: 0:00:04.186

e:\utils>timer (do i=1 to 100 (echo foo | findstr bar))
Timer 1 on: 19:59:42
Timer 1 off: 19:59:50  Elapsed: 0:00:08.108

e:\utils>timer (do i=1 to 100 (echo foo |! findstr bar))
Timer 1 on: 20:00:02
Timer 1 off: 20:00:10  Elapsed: 0:00:08.077

Joe

     _x64: 1
   _admin: 1
_elevated: 1

TCC  28.02.15 x64   Windows 10 [Version 10.0.19043.1288]

 

[vefatica]

That first one is outrageous, Joe Caverly. Did you try it a second time?

And what the heck do you do with 128 GB RAM?

 

[Kachupp]

 

[Joe Caverly]

That first one is outrageous, Joe Caverly. Did you try it a second time?

And what the heck do you do with 128 GB RAM?

Hi @vefatica,
I just re-ran them;

e:\utils>timer (do i=1 to 100 (echo foo | ffind /k /m /t"bar"))
Timer 1 on:  8:02:39
Timer 1 off:  8:03:11  Elapsed: 0:00:31.724

e:\utils>timer (do i=1 to 100 (echo foo |! ffind /k /m /t"bar"))
Timer 1 on:  8:05:42
Timer 1 off:  8:05:47  Elapsed: 0:00:04.524

e:\utils>timer (do i=1 to 100 (echo foo | findstr bar))
Timer 1 on:  8:05:57
Timer 1 off:  8:06:05  Elapsed: 0:00:08.325

e:\utils>timer (do i=1 to 100 (echo foo |! findstr bar))
Timer 1 on:  8:06:15
Timer 1 off:  8:06:24  Elapsed: 0:00:08.498

As for the 128 GB RAM, I'm using it to explore the MilkyWay, for RAMDisks, for Virtual Machines, and for SandBoxes.

Joe

 

[vefatica]

I think that first test is the only one of the four that starts new TCCs. It's very slow (compared to here). I'll bet you're doing a lot in TCSTART.

 

[Joe Caverly]

I think that first test is the only one of the four that starts new TCCs. It's very slow (compared to here). I'll bet you're doing a lot in TCSTART.

I am indeed doing a lot in TCSTART.

When I start TCC.EXE with the /i option;

c:\program files\jpsoft\tcmd28>tcc.exe /i

TCC  28.02.15 x64   Windows 10 [Version 10.0.19043.1288]
Copyright 2021 JP Software Inc.  All Rights Reserved
Registered to DESKTOP-H2JFFTF

c:\program files\jpsoft\tcmd28>@timer (do i=1 to 100 (echo foo | ffind /k /m /t"bar"))
Timer 1 on: 11:19:01
Timer 1 off: 11:19:45  Elapsed: 0:00:43.229

c:\program files\jpsoft\tcmd28>@timer (do i=1 to 100 (echo foo | ffind /k /m /t"bar"))
Timer 1 on: 11:21:02
Timer 1 off: 11:21:46  Elapsed: 0:00:44.049

...TCSTART.BTM is not loaded, and it takes longer?

With TCSTART.BTM;

c:\program files\jpsoft\tcmd28>tcc.exe /i

TCC  28.02.15 x64   Windows 10 [Version 10.0.19043.1288]
Copyright 2021 JP Software Inc.  All Rights Reserved
Registered to DESKTOP-H2JFFTF

c:\program files\jpsoft\tcmd28>@exit

c:\program files\jpsoft\tcmd28>timer (do i=1 to 100 (echo foo | ffind /k /m /t"bar"))
Timer 1 on: 11:25:26
Timer 1 off: 11:26:01  Elapsed: 0:00:34.705

...it's faster?

Note well, that the preceeding was run from TCC.EXE inside TCMD.EXE

When I run in a stand alone TCC.EXE window, results are similar, if not the same.

Joe