Re: Problem saving a new file
Re: Problem saving a new file
- Subject: Re: Problem saving a new file
- From: Axel Luttgens <email@hidden>
- Date: Mon, 22 Oct 2012 23:52:25 +0100
Le 22 oct. 2012 à 12:47, Eric Robertson <email@hidden> a écrit :
>
> On 21 Oct 2012, at 11:49, Axel Luttgens <email@hidden> wrote:
>
>> Le 20 oct. 2012 à 17:30, Eric Robertson a écrit :
>>
>>> [...]
>>>
>>> I was aware that you can't use a file alias for a non-existent one but I thought I'd read that while the dictionary of some applications specified that a file alias had to be used you could get by without using one. This doesn't work here and I see how you've got over this problem.
>>
>> Hello Eric,
>>
>> You are right: dictionaries are often a bit inaccurate when it goes about the way to specify a file; as a result, some trial and error is often needed...
>>
>> On the other hand, it's always worth to have a look at the way an application behaves, since its scripting model usually tends to reflect that behavior.
>>
>> In the case of TextEdit, the workflow is to ask for a new document (which is internally handled by TextEdit in some kind of limbo as far as the user is concerned), then to type some contents, and finally to save the document somewhere.
>>
>> So, let's try to just mimic this:
>>
>> tell application "TextEdit"
>> tell (make new document)
>> set its text to "This is sample text"
>> close saving in POSIX file "/Users/ericrobertson/Documents/New Notes.rtf"
>> end tell
>> quit
>> end tell
>>
>> HTH,
>> Axel
>
> Thanks Axel, that works fine. I'm confused though as some of the other suggestions haven't worked because it seems of this sandbox effect, and the new file had to be set up outside of TextEdit yet here you've managed to do the whole thing inside TextEdit. Is it because you've got the whole thing inside that second 'tell' so the whole thing is inside the sandbox?
Hello Eric,
The inner tell block is just there for the lazy guy (me): while ensuring the target of the enclosed commands is indeed the newly created file, it avoids to type references to that file. As a side effect, this also yields a more legible code.
Now, it appears that various themes have been encountered throughout the thread.
The first one appeared with the seemingly innocuous attempt to specify the file's path at creation time:
tell application "TextEdit"
tell (make new document with properties {path:"/Users/ericrobertson/Documents/New Notes.rtf"})
set its text to "This is sample text"
save
end tell
end tell
--> An error pops in TextEdit: Document « New Notes.rtf » could not be saved. You aren't allowed.
This indeed suggests that sandboxing is at work, but also that TextEdit probably isn't supposed to work that way. After all, a newly created document in TextEdit (the automatic one, or one created with the "New" menu item) has a path set to missing value; it is only afterwards, through some save dialog box, that the path will be set (with the physical file created at the same time).
Hence the second theme: TextEdit's dictionary tells that the save command requires an alias reference, but such a reference requires an existing file; so, let's create the file outside of TextEdit (supposed unable to create files because of sandboxing), and the code thus became similar to this one:
-- create file "New Notes.rtf" with System Events, then:
tell application "TextEdit"
tell (make new document)
set its text to "This is sample text"
save in alias "Macintosh HD:Users:ericrobertson:Documents:New Notes.rtf"
end tell
end tell
Right, it works, but yet leaves a question open: why should TextEdit be allowed to overwrite an existing file, while not being allowed to create a new file at the same location? Wouldn't this be a poor sandbox implementation?
Incidentally entered a third theme, a rather interesting one:
path to documents folder
--> alias "Macintosh HD:Users:ericrobertson:Documents:"
tell application "TextEdit"
path to documents folder
--> alias "Macintosh HD:Users:ericrobertson:Library:Containers:com.apple.TextEdit:Data:Documents:"
end tell
So, calls to Standard Additions commands are liable to be subjected to the sandboxed status of an application. I'm still wondering at how Apple managed to do that, but there must be a nice trick at work here. ;-)
But now, going back to the original problem, it appears that TextEdit is perfectly able to create files anywhere in the filesystem, provided the unix permissions (or some ACL) allow that file creation: just create a new file with the "New" menu item, then save that file with the "Save..." menu item everywhere you want. Which isn't really surprising after all, since
codesign --display --entitlements - /Applications/TextEdit.app
shows that TextEdit has the com.apple.security.files.user-selected.read-write entitlement. As a result, once the user has specified a name/location for a file through a dialog à la "Save...", TextEdit is allowed to create that user specified file.
Hence my (un)educated guess:
1. in the GUI, one asks TextEdit to create a new document and then to save it at a specific location
2. the corresponding commands in AppleScript should be "make new...", then "save in..." or "close saving in..."
3. TextEdit relies on the NSDocument class, and that class should have been updated to take sandboxing into account, so that AppleScript commands should preserve the application's entitlements
The third point is of course the more questionable one, since I just don't know: perhaps is the AppleScript's support provided by NSDocument just plain unaware of entitlements.
But trial and error shows that one is able to save documents anywhere by scripting TextEdit, the same way as before TextEdit became sandboxed.
> I don't think I would have thought of this way of writing the script from the workflow.
Perhaps because of my choice of "close saving in..." instead of "save in..."?
I agree that I've been somewhat liberal in my wording of the workflow description. ;-)
> Eric
>
> PS Sorry I forgot to change the Subject in my last email - any way to change this now?
Too late: we all have received it as is. :-)
HTH,
Axel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden