Welcome!

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

SignUp Now!

tee command cancels colors

May
62
1
Code:
[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]
colortee.jpg


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

1635383773856.png


So does this.

1635383927413.png
 
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.
 
It's different at the command line. There, it seems that any pipe cancels the colors.

1635385057441.png
 
Interesting. These two command sets produce different results:
Code:
color bri yel on gre
echo foo | sort /o trash & echo foo
Code:
color bri yel on gre
echo foo | sort /o trash
echo foo
The first one changes the output color; the second does not.
 
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
 
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
 
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.
 
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.
 
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:

Code:
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.
 
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:

Code:
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.
 
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.
 
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.

Code:
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..

1635891814271.png
 
Code:
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
Code:
     _x64: 1
   _admin: 1
_elevated: 1

TCC  28.02.15 x64   Windows 10 [Version 10.0.19043.1288]

1635897891506.png
 
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?
 
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;
Code:
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
 
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 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;
Code:
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;
Code:
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
 

Similar threads

Back
Top