Tinderbox Forum

Beyond Compare Folder Comparison via Tinderbox

Hi, I got a new mac which was delivered several weeks before the announced date. I initially planned to use the time (till it should be delivered) to go thru my old mac’s directories to get rid of year old stuff that I won’t need anymore and to establish a better folder structure. This probably would have worked just fine to be prepared for a clean install. But, of course, the moment the new mac was delivered all those plans vanished. So, now I’m in a quite frustrating situation, that is: new mac (with important stuff already copied to it) and disk images of the old mac.

I thought it would be a good idea to use Tinderbox and Beyond Compare (via its scripting language) to make sense of the mess. But although I nearly got everything working I can’t for the life of me figure this one out:

Why does this code

var path=$Path;
create(path,$Name+" - Name of the Child Note");

work for notes on root-level - and why does it fail for non-root-level notes?

(for testing purposes it’s in a Stamp; will be in an Edict later)

test.tbx.zip (32.7 KB)

I don’t understand. Seems to work for me. Created a test not just fine.

1 Like

Why does it not work with note Content/Ordner vergleichen/Kater Blau Radio [geschnitten]??

It’s not a bug, but a definite glitch. the issue isn’t whether the note is at route. It is the presence of square brackets [ ] in the note—title or path.

Your stamp works on the non-root note “Ordner vergleichen”. But if I change the note’s title ($Name) to “Ordner vergleichen [x]” the same stamp fails. This is repeatable.

Oddly, although some characters are known to problematic for action code use when the occur in a note’s title, square brackets have until now not been a problem.

pinging @eastgate in case I’m mis-understanding the cause of the failure here.

I believe that the second argument might be evaluated twice. First, of course, we have to evaluate the argument itself, so we get something like

create(path, TheName - Name of Child Note)

But, when checking to see if the note already exists, I believe we try again to evaluate the path expression, just in case that’s what you meant.

I think that second evaluation is a bad idea nowadays, but should check what breaks before scrapping it.

Agree, neither argument is being correctly evaluated. But [ ] remain problematic. Proof, this stamp using explict literal strings for both arguments still fails:

create("/Content/Ordner vergleichen/Kater Blau Radio [geschnitten]","Kater Blau Radio [geschnitten] - Name of the Child Note");

but this works:

create("/Content/Ordner vergleichen/Kater Blau Radio geschnitten","Kater Blau Radio geschnitten - Name of the Child Note");

Only difference, the square brackets. So evaluation is mis-detecting literal values as, I guess, regex patterns?

Trying to use an attribute value for argument #1, results in its use as a literal string:

create($Path,"Kater Blau Radio geschnitten - Name of the Child Note");

This creates a child container called “$Path” (yikes!) with the new note inside it:

so currently neither a literal string argument nor an attribute reference nor a variable(value) works consistently. I wonder if a recursion error has crept in as I’m sure when testing this operator when first added that we didn’t have this issue.

IIRC, create() was first added for v8.0.0 (see create(item)) and last changed in v9.1.0 (see create([pathTo,] name)). Despite small changes in the name of the page in aTbRef, the olny change appears to be that v9.1.0 ensured:

From v9.1.0, the create() operator always returns the path to the new (or pre-existing) note. Previously, if the note already existed, create() returned false .

So the change in observed behaviour doesn’t appear to derive from a deliberate feature modification.

Yes, I also figured that out but forgot to mention it (I’ve spend far too long (hours …) trying to figure out what’s going on and didn’t keep track of “interesting” results …)

Hahaha, yeah, that was the point when I finally knew: you have to ask, there’s definitely something going wrong (again, I didn’t keep track of results but randomly tried).

Now worked around this by temporarily storing the original name in an attribute and restoring it afterwards. However, the code I used to write the Beyond Compare’s folder comparison report to a new note’s $Text currently doesn’t work anymore. So I might later need some help with this.

Thanks for looking into this, much appreciated :slight_smile:

1 Like

The reason [ ] is causing trouble is that it’s being evaluated, and (say) Customer [ Harrison ] is treated as a synonym for $Customer.at("Harrison").