Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD FORMAT Function with Escape Characters Miscalculates String Length

Jay Sage

Jay Sage

Jun
1,092
48
Rex, I'm posting this here in case you missed it in the longer discussion in another post.

When a string containing the escape character ^s is passed to the FORMAT function, the escape character is displayed as a space, but the length calculation thinks it is two characters long. That's probably because the LEN function does not expand the escape character.
Here's a demonstration.

Code: 
C:]echo !%@format[010,one two]!
!000one two!

C:]echo !%@format[010,one^stwo]!
!00one two!

C:]echo %@len[^s]
2

A similar problem occurs with ^t.
 
@FORMAT doesn't know that ECHO is going to shorten the string. What's the solution?
 
Charles Dye said:
... A function to expand the escapes before passing the string on to @FORMAT ?
Click to expand...

Already had one.

Code: 
v:\> echo !%@format[010,%@escape[one^stwo]]!
!000one two!

Funny ... last night I axed it in a fit of plugin pruning. I had to put it back for this thread. It's all of four lines of code (simple wrapper for EscapeLine()). Charles, do you have a plugin where it would fit in nicely?
 
vefatica said:
Already had one.

Code: 
v:\> echo !%@format[010,%@escape[one^stwo]]!
!000one two!

Funny ... last night I axed it in a fit of plugin pruning. I had to put it back for this thread. It's all of four lines of code (simple wrapper for EscapeLine()). Charles, do you have a plugin where it would fit in nicely?
Click to expand...

I have one myself, thanks.
 
Jay Sage said:
Rex, I'm posting this here in case you missed it in the longer discussion in another post.

When a string containing the escape character ^s is passed to the FORMAT function, the escape character is displayed as a space, but the length calculation thinks it is two characters long. That's probably because the LEN function does not expand the escape character.
Here's a demonstration.

Code: 
C:]echo !%@format[010,one two]!
!000one two!

C:]echo !%@format[010,one^stwo]!
!00one two!

C:]echo %@len[^s]
2

A similar problem occurs with ^t.
Click to expand...

@LEN does not try to interpret escape sequences. This would be a breaking change, so it's not going to be implemented in @LEN.

The escape processing has to be handled individually for each variable function, so it only gets added to those that either require it or had enough users request it (long ago, before it became canon).
 
rconn said:
@LEN does not try to interpret escape sequences. This would be a breaking change, so it's not going to be implemented in @LEN.
Click to expand...

What about @FORMAT? It is probably used most often for displaying output, in which case ^s will be converted to a space. The internal length calculation would not have to be the same as with the @LEN function.

Of course, I imagine that the result of ^t is unpredictable, since the spacing will depend on where the string started, which @FORMAT cannot know.
 
Jay Sage said:
What about @FORMAT? It is probably used most often for displaying output, in which case ^s will be converted to a space. The internal length calculation would not have to be the same as with the @LEN function.
Click to expand...

If you can guarantee me that nobody has ever used a ^ in @FORMAT, then it won't be a breaking change. Otherwise ...

The problem is that you want the DWIM parser, where sometimes it processes escapes before variable expansion (which means no escapes would be allowed in a variable value -- and don't even think about ever nesting variables), sometimes after variable expansion, sometimes just before passing to a command (but not DO or FOR or IFF or SWITCH) and sometimes just before a command displays output.

Oh, and ^ is a valid filename character, so anybody that has used that in a filename is out of luck if escapes are processed before variable expansion.
 
You must log in or register to reply here.
Back
Top