I wonder if filters like this is possible and eventually what I’m doing wrong.
set tf to POSIX file (POSIX path of (path to desktop) as text ) &"Text.txt"
read tf
set theText to text of the result
close tf
tell theText
set empar to get paragraph 1 of it whose first character is "(" -- where it begins with "("
end tell
I know a couple of other ways to achieve the same result, I’m just curious.
this is not possible. The whose filter works only on object elements like files of Finder or tracks of iTunes.
In pure AppleScript you must use a loop.
Again a coercion note
set tf to POSIX file (POSIX path of (path to desktop) as text ) &"Text.txt"
in this line an alias is coerced to text → to POSIX path → to file URL
To get the HFS path of the desktop this is the proper way
path to desktop as text
in this case as text is no coercion, it*s a parameter of the path to command.
The read command expects an alias or file specifier
set tf to ((path to desktop as text) & "Text.txt")
set theText to read file tf
or
set tf to alias ((path to desktop as text) & "Text.txt")
set theText to read tf
The close line is wrong, it’s only needed as a balance to the open for access command
So words and paragraphs of a text is not an object element, but more like “properties”.
Thanks for your corrections of my coercions. -It’s very nice to get these things in place.
I was a little bit to quick meshing up some lines.
I’m actually reading the documentation for the path to right now. (About time)
And sees how much simpler ( and correct ) your code is. -I didn’t think of giving up the POSIX path while writing the code in the post. -Being paranoid about the user name (without an rational reason for I believe).
I guess I am right that the two bottom examples of yours both expresses the same and the alias in the last
is also unnecessary because
path to & "someFile.txt"
will be coerced to an alias in itself and thereby be a valid parameter to the read command. -But a tad more readable.
More specifically, ‘whose’ filters only work with object elements of scriptable applications and the applications must support the filters used. Since it’s up to the application developers to implement them, it often turns out that a form of fllter which works in one application doesn’t work in another. You have to experiment to see what does work.
An “element” is a “thing” that’s contained by (or is part of) another “thing”. There may be more than one of them and each may (or may not) contain other elements or have properties. They can usually be indexed by number. So words and paragraphs are elements of text. Words are also elements of paragraphs. You can filter for them within scriptable text applications like TextEdit, but not when the text has been extracted into vanilla AppleScript.
A “property” is a labelled value, which may be possessed by a script, a record, an element, or an application. It can only be referred to by its label, not by a number.
It may sometimes be that a property has an element as its value! For instance, an application with ‘configuration’ elements may have a ‘current configuration’ property whose value is one of the configurations. But ‘current configuration’ itself is a property of the application, the configurations themselves are elements.
Then the conclusion must be that I should write “filters” as a substitute for the whose clause when it is feasible to use whose constructs. By “filters” I mean the principles of the construct found on page 153 in AppleScript The Definitive Guide By Matt Neuburg.
Maybe in connection with the more advanced constructs for passing parameters (prepositional or labeled).
Speaking of ASTDG: the real reason for updating this section was that Matt Neuburg allwasy closes the file, even with a simple read. He makes some fuzz about it at page 372. He use the form close access,
together with a read command like mine in the post above.
So I’m interested in hearing about your rationale Stefan. I’m not sure whom I should believe when you and M. Neuburg differ in opinion.
Matt Neuburg’s book is the “bible” of AppleScript and he’s above any doubt.
When you read carefully Matt’s read and write scripts, you will see always this syntax
set fNum open for access
-- do something with fNum
close access fNum
there is never a single close or close access without a preceding open for access command
before he reads the file which means that he only uses file handles for reading files. Then he always has access to the file buffer.
I looked up in ScriptDebuggers dictionary and it stated that you could give anything to the close
access statement. -This is no dispute or something, - it just ok to get it sorted out.
It also makes sense that you can close even if you don’t have access to it’s buffer.
-Like a more higher level file command.
Are you sure that that construct is just a waiste of characters. - A system call that doesn’t work?
My syntax were however wrong. I should have written
For example I’m using this handler to write text to disk
on write_to_disk from theData into theFile
try
set ff to open for access file theFile with write permission
write theData to ff
close access ff
return true
on error
try
close access file theFile
end try
return false
end try
end write_to_disk
If an error occurs, the handler tries first to close the file handle.
If the file handle couldn’t be created with the open for access command, the handler tries to close the file.
The last try block is necessary in case the file is already closed when the error occurs
Hello
I believe that to be the correct way to write a file
And I understand that the open for access statement actually harnesses the quality of the code.
With an open for access command goes a close command.
To write to a file without any open for access command is so so. My experience with this is that
the file is closed right after the data is written or read, or that the close access can’t get to the buffer when a reference to a file is given.
The commands works quite soundly, -perfect!
All in all I’ll use your code as a template for writing other file handlers.
Thanks for taking your time and sharing your code.
I should really read the Apple Script Language Guide again.
I haven’t had a look at the last edition really. But I remember the last one as a good and very interesting book.
UPDATE:
I’ll promise to quote documentation correctly when I quote it.
I haven’t come around to read ASLG (again) yet, but will start that today.
After having read [url=http://macscripter.net/viewtopic.php?id=24745]this post here at macscripter[url]I am feeling a lot wiser regarding files. -I guess I am the kind of person who likes to see practical examples. But that was a marvelous tutorial. -I feel so much wiser!
I’m also the kind of person who likes to discuss things, from hereafter I’ll do my homework better before asking. -I really hope I haven’t trod on somebody’s shoes.