WAD Bug in @LEN Function?

[Jay Sage]

I'm using the @LEN function to get the length of a string. However, when that string contains special escaped characters, such as ^s, the length is wrong. Both the caret and the s are counted as separate characters. The same thing happens with strings enclosed by back-quotes. The back-quote characters are counted.

TCC(30.00.22): C:\>echo %@len[1234]
4

TCC(30.00.22): C:\>echo %@len[^s1234^s]
8

TCC(30.00.22): C:\>echo %@len[`12%34`]
7

TCC(30.00.22): C:\>echo `12%34`
12%34

 

[rconn]

WAD (for the last 30+ years).

Escape character processing is done after variable expansion. If it was done prior to variable expansion, you could never put an escape character in a variable.

 

[Jay Sage]

Can you suggest a way around this?

If it were being used in a script, I could do the following:

TCC(30.00.22): C:\>set junk=`12 34` & echo %@len[%junk]
5

TCC(30.00.22): C:\>set junk=^s12 34^s & echo %@len[%junk]
7

However, I'm using %@len in a user-defined function so that a generated string will have the right length. That's how I noticed the problem. When I put leading spaces on a string using ^s, the resulting string came out too short.

 

[rconn]

A few functions (like @CLIPW / @CLIPWN will unescape a string before writing it (because they're not returning a resulting string for something else to process).

But your unknown rogue background processes that are rewriting the clipboard would make this unreliable ...

A few other functions like @REPLACE, @REREPLACE also unescape the strings. And then there's always @EXECSTR, though it's klunky & slow.

 

[Jay Sage]

I couldn't figure out how to use the CLIP or REPLACE functions. My workaround was to implement what I suggested would work in a batch script. I added

@exec[@set var3$=%3$]

Then, everywhere that I had %@len[%3$], I used %@len[%var3$]. That worked.

Fortunately, speed is not an issue these days for something like this.