Display of special characters in aliases.
- Thread starter vefatica
- Start date
- May
- 13,190
- 180
Look at the pics; see the change. It's a global alias (shralias), used by all TCC versions.
- May
- 13,190
- 180
Some of my older TCCs, left in states of disarray, have other fonts. But v19 and v20 both use Andale Mono (Unicode), bold 16. All my TCCs (all my consoles) use CP437.
- May
- 13,190
- 180
Is build 12 any different?
rconn
Administrator
- May
- 13,218
- 206
Staff member
Not in this regard. It had some changes in DEDUPE and some help text updates.
- May
- 13,190
- 180
Yes.
rconn
Administrator
- May
- 13,218
- 206
Staff member
You are begging for trouble here -- you're expecting unknown escape sequences to be displayed as though they weren't escape sequences. The ANSI standard says to throw away unknown escape sequences. And you're also assuming that they're not going to get pre-processed by TCC as escape sequences for the parser. Your assumption is only going to be correct as long as you (1) only do <Esc>@ (and never any other character), and (2) I don't decide at some point in the future to create a new TCC escape sequence using @.
And your fix won't work, because you're only considering <Esc>[ and <Esc>], and overlooking all of the other possible ANSI escape sequences (0x20 - 0x2F, P, X, ^, _, etc.).
And your fix won't work, because you're only considering <Esc>[ and <Esc>], and overlooking all of the other possible ANSI escape sequences (0x20 - 0x2F, P, X, ^, _, etc.).
rconn
Administrator
- May
- 13,218
- 206
Staff member
4NT and every version of TCC from v11 to v19 didn't support ANSI, they supported a small subset of ANSI (basically just the colorization). V20 supports a much fuller set.
There are a number of additional ANSI combinations that v20 supports that aren't in the documentation yet. And they don't begin with ^e[ or ^e].
No.
If you want to print non-printable characters (why??), don't use ANSI. They don't go together.
- May
- 13,190
- 180
I can't wait to see the additional combinations. I thought we had just about everything useful in a Windows console and I can't imagine what new ones might do ... trigger a reboot, maybe. Has there been much outcry for more escape sequences?
Perhaps you can suggest another keystroke alias that can be issued anywhere on the command line and will cause TCC to exit without further ado and without entering anything in the command history?
Perhaps you can suggest another keystroke alias that can be issued anywhere on the command line and will cause TCC to exit without further ado and without entering anything in the command history?
rconn
Administrator
- May
- 13,218
- 206
Staff member
How is that relevant to this topic?
- May
- 13,190
- 180
That's the alias which has displayed correctly until recently
rconn
Administrator
- May
- 13,218
- 206
Staff member
The alias still *works*, it's just not displaying the escape sequence when you enable ANSI (which thinks it's an invalid sequence and discards it). This scarcely requires you to throw everything out the window.
vefatica is right in that something has changed in v20 regarding ANSI (probably directly related to adding general ANSI support for all console windows). But I think Rex is definitely right in how it works (and how it should work) in v20. I remember playing around with ANSI sequences back in the days of MS-DOS v6 (with ANSI.SYS loaded in the CONFIG.SYS file) and with calling BBS's and using ANSI terminal emulation with almost all my BBS connections, and I remember that anytime I used an ESC character (ASCII 27) followed by a character that isn't recognized by ANSI.SYS (like when putting only an ESC character and then other text, where the following character is very likely not to be recognized as part of a valid ANSI sequence), then upon displaying it on the screen (e.g. putting it in a text file and then later doing TYPE TEXTFILE.TXT), the ESC character would be discarded, and I think the following character was discarded as well. This is always the case as far as I remember. Since Rex says that the previous versions of TCC didn't directly support ANSI except for just a subset, I'm guessing that displaying them on screen as a result of certain commands like ALIAS didn't cause them to be interpreted (if it was in one of the aliases that displayed on the screen), but they would be interpreted as a result of other commands like ECHO and TYPE that display to the screen. Now that there seems to be (more or less) nearly full ANSI support, the ANSI sequences seem to be interpreted anytime they are displayed on the screen by any command (either just in TCC or in all console apps, depending on settings), and like I say, I think this is the way it's supposed to be, which again was the way it worked back in the old DOS days. I tested the alias though, and it seems to execute properly, even though it doesn't display on the screen the way you'd expect it to. If you want to see it when displaying aliases on screen, and assuming you're loading all your aliases on startup from a file, you can always add the alias directly to the file instead of adding it at the command line (and assuming you're using "^e" instead of trying to directly enter the ESC character). Then when you display aliases on the screen, you'll actually see the "^e" in the alias instead of either the ASCII 27 character or the character not appearing at all.
