Some more background on $HTMLExportCommand, having burrowed into my email archive. It turns out, I tried re-integrating the above external solution as recently as 2022. It failed—silently. Best guess—after discussion with Eastgate—is the problem of escaping. The CL needs both single quotes for the sed
argument and within that (CL-)escaped double quotes which are a necessary part of the regex needed for the replacement task:
sed -E 's:href=\"index[^\.]*\/([^\.]+)\.html\":href=\"#\1\":g'
So we’ve got escaping in the command line and a further layer of escaping for storage in the XML of the TBX file. Somewhere in that nesting of escapes something is going awry.
When last discussed in 2022, the suggested solution was:
Rather than dealing with multiple levels of escapes, I’d suggest saving the sed command as a shell script. Make it executable with chmod, and then use that shell script in runCommand.
Essentially, I’m doing this in aTbRef (method described above) without the overhead of requiring the knowledge to set up the call to the shell. The point I observe is most Mac users are not confident/regular users of the shall. So the suggestion, whilst valid and well-intended, is IMO simply not valid in the deployment context.
I note all this here as some CL-adept folk among us might use an alternative approach. For instance one using less escaping such as seems to derail use of $HTMLExportCommand.
Essentially, my script looks for URLs in href
values in the HTML like index[something].html
and changes them to #(something)
. IOW, from a link to a jump-link to an in-page named as for the normally exported filename of the included page†. Note: the export templates (up-thread) deal with setting up those anchors in the HTML of the exported composite page.
I lay this out here in case someone in the community with CL smarts can suggest a way an ordinary/casual user with no CL experience can do this task without missing around under the hood of macOS (a scary proposition for many).
The difficulty of this also explains why aTbref has so many small articles. It allows both better addressability and avoids the problem with inclusion breaking links
One further workaround of sorts, and which I feel scales badly, is to make links in the TBX. But for those that are known to point to embedded notes, replace the calls with web links pointing to an anchor (which you’ll also construct in your export template) in URL of the exported note that forms the parent/base of the composite page. Not simple, I grant, but if the need is there, that is the route to take.
By way of recap there are tow edge-case export issues here:
- Tinderbox has no method to ‘auto-translate’ exported intra-TBX links where the target note is exported as an include to another note.
- Tinderbox links are one-to-one. If the target embedded note is used multiple times, Tinderbox has no way to know which one of those to which to point the exported link.
Thus, unless your export process demands composites, consider planning on using discrete files. Or, don’t use intra-note links, but that rather defeats the utility of a hypertext!
†. Oops, a point I missed for @LittleHouse75 earlier. aTbRef exports a root index.html and all other site files are thus within an /index/
sub-folder of the aTbRef site. In my sed
call I use ‘index’ as a filter to ensure I don’t ‘fix’ web links pointing outside the aTbRef site. So you may want to adjust the sed
regex accordingly for your use.