Why does property blockedXpath : "#\:r48e\: > span" not compile?

Why does

property blockedXpath : "#\:r48e\: > span"

not compile?

It fails on the first colon in the string. I have tried deleting the double quotes and entering them again, as well as the colon itself, to no avail.

Sometimes with xPaths and RegExa you need to double escape with “\:” “\b” and “\\”

Hah and when I typed it here without quotes

you need two

\\: \\b

As the above post escaped as the compiler
Would see and use it

Why? The string is within quotes. Does AS really evaluate strings? Isn’t that a security problem?

Because certain “functions” like XML and RegEx URLs. There reserved characters, if you want to use those caractera as literal you need to escape it encode them. And in some the single backslash is used in combination with a character. Like in RegEx. Single Backslash d. For digit. \d

But is Somecases JavaScriptt, AppleScript, Objective-C you then need to escape the single backslash with another single backslash.

So the string you provide would be
double backslash d

I can’t even type that here because it will get
Posted as a single backslash d

Anyhow why don’t you try it before you start arguing about why it should or shouldn’t work.
Many people when the give you answers have already gone thru what your running into and know how to execute it correctly.

1 Like


In addition to the detailed reply from @technomorph:

Yes, that’s the expected behavior in AppleScript. To test it, you can just create an empty AppleScript, paste "#\:r48e\: > span" and try to compile - you’ll get the same errors.

For AppleScript, colon is not a character that can be escaped because it doesn’t have any special role in an AppleScript string (unlike, for example, r). Therefore, you also need to escape the backslash itself to indicate that the backslash is a string literal, not an escape symbol for the AppleScript string.

Does AS really evaluate strings? Isn’t that a security problem?

Frankly, I’m not exactly sure what that means. That’s how AppleScript always behaved.

I was curious what lagr wants the string to be. If a single backslash before the colon then:

set theString to "#\\:r48e\\: > span"
display dialog theString

And, if the backslashes are not desired at all then:

set theString to "#:r48e: > span"
display dialog theString

Whatever the case, as leo_r pointed out, a backslash has a special meaning in text, and a single backslash can only precede specified characters, which include a backslash (to return a literal backslash), a double-quote (to return a literal double-quote), t, (a tab), r (a return), and n (a newline). That’s why placing a backslash before a colon causes an error.

Perhaps lagr will put the string to some particular use and needs something different from the above?

1 Like

If it’s XML the issue is the >

Read the link I posted above