Beyond Compare Folder Comparison via Tinderbox

[Pete]

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)

[satikusala (Michael Becker)]

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

[Pete]

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

[mwra (Mark Anderson)]

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 ” 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.

[eastgate]

@Pete

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

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.

[mwra (Mark Anderson)]

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.

[Pete]

@mwra

Only difference, the square brackets

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 …)

@mwra

This creates a child container called “$Path” (yikes!)

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).

@mwra

so currently neither a literal string argument nor an attribute reference nor a variable(value) works consistently.

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

[eastgate]

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