ANSI Prompt messes up list output.

[FreezerBurnt]

Seeing other post on ANSI colours reminded me that I have a problem with them as well.

Using:
TCC 27.00.18 x64 Windows 10 [Version 10.0.19042.746]

And starting it from the installed link (Regular old Windows console).

If the prompt is set to:
prompt `$e[1;36m$p$g$e[0;m`

My old TCC/LE worked fine, but with version 27, the prompt itself works fine, but output of "list" is completely blank. It's there, just the colors are black on black or something.

Setting the prompt to "prompt $e[1;36m$p$g$e[0;37;40m" seems to "fix" it, but...why?

Thoughts?

 

[vefatica]

Try changing "$e[0;m" to "$e[0m"

 

[FreezerBurnt]

No change.

 

[vefatica]

I recall that, with the new-fangled Windows console, messing with the properties could corrupt things. Try this:

regdir /v /d hkcu\console | findstr ScreenColors

Does it show any zeros?

 

[FreezerBurnt]

Nope.

d:\apps\tcc64>regdir /v /d hkcu\console | findstr ScreenColors
  ScreenColors : REG_DWORD : 7
    ScreenColors : REG_DWORD : 86
    ScreenColors : REG_DWORD : 86

I should point out that this doesn't happen in Microsoft Terminal. Only in the regular old console.

 

[FreezerBurnt]

Heh heh. Wrong issue.

 

[vefatica]

Heh heh. Wrong issue.

I was wondering why it didn't show up!

 

[FreezerBurnt]

I think it might be worth pointing out that list seems to use whatever the prompt left the ANSI codes at. So setting the prompt to:

prompt $e[1;36m$p$g$e[0;37;40m

Make the prompt look like:

And list will use those colours:

Never using ANSI at all - in a prompt or anywhere else, results in "normal" behaviour.

Setting the prompt to "$e[0m$p$g" results in the black on black list behaviour.

My guess is that this would SEEM to be a "list" issue. Setting a SPECIFIC ANSI colour scheme works, but if it just gets reset to defaults with "$e[0m", list displays black on black. So, at least to the "list" command, never setting any ANSI codes (no ANSI prompt or startup colours) is somehow different than the settings after "$e[0m".

 

[rconn]

LIST is obsolete and deprecated, so if there are incompatibilities introduced by new Windows 10 builds, LIST will not be "fixed".

That said, two things:

1) LIST determines its colors by getting the attribute at the current cursor position, using the ReadConsoleOutputAttribute API. This will not work as you want when using ANSI, as the attribute that will be written by the Windows ANSI code is not the default console attribute.
2) You can define the colors you want LIST to use with the ListColor directive in TCMD.INI.

 

[Joe Caverly]

Another option is to alias the list command and use an external utility.

I'm still using Vernon Buerg's LIST.COM with TCC;

e:\utils>alias list
msdos.exe e:\dosbox\utils\list.com  %@sfn[%1]

Joe

     _x64: 1
   _admin: 1
_elevated: 1

TCC  27.00.18 x64   Windows 10 [Version 10.0.19042.746]

 

[mfarah]

LIST is obsolete and deprecated, so if there are incompatibilities introduced by new Windows 10 builds, LIST will not be "fixed".

That said, two things:

1) LIST determines its colors by getting the attribute at the current cursor position, using the ReadConsoleOutputAttribute API. This will not work as you want when using ANSI, as the attribute that will be written by the Windows ANSI code is not the default console attribute.
2) You can define the colors you want LIST to use with the ListColor directive in TCMD.INI.

It seems to be "ListColors" (ListColor yielded an "invalid item name" error). I tested it with "White on Black" but the problem kept showing up; OTOH, "Green on Black", "cyan on red", "white on yellow", "bright white on black" (etc.), worked fine. Perhaps the problem manifests itself because white on black happens to be the default?

BTW, a similar problem affects the SELECT command (which I use all the time); although it's mitigated by my... gaudy... COLORDIR choices, it's annoying to see "empty" lines where the file name is only seen when the cursor bar is over it:

In this example, ".ico" files don't have a color, so "bandera.ico" can't be seen between "apple-touch-icon.png" and "calendario.html". The big black segment is due to the presence of ".inc" and ".php" files.

 

[rconn]

Use SelectColors.

 

[mfarah]

The SelectColors directive works, indeed, in the same fashion, down to getting the "black on black" text when the directive is set to "SelectColors=white on black". Making the last ANSI sequence in the prompt to be "$e[0;37;40m", as OP did, wades around the issue.

 

[vefatica]

FreezerBurnt, do you have these set (OPTION\Windows tab)? I can reproducr the LIST problem when I set them all to (Default). MFarah, maybe they have something to do with SELECT also.

 

