Appendfile Concatenation fails in Action debugger

Can’t figure this one out. I have to adjust the registry in order to add a line to remove the native policy for the 132 character limit before automatic carriage return on sent mail.

In order to do this, I have to modify the HKEY_USERS registry as my HKEY_CURRENT_USER is locked from modification.

The problem is that the concatenation relevance works great in the debugger -
q: concatenation “0d%0a” of ((“reg.exe ADD %22” & it & “%22” & " /v WrapLines /t REG_DWORD /d 0 /f") of pathnames of key “Software\Microsoft\Office\14.0\Common\MailSettings” of key whose (name of it contains regex “(S-1-5-21)-\d{10}-\d{10}-\d{7}-\d{6}$”) of key “HKEY_USERS” of registry)

A: reg.exe ADD “HKEY_USERS\S-1-5-21-1355233316-1600531628-3476437-166515\Software\Microsoft\Office\14.0\Common\MailSettings” /v WrapLines /t REG_DWORD /d 0 /f

T: 1.005 ms

However, when I try to run the same relevance in the action it gives me an invalid relevance clause error -

As seen in my action window -

appendfile {concatenation “0d%0a” of ((“reg.exe ADD %22” &
it & “%22” & " /v WrapLines /t REG_DWORD /d 0 /f") of pathnames of key “Software
\Microsoft\Office\14.0\Common\MailSettings” of key whose (name of it
contains regex “(S-1-5-21)-\d{10}-\d{10}-\d{7}-\d{6}$”) of key
"HKEY_USERS" of registry) }

evaluation error - Invalid relevance clause - Line 5

Anyone able to see my mistake here?

Thanks.

You are seeing that error message because you’re using {} multiple times and the action script can’t understand which should be used to see where the “relevance” code is, and which to ignore as part of the registry key/regex matches.

So, I believe escaping the inner curly brackets with an extra closing curly bracket should signal to the relevance interpreter to parse the outer pair {} around the code (and treat it as relevance) and ignore the inner {}'s as part of the regex string.

appendfile {concatenation "0d%0a" of (("reg.exe ADD %22" & 
it & "%22" & " /v WrapLines /t REG_DWORD /d 0 /f") of pathnames of key "Software 
\Microsoft\Office\14.0\Common\MailSettings" of key whose (name of it
contains regex "(S-1-5-21)-\d{10}}-\d{10}}-\d{7}}-\d{6}}$") of key 
"HKEY_USERS\" of registry) }
2 Likes

You need to escape your {. The Action Script uses them to evaluate relevance.

appendfile {concatenation "0d%0a" of (("reg.exe ADD %22" & it & "%22" & " /v WrapLines /t REG_DWORD /d 0 /f") of pathnames of key "Software\Microsoft\Office\14.0\Common\MailSettings" of key whose (name of it contains regex "(S-1-5-21)-\d{{10}-\d{{10}-\d{{7}-\d{{6}$") of key "HKEY_USERS\" of registry) }

Try that.

jmaple - I think you may be confusing the issue of when to use left { and right }.

You prefix {} with a left bracket { when you have an action script line that should NOT be treated as relevance. You use the ending right bracket } any time you use {} inside some relevance code.

By default, the {} signals to action script to treat the inner characters as relevance code.

So when the code says:

appendfile {*this is the relevance code blah blah blah*}

…then anything inside that set of {} that is going to also use {}'s will need to have a following } to tell the relevance engine to ignore those {}'s and pass them as part of a string.

You only use a prefix { in the case where you have an action script line that has {}'s and you need to tell the action script interpreter NOT to hand it over to the relevance interpreter.

Hmm… I was under the impression the escape for this was at the front of the statement? That’s how I’ve been doing it and haven’t seen a problem.

I do know that you can escape {} with an extra opening or closing bracket depending on the circumstances, but I never really thought about which would need escaped in which cases. I think @jwilkinson is right about this.

I think you can also percent encode the {} characters within relevance statements, and I think that is often what I had done instead.

You do only need to escape the leading ‘{’

Often people do percent encode both {} but its only the leading one that matters as it puts the engine into relevance substitution mode

1 Like

Gah!..can’t believe I overlooked that! Thanks for the assist! It worked fine in the debugger…lets see how it handles a real-time test. Don’t know if it will handle more than one profile yet.

Oh to correct myself (as I didn’t even notice it) your internal } will “close off” the original so yea you need to escape that as well.

appendfile {{ this is not relevance { "this is relevance " & "}}" & " and still relevance" } and not relevance }

should produce

{ this is not relevance this is relevance } and still relevance and not relevance }
2 Likes