Re: run script
Re: run script
- Subject: Re: run script
- From: Ric Phillips <email@hidden>
- Date: Thu, 23 Aug 2001 10:50:27 +1000
On 23/8/01 4:37 PM, "JJ" <email@hidden> wrote:
>
> 1) As I understand, the command "open for acces" in the scripting additions
>
> opens a text file passed as an alias. When the file doesn't exist, it
>
> creates it. My question may be stupid but it is not possible to create an
>
> alias to a file that doesn't exist! If I send directly a new file name
>
> instead of an alias like open for access "Macintosh HD:Work:MyTextFile" it
>
> doesn't work. What am I doing wrong?
>
>
>
set new_file to "HD:Desktop Folder:Inexistent_File"
>
open for access new_file with write permission
>
write "Hello, Dolly" to new_file
>
close access new_file
>
You don't have that problem. Rather your references to the file through the
variable new_file aren't going to work because a path name isn't a complete
file reference. You need to still precede the variable name with a type
identifier - 'file' or 'alias' - as in 'write "Hello Dolly" to file
new_file'. With those added your code works just fine.
An alternative is to store the (HFS) file/item id on creation using the
following syntax,
Set new_file to open for access file "HD:Desktop Folder:Inexistent_File" ,
with write permission
write "Hello, Dolly" to new_file
close access new_file
It may have been seeing code like this that led to the mistake in the first
place. In this sample the variable 'new_file' is loaded with the file id
number assigned to the new file by the system. This value can be
de-referenced by the read write and close commands directly via the variable
name - without any type prefix.
For any beginners reading this.....
-----------------------------------------------------
With all 'loosely typed' languages, like apple script, you always need to be
careful of what type of data a variable is de-referencing and whether your
reference forms are correct.
Consider the following example....
If a folder has only one item in it then the following code,
tell application "Finder"
set x to the name of every item in folder "folder 1"
end tell
...produces a string result => "item 1"
But if the folder has more than one item in it the same code produces a list
result =>
{"item 1", "item 2", "item 3"}
You've used 'every', so (naturally!) you assume you have a list. On this
assumption, later in the code you process that list...
repeat with i in x
<do something to i>
end repeat
Fine - where your folder had multiple items the list you are processing will
be {"item 1", item 2", ... "item n"}. But where your folder had a single
item and the code returned a string, Apple Script won't throw an error.
Instead it will convert the the string "item 1" into the list...
{"i", "t", "e", "m", " ", "1"}
...and process that (according to the logic of your code) as if each
character in the list were the name of an item in folder 1.
So your code could appear to test well, but fail later because of changes in
environmental conditions that affect the data type being returned by the
code.
Using an explicit type cast can avoid this problem. IE., in the above
snippet,
set x to (the name of every item in folder "folder 1") as list
...will force a single item result to => {"item 1"} - and the assumption
that any code thereafter processing the variable x is processing a list will
be a safe assumption.
But here's the really interesting (and frustrating) bit, the above scenario
applies to code de-referencing the name property of all the items in a
folder, but if you were simply getting a reference to the items themselves,
as in..
set x to every item in folder "folder 1"
Then even if there was only one item in the folder the result would be
returned as a singe item list.
Go figure!??! There may be some underlying pattern or rule governing such
'inconsistencies' in Apple Script, but if there is, I haven't found it yet.
Ric Phillips
Computer Laboratory Support Officer
Faculty of Humanities and Social Sciences
La Trobe University
9479 2792