How to? TEE question

[Claire_CJS]

So, I have a question about tee. Basically: "why emoji die?!?!"

The top line is the before,
the bottom line is the after:

%LAST_WHISPER_COMMAND% |:u8 copy-move-post whisper
%LAST_WHISPER_COMMAND% |:u8 copy-move-post whisper |&:u8 tee /a "%OUR_LOGFILE%"

Before: Emoji & ANSI go to screen just fine.
After: Emoji & ANSI go to logfile just fine, but not to screen.

Related, but not the main issue:

also lose the colorcycling effect copy-move-post adds, so the screen output is somehow processed in a way which i would very much like to prohibit. I instead get a frozen moment of the currently-color-cycled color that is only updated when a new line of input comes in, vs continuously updating}
{some of my output is in different colors, some is meant to be color-cycled

Even less related:

If TCC's tee can't do what i want, is there a version of tee that does?

Why can't tee play with others? I must be doing something wrong.

 

[Claire_CJS]

The cygwin tee.exe sends the ansi-color-cycling to the screen, but TCC's doesn't. Interesting. Guess i'll use theirs.

 

[vefatica]

The cygwin tee.exe sends the ansi-color-cycling to the screen, but TCC's doesn't. Interesting. Guess i'll use theirs.

How so?

 

[Claire_CJS]

How so?

View attachment 4637

Color cycling, not changing. Changes go through just fine.

I'm sure it's related to why emoji don't go through either.

Both those work with cygwin's tee but not TCC's, which is fine.

I pipe some things through a postprocessor that uses ansi codes (they probably represent 90% of the output) to change the definition of the default/white color so that it cycles through all the colors of the rainbow.

I wouldn't want that in the output file , but i would want all the color changes in the output file (most lines are a randomly generated color).

Both versions of tee "know" that this extra color-changing ansi is nothing anybody would want in the final file. I don't know how.

But only cygwin's updates the screen constantly (instead of when a newline is encountered), which i think is the key to why the color cycling works. With TCC's version, each new line changes the default color to the currently cycled color-cycle-color of that moment.

Maybe it's not the same reason emoji don't make it through , maybe it is.

If you want to see that in action it just get:
clairecjs_bat/BAT-and-UTIL-files/copy-move-post.py at main · ClaireCJS/clairecjs_bat and the library file clairecjs_utils/claire_console.py at main · ClaireCJS/clairecjs_utils

then pipe the output of a copy command through it

[ansi glitches can be fixed by piping to cat.exe, though certain versions are much much slower than others and i timed them all and renamed the fastest as fast_cat and typically use that one for this ]

 

[vefatica]

Maybe I spoke too soon. What is "ansi-color-cycling"? ... something other than just ANSI colors?

 

[Claire_CJS]

I could always post a video o

Maybe I spoke too soon. What is "ansi-color-cycling"? ... something other than just ANSI colors?

Redefining the ansi color "1" / default / white to a specific RGB value at approximately 0.06 intervals (though my implementation has adaptive throttling so it doesn't clog up CPU during tight loops, since i call it within python loops to quell hang-anxiety as well, that's what i originally designed it for... a way of seeing a process is alive without generating any "official" stdout)

 

[vefatica]

You've lost me.

 

[Claire_CJS]

Basically:

TCC's TEE only updates the screen when it receives a newline.
Other one(s) do not.

TCC's TEE doesn't correctly send emoji to the screen.
Others do.

 

[Claire_CJS]

You've lost me.

Here's a sample. The piped copy command at the end color-cycles all the backslashes and arrows on the screen. Very different from a color change. Their color is technically the same color all the time: The default color. It's simply that the RGB value of the default color is being rapidly changed in the background:

[ I just wish there as away to allow the /G percentage to bleed through properly when doing this. I had to lose that. ]

 

[vefatica]

I don't know enough or care enough about these things to continue.

 

[vefatica]

Tee can get it right.

 

[Claire_CJS]

Tee can get it right.

View attachment 4639

You're 100% right.

 

[Charles Dye]

I guessing that you want to send UTF-8 one way and UTF-16 the other? I don't believe TCC's TEE can do that.

 

[Claire_CJS]

I guessing that you want to send UTF-8 one way and UTF-16 the other? I don't believe TCC's TEE can do that.

I guess so? Thanks for figuring out what i meant, though! :)

 

[rconn]

The TCC current output format (ANSI, UTF-8, or UTF-16) cannot be changed on an individual file/device basis with TEE.

 

[rconn]

Basically:

TCC's TEE only updates the screen when it receives a newline.
Other one(s) do not.

TCC's TEE doesn't correctly send emoji to the screen.
Others do.

Neither of those statements are correct. Can you provide an example of each that is failing for you?

 

[Claire_CJS]

Neither of those statements are correct. Can you provide an example of each that is failing for you?

Not one that someone else could run, unless you have

1) my python scripts that generate the color-cycling (not changing) output.

2) And some kind of input that isn't instant. A process that updates it's status every few seconds.

(For me, this is WhisperAP transcribing music, which only outputs a line of STDOUT every few seconds, but some form of delay and repeat would probably simulate that)

At that point you could pipe something to cygwin's TEE. The color-cycling (not-changing) instantly updaetes to the screen — you see the colors shift through the visible spectrum. The special color-redefining ansi codes are being passed through to windows terminal (or something; i don't know how it works under the hood) and the colors are cycling.

Running it through the internal TCC pipe, this does not happen. As each newline of input goes through, you get a single update, with the default color changing to the color-cycled-color-OF-THAT-INSTANT.

In other words, you only get one color change per line of STDOUT, even though it's constantly happening in the background (to the point of technically being 99% of the output).

So the character still hit the "screen" / my eyes / windows terminal / whatever, but the updates only come as each line of STDIN is fed to TCC's TEE, whereas they come instantly as each character is fed to cygwin's TEE.

One can see a demo of the color cycling by looking at (just) the backslashes [and arrows] in the copy output, near the end of this video:

When piped through things, it either works or doesn't. I've never seen this "just 1 update per newline which is a snapshot of that instant"-type behavior. I had to use cygwin's tee to be able to preserve the beautiful effect i worked so hard to add....

 

[Claire_CJS]

and just to be clear, when something is piped through my "make the colors cycle" postprocessor, there is constant output. something along the lines of 60fps of ansi color changing codes.

 

[Claire_CJS]

P.S. The resulting file output by both TEEs ends up with 100% of the ANSI codes for color changes, and 0% of the ANSI codes for color-cycling, in it.

Which is exactly what I want, and quite frankly surprised me

It seems changing colors to preset colors, and redefining the RGB value of the primary color, somehow go to different paths: Like this:

color change ANSI -> TCC TEE -> hits output file & screen realtime
color change ANSI -> 'Nix TEE -> hits output file & screen realtime
color-cycling ANSI -> 'Nix TEE -> suppressed from output file & updates screen realtime
color-cycling ANSI -> 'TCC TEE -> suppressed from output file & updates screen only when a newline is encountered (though maybe not BECAUSE of the newline)