Escape Character Hassles

OK. What’s up with escaping the AS escape character? Why does this happen:

set theString to “A” & “\”
returns “A\”

but

set theString to “A” & "" throws a compile error

How can I get "A"?

harges:

I tried this, and I get "A"

See below:


set a to "A" & "\\"
display dialog a

Are you still having this problem?

Interesting.

The result in a dialog is "A" but the result of a return command is “A\”

Why would that be? I was using “return theString” to check the output but it looks like the output is different there than if I used it in a dialog. What I was trying to do was to concatenate an address for a shell script cUrl call, and I can’t remember exactly now but I think that was including the extra \ in the address.

for do shell script commands don’t try to escape commands yourself but use quoted form instead

set theString to "the man said: \"Good evening\"'" 
do shell script "echo " & theString --result: error
do shell script "echo " & quoted form of theString --result: "the man said: \"Good evening\"'"

Well applescript (like any other programming language) has escape characters. Generally a \ is a escape character to tell the environment that the next character is a special character. A string is surrounded by " would not be possible to have an " inside the string. With an escape character it can because you tell the interpreter that the next character is a special character. In applescript a " says that there is a " in the string and not a string terminator. But with an escape character feature gives also another problem to have an escape character handled as normal character. so the basic rule for any kind of string in any kind of environment is that an escaped escape character must be handled as a normal character (also used in CSV for example).

To come back to your answer is that as long as you’re inside applescript you would see a \ as \ and setting a \ needs a \. So when writing \ with open for access to a file would show \ in text edit.

Got it. Thanks. That makes sense. Results returned within the environment will be different that those sent as strings outside it as in a dialog.

Thanks for the “quoted form of” syntax. That’s exactly what I needed in this situation.