Re: Applescript and referring to a folder
Re: Applescript and referring to a folder
- Subject: Re: Applescript and referring to a folder
- From: "Mark J. Reed" <email@hidden>
- Date: Tue, 26 Jan 2010 11:32:31 -0500
OK, analogies usually help; sorry for the confusion. My point is, a document object is not a file object. It may *refer* to a file, but that doesn't make it the same thing *as* a file.
Application objects, as far as AppleScript is concerned, are inviolable. You can't do anything with them except hand them back to the application you got them from and ask that application to do something on your behalf. Less figuratively, the only commands that you can apply to them are commands defined by the application itself, not commands defined by some other application. So you can't make a disk alias (which is a Finder command) out of a TeXShop document object, because the Finder doesn't know anything about TeXShop documents and TeXShop doesn't know how to make disk aliases.
What you can do is extract meaningful data out of application objects in some universal form that can be used by other applications and by AppleScript code that doesn't target any application: text strings are a good example. So a way to get an alias to a TeXShop document is to do exactly what you're doing - get the pathname, which, as a string, is universal, and use that to construct the file reference needed by the Finder to make an alias.
File objects and AppleScript "aliases" (not the Finder/disk kind) are also a universal type, and there may be a way to get one of those out of the document object without having to go by way of the POSIX pathname. See below.
> What Applescript refuses to do is to permit me to manipulate the file to
> which that path refers, unless I go via a very ugly construction to coerce
> the path data into something that Applescript understands as a file pointer.
Having to say (POSIX file pathNameGoesHere) is not "a very ugly construction" (or "nasty horrible ugly code") by AppleScript standards; it is the standard way to get a usable AppleScript object out of a POSIX path name.
However, if you really need the "as string" at the end of "path of this_document", then you should look in the TeXShop dictionary (File->Open Dictionary from Script Editor), in the document class, to see what the type of "path" actually is. You might be doing an unnecessary double conversion from a file reference to a string and back to a file reference - despite the name, the "path" might actually be an alias (in the AppleScript sense) instead of a string. If it is, then you might be able to use it directly (as long as you don't coerce it to a string first). e.g.
tell application "Finder" to make new alias at selected folder to (path of this_document)
> What do you mean by that? The document objects concerned all have a file
> system path associated with them, which means to me that it's certainly
> formally connected to a file on disc.
It's incidentally connected to a file on disc. A document references a file on disc, but is not identical with a file on disc. This is an important distinction. The file exists when the app is not open. The document doesn't. The document exists when created via File->New, before being saved, even though it has no file on disc associated with it.
Trying to access a TeXShop document will launch TeXShop if it's not running.
Renaming, making an alias to, deleting, or otherwise manipulating the file on disc that holds the document will not involve TeXShop at all.
They're different objects. They have an association between them, but they're not interchangeable.
>> AppleScript will happily coerce a path into a file,
>
> It has failed to do so when I've asked it to.
It depends on how you ask, and what kind of path you have. If you have a POSIX path, you have to use the POSIX file constructor syntax, (POSIX file pathNameGoesHere). But if you have a Mac-style path, then just (pathNameGoesHere as alias) will work; that is a coercion. You can also use the non-POSIX file constructor syntax (file pathNameGoesHere) with a Mac path.
>> As an unrelated point, nested tell blocks are just begging for
>> terminology conflicts.
>
> I don't understand what that means.
You have a 'tell application "Finder"' block inside a 'tell application "TeXShop"' block. As a general rule, nesting tell blocks like that is inadvisable, because a tell block imports the application's terminology into the current namespace, and you could wind up with terminology conflicts.
The compiler is not really confused, of course. But you will get confusing results. Worse, you will not necessarily get any warning from the compiler that there is a conflict.
>> So I wouldn't
>> put a "tell Finder" block inside a "tell TeXShop" block; get all the
>> pathnames out of TeXshop first and then make the aliases separately.
>
> I don't understand you.
Right now you're doing the alias-making inside the "tell TeXShop" block. It's interleaved:
1. get a document from TeXShop
2. tell Finder to make an alias
3. go back to 1 while there are any more documents
Every time through the loop, you're talking to both applications, and since the TeXShop tell block encompasses the whole loop, the Finder loop is inside it. It's not really a problem in this particular case; it's just not best practice.
Instead, you can split it into two phases:
1. Query TeXShop for the pathnames of all its open documents.
2. Tell Finder to make aliases to all the corresponding files.
> Okay - could you perhaps explain the meaning and function of this line,
> which uses coding I'm not familiar with:
>
> set all_paths to (get the path of every document)
It constructs a list containing the paths of all the documents.
The "every document" by itself is the same as "documents" - it returns a list of all the document objects.
Applying "(the) path of" to "every document" causes it to apply "path of" to each document in the list and return the list of results. So instead of a list of document objects, you have a list of paths. (The word "the" is a no-op intended to make the code read better as English.)
The "get" makes sure that you have an actual copy of the path data on the AppleScript side, rather than just a reference to data that you have to talk to TeXShop to manipulate.
The following loop achieves the same result more verbosely:
set all_paths to {} -- empty list
tell application "TeXShop"
repeat with a_document in documents
set end of all_paths to (get the path of a_document)
end repeat
end tell
The end result is a list, where each item of the list is the result of asking TeXShop for the path of one of its documents.
I was assuming that "path" returned a string, by the way, which may not be the case, as discussed above. You can add "as string" to the end of the "get the path of every document" command if needed, or if it turns out that "path" returns an alias or file object in the first place, just get rid of the "POSIX file" in the "make new alias" command.
_______________________________________________
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