[mfarah]

This is how I had 'em:

Changing the "Output:" colors to regular white on (default) [which was then magically converted to black] solved the issue.




(perhaps it's simply that "(default)" is read as the wrong "default" somewhere?)

 

[FreezerBurnt]

Just trying to catch up here. My colours are literally the default:

 

[FreezerBurnt]

LIST is obsolete and deprecated, so if there are incompatibilities introduced by new Windows 10 builds, LIST will not be "fixed".

Why is list deprecated? It's one of the things I love about TCC, no external application to have a decent look at files (and in hex too).

 

[FreezerBurnt]

Just looking into some colour settings, I have found that (using the $e[0m on my prompt - so I would normally get the black on black):

select will use:
SelectColors if they are set
StdColors, if SelectColors isn't set
Black on Black if neither are set

list will use:
StdColors if they are set
Black on Black if it's not set (ignores SelectColors)

Weird.

 

[David Marcus]

Supposedly VIEW replaces LIST, but I never use VIEW, and I use LIST a lot. If I wanted to open a new app to look at a file, I'd just use my text editor.

 

[Joe Caverly]

Supposedly VIEW replaces LIST, but I never use VIEW, and I use LIST a lot. If I wanted to open a new app to look at a file, I'd just use my text editor.

I am pro-list also, but after (begrudgingly) having used VIEW, I use it quite often now, mainly for the greenbar, and the fact that one can customize the keyboard shortcuts to emulate the LIST command.

It also has hex view.

I was so used to the DOS LIST.COM command, and the keyboard shortcuts that it uses, which is why I still use it.

I have managed to get the keyboard shortcuts for VIEW to emulate (the majority of) the DOS LIST.COM keyboard shortcuts.

Give VIEW an honest try for a while, and see how it works for you.

Joe

 

[David Marcus]

The reason I use LIST is that it displays in the existing window, so I don't have to move windows around if I am quickly looking at a file. "VIEW /w" tries to do this, but if the window loses focus, it becomes invisible; I want to be able to see it. I also like that LIST leaves what you were seeing in the window when you exit it so you can copy.

 

[Joe Caverly]

The reason I use LIST is that it displays in the existing window, so I don't have to move windows around if I am quickly looking at a file. "VIEW /w" tries to do this, but if the window loses focus, it becomes invisible; I want to be able to see it. I also like that LIST leaves what you were seeing in the window when you exit it so you can copy.

Fair enough.

What about the LIST.EXE that comes with the Windows 10 Kits;

e:\windows kits\10\debuggers\x64>dir list.exe

 Volume in drive E is New Volume   Serial number is 2c1e:6e61
 Directory of  E:\Windows Kits\10\Debuggers\x64\list.exe

2019-12-06  21:09          71,624  list.exe
              71,624 bytes in 1 file and 0 dirs    73,728 bytes allocated

Yes, it is an external program, yes you have to install the Windows SDK, but it does display in the existing window.

Joe

 

[vefatica]

Joe, do you know the expected location and syntax for TOOLS.INI?

 

[vefatica]

Joe, do you know the expected location and syntax for TOOLS.INI?

And how do you get the help screen?

 

[Joe Caverly]

Hey @vefatica when LIST.EXE is active, press the F1 key.

I've never much used the TOOLS.INI file, as the defaults always worked for me, so not sure where the expected location is.

Note also LIST.EXE /? which returns;

e:\windows kits\10\debuggers\x64>list.exe /?
list [-s:string] [-g:line#] filename, ...

Something in the back of my mind says that the location of TOOLS.INI was determined by an environment variable that one set to point to the folder in which TOOLS.INI is located, but I don't remember the name of the environment variable, and I also may not be remembering this correctly.

Joe

 

[vefatica]

There's WSL's less. But using it like this fails miserably. Too bad; less is pretty nice.

 type file | wsl less

 

[Joe Caverly]

Works okay here;

...using;

type test.txt | wsl less

Joe

 

[Joe Caverly]

From PowerShell 7 in TCMD;

...gives me...

But in PowerShell 5.1 in TCMD;

...gives me...

Joe

 

[vefatica]

Do any keys (up, down, q(uit)) work in less with PS7? None at all work with TCC/CMD/PS5 in TCMD or WT. The only way out is Ctrl-C.

 

[Joe Caverly]

Do any keys (up, down, q(uit)) work in less with PS7? None at all work with TCC/CMD/PS5 in TCMD or WT. The only way out is Ctrl-C.

I have tried wsl less file.txt in all shells in all environments.

All the keys for WSL LESS work for me in any environment.

Ditto for Windows Terminal, using TCC/CMD/PS5/PS7.

Can you maneuver through a man file? That is, wsl man less

Joe