WAD Escaping changes case to lower?

[vefatica]

The last one below is a little surprising.

v:\> echo %@ascii[a]
97

v:\> echo %@ascii[^a]
97

v:\> echo %@ascii[A]
65

v:\> echo %@ascii[^A]
97

 

[Charles Dye]

Very surprising; the value should be 1.

No, wait, you wrote "escaping"....

 

[vefatica]

Very surprising; the value should be 1.

No, wait, you wrote "escaping"....

Huh?

Also

v:\> echo ^A
a

 

[rconn]

WAD. And it always has.

But since there's no reason to do this, it doesn't seem like much of a "bug".

 

[vefatica]

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]

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.

 

[vefatica]

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]

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.

 

[vefatica]

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.

 

[rconn]

CMD does it right.

A surprising assertion, given that CMD doesn't support escape characters.

D:\TakeCommand17\tcc>ver

Microsoft Windows [Version 6.1.7601]

D:\TakeCommand17\tcc>echo ^S
S

D:\TakeCommand17\tcc>echo ^s
s

 

[vefatica]

But it does support escaping characters.

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]

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.)

 

[vefatica]

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?