Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Applescript errors with CO20 after upgrade from CO11

Comments

10 comments

  • Eric Valk
    Are you running these scripts from Apples Script Editor of from Capture One?

    IMO your Applescript is not broken, either your script or the script's parent doesn't have permission to use exiftool or possibly to use the do shell script comand.

    Which Operating System are you on, 10.14 or 10.15?

    I'm om 10.14.6,

    I note that I have enabled both Capture One 12 and Capture One 20 in the following panels
    • System Preferences> Security & Privacy> Full Disk Access

    • System Preferences> Security & Privacy> Automation

    • System Preferences> Security & Privacy> Accessibility


    In addition my standalone scripts are in the Automation and Accessability panels
    0
  • rollbahn
    Sorry Eric - I should have mentioned all that in my post.

    I am on 10.13.6 (nice and stable so not keen to upgrade until Catalina improves) and have been running these scripts via Capture One's menu for 2-3 years without an issue.

    As I am using 10.13 there are no settings for Automation and Full Disk Access that I am aware of but there is an Accessibility setting. I added in Capture One 20 (still doesn't work) but I didn't have that set for CO11 and it worked fine.

    In my Google searches I did come across what you said which was an issue with the do shell script command but I can't think how to fix it.

    I am wondering if CO20 added in the additional permission requirements because of 10.14 and 10.15's new security features but because I am on 10.13 I have no way to set that and therefore have the issue. I'd be ok to move to Mojave if I know that is the issue but surely there's another way around it for now.

    Thanks for your help.

    Jason
    0
  • Eric Valk
    Its good that you are on 10.13 for now. I was on 10.12 for a long time, moved to 10.14.6 in November.

    10.14.5 was the start of the new OSX security structure.

    Applications like Capture One cannot change the Operating System security, like Full Dusk access and so forth, they can only trigger security mechanisms that already exist to act. The errror message you got comes from OSX's security system.

    Fortunately for you (in this case) 10.13 does not have a very complex security mechanism, I assume its much like 10.12 although I have no direct experience with it.

    Lets try this:
    I assume

    • That the security mechanism is the same as in 10.12 and earlier releases

    • That you have one OSX account, and it has admin privileges

    • That in this OSX account, you down loaded and installed Capture One 20

    • Because you run the script from Capture One 20, its an issue with Capture One's own permissions. In any case, we make sure these are OK first.


    Just to "clean" all the system settings and remove anything that might cause issues, do a safe boot. (I learned this from Apple support when we were debuggong a strange problem with my Mac)
    • Shut down the Mac

    • Start the Mac

    • Immediately after pushing the start button, press and hold the left shift key (right may work too, but I always use left and haven't tried right)

    • Hold the shift key until the boot sequence is completed and you can sign into your account (this may be 3 minutes or more)

    • You will see Safe Boot in small red letters at top right

    • Sign into your account. Do some trivial operations. The screen may flicker a bit.

    • Restart normally and sign into your account


    Now lets remove any quarantine flags on Capture One 20 (this is one of the fundamental security measure on that generation of OS X)

    Find the Capture One 20 application with Finder
    Right click (or control click) on the application. In the menu that pops up, select "Open"
    If there was a quarantine set, then a pop up appears that asks something like "Do you trust this Application? It was downloaded blah blah blah". Of course you will select OK or Yes.

    (If Capture One was installed by another Account on this Mac, this may not be effective. But I am perhaps unusual because I have multiple accounts on my Mac for different people and diffferent purposes. Likely nothing for you to worry about.)

    Then Capture One will start, use it for something trivial. Stop it, start it again. Now try your script and see if it works.

    If it doesn't work, then it may be that Capture one has made a private copy of the script application, and the issue is with the copy, or possibly there is a new version of ExifTool and th issue is there.

    Please try the following and report back:
    • Does the Script still work in Capture One 11?

    • Does the script work in Standalone mode?
      Can you run the script from script Editor?
    0
  • rollbahn
    Thanks again Eric for your comprehensive error it is much appreciated!

    I had an inkling that the error was more to do with Applescript than the system so I did a bunch of testing and retesting today and solved the issues and will post below in case anyone has similar problems in the future.

    Here's the new code and there's only two small changes. Apparently the privilege error comes from the use of the "do shell script" inside the "tell application" loop. If you need to do the loop inside the "tell" loop then the way to solve that causing an error is just to put "tell current application to " in front of the command.

    The other thing I did along the way is add in the "iName" variable and stipulate the file path directly for the exiftool line and that solved the " Error: File not found".

    I still have no idea why this all changed with Capture 20 but now I'll have to update all my scripts I guess. 😄

    tell application "Capture One 20"
    set selectedVariants to get selected variants
    repeat with i from 1 to number of items in selectedVariants
    set this_item to item i of selectedVariants
    set theID to id of (parent image of this_item)
    set iName to path of (parent image of this_item)
    --display dialog "my variable: " & iName
    tell current application to do shell script "/usr/local/bin/exiftool -Make='Pentax' -Model='MZ-S' -Lens='Pentax-FA 31mm f/1.8 Limited' -m -overwrite_original_in_place " & quoted form of iName
    --log theID
    reload metadata this_item
    end repeat
    display dialog "EXIF data has been updated"
    end tell
    0
  • Eric Valk
    Wow, I completely missed that one.

    I don't understand why the previous version of the script ever worked.
    0
  • rollbahn
    Thanks Eric - yes me too 😄
    0
  • Jim_DK
    Small tip (also):

    The line set myVars to selected variants is old, problematic syntax and best avoided.
    Better to use the newer (from CO11.1 on) set myVars to variants whose selected is true

    /2c
    0
  • rollbahn
    [quote="Jim_DK" wrote:
    Small tip (also):

    The line set myVars to selected variants is old, problematic syntax and best avoided.
    Better to use the newer (from CO11.1 on) set myVars to variants whose selected is true

    /2c


    Thanks very much for the tip Jim - I couldn't find that line in my script.

    Should I be changing this one

    set selectedVariants to get selected variants

    to

    set selectedVariants to variants whose selected is true
    0
  • Jim_DK
    Apologies I used my own variable name. But yes - you got it.
    0
  • rollbahn
    No worries - thanks Jim!
    0

Please sign in to leave a comment.