WAD Escaping changes case to lower?

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#5
But the help says: "If you follow the escape character with any other character, the escape character is removed and the second character is copied directly into the command line.". And that's how it should work.

I have an idea (a guess) why this happens (code-wise) and if I'm correct, it'd be really easy to fix.
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,376
39
Albuquerque, NM
prospero.unm.edu
#6
I think you're tripping over the feature which uses escaped letters to represent various troublesome characters -- ^Q for a double quote, ^C for a comma, ^K for a strong quote, and so on. Presumably the parser lowercases the letter before checking for these special combos. As it happens, ^A has no special meaning, so the (now lowercased) letter is not replaced with any symbol.
 
#7
I think you're tripping over the feature which uses escaped letters to represent various troublesome characters -- ^Q for a double quote, ^C for a comma, ^K for a strong quote, and so on. Presumably the parser lowercases the letter before checking for these special combos. As it happens, ^A has no special meaning, so the (now lowercased) letter is not replaced with any symbol.
I figured (a little late) that you were talking about a typical way of writing control characters, of which TCC is completely oblivious. The special escape sequences in TCC don't match perfectly with them ... ^q ... ^k ... ^s ...
 

rconn

Administrator
Staff member
May 14, 2008
10,096
85
#8
But the help says: "If you follow the escape character with any other character, the escape character is removed and the second character is copied directly into the command line.". And that's how it should work.
You're operating under the misconception that your aliases / batch files will always know that (1) the character following an escape is a valid escape character, or (2) the character following an escape is not a valid escape character. Neither assumption is correct.

There is no reason to escape non-escape characters, even if you did know what they are (and provided you had magical foreknowledge that new valid escape characters will never, ever be added).

If you have a valid reason to escape non-escape characters, it would be more useful for you to post an example of that rather than a useless oversimplification.
 
#9
No, I don't think about it that deeply. The way the help describes it is pretty widespread and uniform behavior of escaping. What's the big aversion to making it work as folks would expect (and as the help specifies)? Whether or not there's any reason to do it, TCC handles it. Changing the case is ... um ... just plain goofy. CMD does it right.
 
#11
But it does support escaping characters.
Code:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\vefatica> echo ^>
>

C:\Users\vefatica> echo ^^
^

C:\Users\vefatica> echo ^%
%

C:\Users\vefatica> echo ^A
A

C:\Users\vefatica> echo ^a
a
So you must test for special ones. What's the big deal? Instead of changing the case and looking for (say) 's' (space), don't change the case and look for 's' or 'S' ... probably a few more "case" statements in a "switch" (or something like that). However it's done, I'd bet you could have changed the behavior in less time than you've devoted to this thread.
 

rconn

Administrator
Staff member
May 14, 2008
10,096
85
#12
My aversion is because you're trying to lock me into never, ever allowing any new escaped characters. I would rather simply remove all of the special escape character processing; then TCC would be 100% compatible with CMD's (non) escape character processing. Is that a satisfactory solution for you?

What's your obsession with useless syntax? (And I bet you've spent 10**4 more time complaining about something you've never used and never will use than you would, umm, never use it.)
 
#13
My aversion is because you're trying to lock me into never, ever allowing any new escaped characters. I would rather simply remove all of the special escape character processing; then TCC would be 100% compatible with CMD's (non) escape character processing. Is that a satisfactory solution for you?

What's your obsession with useless syntax? (And I bet you've spent 10**4 more time complaining about something you've never used and never will use than you would, umm, never use it.)
First paragraph: Huh?
Second paragraph: TCC has to do something when the user says "ECHO ^A" however silly that may be. It doesn't do what the help says and what I (most folks?) would expect to do. And yes, I point out a variety of things. I've been doing it just for fun for ... how long ... 15 ... 20 years. And it has been satisfying. I figure my net contribution to the products, however small, has been positive.
Don't you think enough's been said?