Open a Numbers spreadsheet with AppleScript

Hi all,


How do I get around violating the sandbox rules (sounds like a playground problem, no?) on this simple script? I'm trying to automate export from a spreadsheet that is updated arbitrarily and needs a scheduled export periodically...


I'm on

MBP 13", 3GHz, 16GB RAM, 1TB SSD

OS X: 10.12.2

Numbers: 4.0.5


This script:

tell application "Numbers" activate open "/Users/latcarf/Desktop/Test.numbers" end tell


Results in this super descriptive and indicative error alert: "Test" can't be opened for some reason.


User uploaded file

Which is actually listed in Console as a Sandbox Violation.


SandboxViolation: Numbers(2398) deny file-read-xattr /Users/latcarf/Desktop/Test.numbers Violation: deny file-read-xattr /Users/latcarf/Desktop/Test.numbers Process: Numbers [2398] Path: /Applications/Numbers.app/Contents/MacOS/Numbers Load Address: 0x1056cb000 Identifier: com.apple.iWork.Numbers Version: 4052 (4.0.5) Code Type: x86_64 (Native) Parent Process: launchd [1] Responsible: /Applications/Numbers.app/Contents/MacOS/Numbers [2398] User ID: 501 Date/Time: 2016-12-30 12:09:14.144 EST OS Version: Mac OS X 10.12.2 (16C67) Report Version: 8


This happens regardless if Numbers is open or not open already. If the file "/Users/latcarf/Desktop/Test.numbers" (which exists) is already open, the above script will work (though it doesn't matter that it works - because the file's already open). I can't count on this file having been open already.


I think, export will fail as well with permissions errors anyway (from a sandbox violation) so this might be a non-starter.


Any way around it? Sandboxing kills automation in many, many ways...


Thanks in advance!

null-OTHER, macOS Sierra (10.12.2), Original Mac 128k hard-soldered to 512k! wOOt!

Posted on Dec 30, 2016 9:20 AM

Reply
13 replies

Dec 30, 2016 9:41 AM in response to Latcarf

Well... As expected the AppleScripted export fails too unless:


  1. The Numbers document is already open
  2. You have already performed the export manually in Numbers once


Given that these two conditions are met, an AppleScripted export will be successful provided the document remains open and Numbers remains running. Close the document or quit Numbers and none of the scripting will work again until the above two conditions are met.

Dec 30, 2016 10:06 AM in response to Latcarf

Hello


You might try this:


tell application "Numbers" activate open ("/Users/latcarf/Desktop/Test.numbers") as POSIX file end tell



* In general, you cannot let an application open a string in AppleScript. You need to construct a file system object from path string explicitly before passing it to open command.


* Not tested with Numbers v4 because I do not use it.


Regards,

H

Dec 30, 2016 10:28 AM in response to Hiroto

Thanks Hiroto!! This worked. I've used AppleScript for literally decades but I'd forgotten about the POSIX file object. Too much shell scripting in the last few years, I guess.


Using the POSIX file object both for the open and for the export worked perfectly. No Sandbox violations. It also works when running the script from a shell script through osascript (which is what I needed anyway).

tell application "Numbers" set my_doc to open ("/Users/latcarf/Desktop/Test.numbers") as POSIX file tell my_doc to export to (("/Users/latcarf/Desktop/Test") as POSIX file) as CSV end tell


Thanks for the gentle reminder of my forgotten knowledge. I used to know this. I'm getting old.

Dec 30, 2016 1:12 PM in response to Latcarf

You're quite welcome. I'm glad to know my old knowledge still serves. 🙂


To save myself from the mess of file system object implementations in AppleScript, I come to use POSIX file for POSIX path mostly and alias for existing HFS path occasionally. POSIX file object is preferred to alias object because it is actually a file URL object and can distinguish mount points explicitly and can represent non-existent node to be created.


All the best,

Hiroto

Dec 31, 2016 8:42 AM in response to SGIII

When OS X came out, professionally and personally I started using shell scripting more than AppleScript. After that, when I needed to use AppleScript, it was usually a small part of a larger system predominantly built in shell, PERL, or other scripts. It became inconvenient to use HFS (colon delimited) paths when everything else was using UNIX/POSIX style paths. In addition, the need to know the hard drive name was also inconvenient. After the POSIX file class came out in Standard Additions, I went with that and never looked back to HFS paths. Now HFS paths just feel anachronistic.


Indeed, this question came from the need to use AppleScript as a small part of larger system. using shell and python scripting. The AppleScript is invoked via osascript in a 'here document' and since the other scripts pass off the paths, it's just easier to use UNIX paths throughout. In fact, one of the reasons I had this question was my surprise that AppleScript still doesn't handle UNIX path strings! (Well, that and the strange sandbox violations caused by using the path strings)


I've not used AppleScript for a few years an have forgotten alot of it. In decades past I sometimes used AppleScript exclusively but those days are long gone and over the years AppleScript has become less and less necessary to accomplish my tasks.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Open a Numbers spreadsheet with AppleScript

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.