Possible Ampersand escape issue in BBEdit, with AppleScript

[Sonic Purity]

Important #1: I am using an older version of BBEdit and macOS. This issue may have been fixed long ago, or might only be a problem with my older versions. It might even be an AppleScript bug wholly beyond BareBones’s control.

Important #2: I already have a successful workaround to this issue for my project. This is a “just sharing” post, in case this actually might be a BBEdit bug and not yet fixed. I discuss my workaround at the end of this post.

Configuration (same as all my recent posts):

* BBEdit 11.6.8

* macOS 10.12.6 Sierra

* AppleScript 2.5

Issue: when replacing HTML which contains &amp: using the BBEdit replace command in an AppleScript, the placeholder text being replaced is included at each occurrence of & in the replacement text, surrounded by the (desired) replacement text.

Steps To Reproduce:

1) Place the 3 files attached to this post together in any regular user folder for the current macOS user. The files are:

* Ampersand blow-up demo script.scpt

* Ampersand blow-up demo template.tmpl

* Test Chapter Titles.txt

2) Ensure BBEdit is running (or put in an activate command in the script which i omitted). No documents need to be open in BBEdit—the script will open/create them as needed.

3) Open the Ampersand blow-up demo script in Script Editor (i’m using version 2.9, or equivalent app you may prefer) and run the script.

Expected Result: the placeholder <li>[…]</li> material in the template will be removed completely, entirely replaced by the content of Test Chapter Titles.txt

Actual Result: the <li> lines for chapters 1-3 and 5-6 of my example files are correctly replaced. Chapter 4, which contains two &amp; entities, is not: the original placeholder text material is repeated entirely in each location.

I notice when reviewing the Replies section of Script Editor that each " is correctly escaped as \", but the two & s of the two &amp;s are not. Here’s a copy/paste of it from my last run:

replace "(?s)<li><a(.+)</li>" using "<li><a href=\"TestStoryC1.html\" title=\"Test Story chapter 1: Watch Out For Ampersands!\">Watch Out For Ampersands!</a></li>

<li><a href=\"TestStoryC2.html\" title=\"Test Story chapter 2: Will It Blow Up?\">Will It Blow Up?</a></li>

<li><a href=\"TestStoryC3.html\" title=\"Test Story chapter 3: Watch What Happens with an Ampersand\">Watch What Happens with an Ampersand</a></li>

<li><a href=\"TestStoryC4.html\" title=\"Test Story chapter 4: Wild &amp; Unruly\">Wild &amp; Unruly</a></li>

<li><a href=\"TestStoryC5.html\" title=\"Test Story chapter 5: Told You!\">Told You!</a></li>

<li><a href=\"TestStoryC6.html\" title=\"Test Story chapter 6: But This Might Already Be Fixed\">But This Might Already Be Fixed</a></li>

" options {search mode:grep, wrap around:true}

--> 1

My Workaround

The template file was left over from when i did manual processing. Having to find and replace all that placeholder text is unnecessary (and arguably ridiculous). I made a new template file which is identical other than all the <li>[…]</li> placeholder material has been replaced by #TOCLISTHERE#, which removes the need to use grep in that replace, hence the grep option was removed. This works properly and wholly solved my issue.

Hoping this may help, or at least provide a few moment’s entertainment,

))Sonic((

[Rich Siegel]

On 26 Oct 2021, at 21:58, Sonic Purity wrote:

> *Issue*: when replacing HTML which contains &amp: using the BBEdit
> *replace* command

> in an AppleScript, the placeholder text being replaced is included at
> each
> occurrence of & in the replacement text, surrounded by the (desired)
> replacement text.

That's because you've specified a Grep search, in which "&" in the
replacement string specifies expansion of the entire match when
calculating the replacement. Chapter 8 of the user manual will have
details.

There's no need to specify "search mode: grep" unless you specifically
plan to perform regular expression pattern matching(*) in your search or
replacement; and as you've just demonstrated, unnecessarily specifying
"search mode: grep" can cause unexpected side effects. :-)

(* NB: backslash single-character escapes (such as \", \n, \t and so
forth) do not require grep searching.)

R.

--
Rich Siegel Bare Bones Software, Inc.
<sie...@barebones.com> <https://www.barebones.com/>

Someday I'll look back on all this and laugh... until they sedate me.