Re: Applescript and referring to a folder
Re: Applescript and referring to a folder
- Subject: Re: Applescript and referring to a folder
- From: Rowland McDonnell <email@hidden>
- Date: Tue, 26 Jan 2010 15:18:35 +0000
Rowland McDonnell <email@hidden> >
I'm not sure I understand that - it's a
pointer to an object, and that
object has a path which I manipulated in my script using stuff I wrote.
Yes, but it's not a file object. It's a document object.
Yes, and a file path is associated with each of these document
objects, and Applescript will give me that file path, and then
Applescript refuses to let me use that file path as a reference
to a file system object - unless I jump through ugly hoops for
reasons I do not understand.
That is the problem which I am trying to solve.
Two
different types, like apples and oranges,
Not like apples and oranges at all. Like a page of text and a
page of text - but a different layout on each page.
(btw, I don't see any benefit in using analogies. At best,
they're meaningless; more usually, they're confusing and so
obstruct my attempts to understand. Or so I find.)
even though they're both
fruit.
Fruit doesn't come into it and it's confusing to mention the stuff.
The document object points to a file object. The two are
intimately associated with each other and Applescript
successfully gives me the path to the document when I ask for it.
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.
I don't understand why it is that Applescript seems unable
automatically to coerce the path data I can extract from the
document object properties into a file system pointer. I can
force that coercion by using this nasty horrible ugly code:
set this_documentX to path of this_document as string
make new alias at selected_folder to POSIX file this_documentX
What I'd like to do is do the same job but without having to
invoke the POSIX outlook.
The document object represents a document that is open in TeXShop.
Yes, I know - which also has a life as a file system object. I
can get a path for each document object in TeXShop (assuming
it's been saved).
My code actually does that using what I'm sure is a nasty ugly method.
It
is formally independent of the file on disk where you happened to have
loaded (or last saved) that 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.
and in fact you can have a
document object that has never been on disk at all.
So I need some error handling to deal with cases where the
document's not yet been saved. I think I'll find that trivial
to add once I've sorted out the enormously hard bit that I've
got stuck on - working with file system pointers.
More importantly,
you can't do anything to a TeXShop document without actually going
through TeXShop. A file on disk is a file on disk whether some
application has it open or not.
But I want to operate on the file on disc that the document is
associated with and for each of which I have worked out how to
get a path. The problem is that Applescript won't work with the
path as a pointer to a filesystem object unless I use a really
ugly method of coercing the data type into what's needed.
It appears from your code that the document has a reference to a
pathname (the 'path' attribute), presumably where it was last loaded
from or saved. But having that attribute doesn't make it a file
object.
I don't see what relevance that has.
The document objects in question each has a file system path
pointing to a file on disc, and I want to be able to use that
file system path as a reference to a file in the file system.
The problem is that there doesn't seem to be an elegant way to
do that, only an ugly one.
The document is a passenger; the file is the car. The
passenger may have a key to the car on him, but that doesn't mean you
can hop in his pocket and drive off.
Sorry, analogies confuse the hell out of me. I've no idea what
this means at all.
So it's clearly an object that uniquely points to a unique file system object.
Points to, yes. Is, no.
Is? Nothing `is'. Sorry, I don't understand you at all.
And I see Applescript complaining that it can't coerce what's obviously a
path to file system object into an alias at times.
A document is not a path, and a path is not a file.
A path points to a file. I can get a path for each document
open in TeXShop. Applescript will not use such a path as a path
unless I use ugly coercion. I'm trying to find elegant coercion.
AppleScript will
happily coerce a path into a file,
It has failed to do so when I've asked it to.
but it won't go hunting around
inside an arbitrary application object looking for a path to do the
coercion on.
I can give it a path and it says it can't coerce it into the
required data type. So what you've just told me is not attested
to by the real life behaviour of Applescript that I've met.
In any case, AppleScript is very picky about what it will and won't
coerce and what to.
I had noticed - so picky I'd say it's broken.
Here's the paragraph on the subject from the
first edition of Matt Neuberg's book:
An alias can be coerced to a string representing its Macintosh
pathname, and its POSIX path property is a string representing its
POSIX pathname. An alias cannot be coerced to a file object, but a
string can be used as an intermediary. A Macintosh pathname can be
coerced to an alias. A file object cannot be coerced to a string, but
it can be coerced to an alias (which can be coerced to a string). A
file;s POSIX path property is a string representing its POSIX
pathname. A POSIX file can be coerced into a string representing its
Macintosh pathname. A Macintosh pathname can be used to form a file
specifier. A POSIX pathname can be used to form a POSIX file
specifier.
I think I'm going to have to do quite a lot of background
reading before I can make sense out of that.
I've asked for book suggestions and I'll be buying one or two.
set the_alias to the_document as alias
Okay - what does that do, and what data types are the_alias and the_document?
What, for that matter, is the alias in question?
As an unrelated point, nested tell blocks are just begging for
terminology conflicts.
I don't understand what that means.
AppleScript syntax is dependent on the
application being targeted, many applications use similar names for
different things, and the compiler is easily confused.
I find that idea so hard to accept my first response is to write
`Oh no it doesn't'.
Are you seriously telling me that the version of Applescript
that comes with MacOS X 10.6.2 is so bug-ridden that the
compiler can get *confused* over nested blocks?
Warn me against getting *me* confused over nested tell blocks,
yes; but warn me against compiler confusion? Come on!
I don't see how any compiler that's out of alpha test could
possibly get confused over anything.
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.
This should work, though I haven't tested it:
tell application "TeXShop"
set all_paths to (get the path of every document)
end tell
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)
tell application "Finder"
repeat with the_path in all_paths
make new alias at selected_folder to POSIX file the_path
end repeat
end tell
I was hoping to be able to dispense with the POSIX bit entirely.
Thank you for your extensively and detailed reply,
Rowland.
_______________________________________________
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