I’m having trouble with this code:
$MyString.replace("%5C","\\")
This replaces the %5C with literally two backslashes when I only want one.
When I use this code:
$MyString.replace("%5C","\")
I am left with nothing. (Presumably, because the close quote is ignored since it is escaped?)
IIRC there is no safe escape method for \, at least in Tinderbox action/export code, as it is already the escape character and the doubling method \\ works unreliably at best. Backslash-escaping single or double straight quotes can also be problematic.
My hunch is that now Tinderbox has AppleScript support this might be the best workaround, conscious that ‘just’ using a whole new coding method is not easy for many user. But, before going further down that line, could you give as a bit more context for the process. How/where is this need arising? For instance is it is imported data, it might be easier to process the backslashes before the data reaches Tinderbox, etc.
Over here, in a stamp, this works:
$MyString=$MyString.replace("%5C","\\");
Perhaps you were missing this part:
$MyString=
Thanks for the reply, Mark. I’m moving data inside the TB environment. It’s not a big deal. This could be an edge case that I can handle “manually” with an old fashioned “find/replace” once the text arrives in the new container as the “” does not frequently appear. Since I have zero familiarity with AppleScript and have no interest in learning another set of commands and protocols, I guess this is just one of the things that I have to life with.
Hi Paul. Yes, I did have the attribute assignment on the front end. I’m not sure why it worked for you and not for me.
The code works, so we need to figure out what’s gone awry in your file. Sometimes, it’s a good approach to start with a new file and just a note or two to test the code. Make sure there are only straight quotes, not curly, and no non-ASCII characters creeping in. If everything works in a small test file then copy and paste the code from there into the stamp or rule or whatever is the source of the action.
There are other ways to do this troubleshooting, which I’m sure @mwra can point out for you.
Edit: a utility like TextSoap – which is included with SetApp subscriptions as well as stand-alone – is great for finding and fixing text gremlins.
The scenario doesn’t surprise me an @PaulWalters is spot on in the answer above about testing small and working out. The issue here is that historically action code was less powerful and rock-solid escaping wasn’t a big deal. A result is some functions may not handle escaping as well as others. If you have nested/chained functions a good triage is to try each discrete function from start/inner and pass the result to an attribute to check in which part(s) the escaping passes or fails.
I hear you on the AppleScript - it is as I guessed. Still, be aware of it as a backstop option. Should it be needed there is some expertise here in the forum.
For now, I think following the testing advice above is the best way ahead.
Tip: If you want to be able to noodle around with action code in a bigger space such as a note’s $Text space without quote types being converted etc., apply the build-in ‘Code’ prototype to your TBX and than assign that to a new note (before you add any code).
Thanks Mark. I switched over to the “Code notes” paradigm 2 years ago and it has definitely changed my Tinderbox life. I use code notes to run nearly all my Tinderbox actions. And yes, I that means there are deeply nested actions that link between code notes. This is probably one explanation for my problem.
Anyway, for now, I’m living with it and using a Keyboard Maestro macro to do the final clean up as needed.
I appreciate all your help, @PaulWalters & @mwra.