Welcome!

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

SignUp Now!

LIST multiple files - color changes after viewing the first file

  • Thread starter Thread starter MPB
  • Start date Start date
Mar
49
1
Here's an odd one. When I use something like "LIST *.txt" from TCC to view whatever files, the first one has the correct bright white on black text. Using escape or ctrl-pageup/down to move between files, the color changes to a darker/regular white on black, no longer bright white.

I noticed this a few revisions back in v36 and I think v35 was okay with this.

Just in case this is somehow related to the OS, I tried this on a couple different systems including a Windows 11 and also a Windows Server 2025 system with the same result.

In my tcstart.btm I have a line:
color bri white on black

Which might be a default? But I've been setting it that way on startup for years, just in case. So I don't know if that plays into this issue at all.

I also set my prompt in tcstart with this, using ANSI escape sequences to give me a bright cyan on black CWD with yellow brackets. :)
prompt $e[33;40;1m[$e[36;40;1m$P$e[33;40;1m]$e[37;40;1m

Again, just including that tidbit in case it has anything to do with the LIST behavior.

For what it's worth, if I set my prompt to just $p$g and also set something like "color bri yellow on black", I get the expected colors on the command prompt, and the first file I LIST will be yellow on black, but it does the same thing where moving to another file results in plain white on black from that point on. When I'm done listing files and get back to the command prompt, it's no longer yellow on black, it's just the regular white on black. LIST seems to overwrite whatever colors were set.
 
Win11 and also checked on a Server 2025. This is just TCC running in a console, not terminal. I just checked, and it does the same thing if I'm using the terminal window.
 
Fixed in the next build.

It didn't have anything to do with LIST (which has been deprecated and unchanged for years). The problem was with the ANSI parser - when a reset was sent (which is done by a CLS in LIST when switching between files) the default color was reverting to the startup color (white on black).
 
  • Like
Reactions: MPB
Don't know whether this is related (suspect it might be), but my list command is behaving strangely after moving to v36. In v35 it was fine; both are in a tcc.exe console on Windows 11. In v36, listing a normal text file does not honour the colours set in tcmd.ini, and it shows "[16;1H" type sequences at the end of most (but not all) lines, with each sequence offset to the right of the similar sequence in the line above.
 
Don't know whether this is related (suspect it might be), but my list command is behaving strangely after moving to v36. In v35 it was fine; both are in a tcc.exe console on Windows 11. In v36, listing a normal text file does not honour the colours set in tcmd.ini, and it shows "[16;1H" type sequences at the end of most (but not all) lines, with each sequence offset to the right of the similar sequence in the line above.

Do you have ANSI disabled?

Are you using ConPTY or the old-style tab windows? ConPTY will require ANSI to be enabled.
 
Ref: _CONPTY

_CONPTY returns 1 if TCC is running in a Windows pseudoconsole (ConPTY), or 0 if it isn't.

Take Command supports either the Windows 10 / 11 pseudoconsoles, or the older hidden consoles.

Ref: _CONPTY

Joe
 
So, I uninstalled and then installed the latest V36 update, but the problem persists. Can you confirm this, and let us know whether it will be worked on? Otherwise I will roll back to V35, as list (even though deprecated) is frequently used by me.
 
As a side note,
consider use the Linux less command,
or the bat command.

You can also download less and bat via winget.

I use both less (Spencer V8 regular expressions)
and bat

Ref: Less
Ref: GitHub - sharkdp/bat: A cat(1) clone with wings.

Code:
winget show jftuga.less
winget show sharkdp.bat

Review them,
and see if they are tools that would benefit your workflow.

Joe
 
Don't know whether this is related (suspect it might be), but my list command is behaving strangely after moving to v36. In v35 it was fine; both are in a tcc.exe console on Windows 11. In v36, listing a normal text file does not honour the colours set in tcmd.ini, and it shows "[16;1H" type sequences at the end of most (but not all) lines, with each sequence offset to the right of the similar sequence in the line above.

The "[16;1H" sequences (cursor position) are coming from conhost (or openconsole, depending on which one you're running), not LIST / TCC. It seems as if there is a disagreement between TCC and conhost about whether to use ANSI.

I cannot reproduce your problem with the current build (36.01.55) or with the 36.50 beta.

What do you get if you type "echo %_ansi" at the prompt? What colors are you setting in TCMD.INI?
 
"echo %_ansi" = 1

Code:
InputColors             = Bright Cyan on Black
StdColors               = White on Black
ListColors              = White on Blue
ListStatBarColors       = Black on White
ListInverseColors       = Blue on White
Code:
[ConsoleColors]
ConsoleColor00=0
ConsoleColor01=14300928
ConsoleColor02=958739
ConsoleColor03=14392877
ConsoleColor04=200
ConsoleColor05=8913032
ConsoleColor06=43218
ConsoleColor07=13421772
ConsoleColor08=7763574
ConsoleColor09=16742459
ConsoleColor10=65280
ConsoleColor11=16766293
ConsoleColor12=255
ConsoleColor13=16711935
ConsoleColor14=65535
ConsoleColor15=16777215
 
Turning off ANSI cleared up the problem (but of course it caused other issues, such as display of prompt, etc.), so you nailed the problem. This is a new installation of Windows 11, and of TC v36; previous Windows 11 had TC V35, and didn't exhibit this problem. Is there something I can do to turn on ANSI in console host? Thanks, Rex!
 
There is a Windows API call to request the console host turn on ANSI support. TCC makes that call, but apparently your system doesn't manage to turn ANSI on.

The only reason I can think of why that call would fail is if you're running in legacy console mode.

Go to your console properties (click on the icon on the left side of the caption bar). Check to see if you've got the legacy console option set.
 
The "Use legacy console" checkbox is not checked; in fact, the line below it says "The legacy console is not installed."

For now, (until trying out the next build of TC V36,) I've changed my 'list' alias from:
alias list= *list /c
to:
alias list=`setdos /a0 & *list /c %1$ & setdos /a1`
which seems to work around the issue satisfactorily.

PS. Using 'list' (without the /c) also works correctly, but then of course one doesn't get the restored screen. Just mentioning that in case it provides some clue.
 
@Joe, lest you think I have forgotten you, I did indeed check out less, which appears extremely flexible (and with a corresponding learning curve). It would most likely be able to duplicate list completely, and I may spend some time in the future to attempt to configure it that way. Now that I have an updated alias for list, though, it will likely need to wait till I have the time and inclination to do so. But thanks for the recommendations.

I'm on V36 build 55, and I see from another thread that build 66 is available, but I don't know how to get that version, as build 55 is the latest on the download page. I'm curious as to whether the newer build has overcome this issue.
 
Thanks for that. So I take it that only a select group have access to later builds. That's fine; no rush as far as I'm concerned. I'll wait patiently for the next release.
 
Back
Top