Why would a script work on one persons machine and not another?
What are the most commone reasons?
It could be due to different versions of AppleScript, different collections of osaxen, different versions of targeted applications, etc. There can be many subtle differences that can cause problems, including system related issues such as amount of available RAM and stuff like that. It sometimes requires a very painstaking process of elimination to find out what is at the heart of a problem.
I too am puzzled by this. I have a script that uses only standard Apple osaxen, which was completely portable under Mac OS 8, 9.
I’ve brought the source into Mac OS X Script Editor, on a “stock” machine, compiled the source, and it works just fine. The relevant tell block is below. The earlier part of the script builds the list which is passed into this tell block.
tell application "Finder"
repeat with x in theList
set file type of x to "spcF"
set creator type of x to "MapF"
end repeat
end tell
When I copy the compiled applet to another “stock” OS X machine, running the same version of OS X (10.2.6 currently), the script runs into an error. It replaces the words “file type” with “<>”. If I respond to the error dialog by using the “edit” button, and replace the “<>” with “file type”, the script immediately compiles, and runs properly for ever more…
This is repeatable and has occurred on each of the 6 OS X machines to which I’ve copied this script. Perhaps it has to do with the creator and type belonging to a Classic application - but I doubt it. I’ll go try this theory now…
Any ideas anyone?
Regards,
almage
Now that’s really strange. 8-
When I type this into Script Editor in both 8.6 and 9.2.2:
tell application "Finder"
set «class fitp» of x to "spcF"
end tell
… «class fitp» compiles to ‘file type obsolete’. That means it’s the ‘file type’ code from a version of the Finder that predates Mac OS 8.6. Any very old scripts that contain it will still work under 8 and 9, but if they’re recompiled with ‘obsolete’ removed, they’ll get the new ‘file type’ code. «class fitp» doesn’t compile to any keyword with the 10.2.6 Finder and ‘file type obsolete’ doesn’t compile there either - which means that this code’s now officially completely “dead”. I can’t think how it can have got into a script on your first 10.2.6 machine when compiling from the source code. Wee-ird… 8-
I saw similar results and I also wonder how this could happen. :shock:
The file and creator types (spcF, MapF) belong to an old legacy application, MapFile, first compiled on Mac II and IIx machines, under Mac OS 6. I believe these codes were registered with Apple in the late 1980s. The development and maintenance has been in MPW Pascal, for all these years. The suite of legacy applications are compiled with switch indicating the presence of a Floating Point Unit (FPU), the functions of which were embedded in the PowerPC chip. With the help of a third-party control panel, PowerFPU, we’ve been able to run these old, non-PPC-native applications through all these years, on Mac OS 7, 8,9 and now on OS X in Classic mode. This is an impressive tribute to the Macintosh OS, and much less a tribute to our ability to update this legacy suite to modern times (probably a two person-year time requirement!).
So, enough of this somewhat off-topic history. In regards to my Applescript problem, I am guessing that what Nigel means here
is that the actual code ‘spcF’ is old and obsolete, and therefore the source of my odd recompile-each-time experience. I’m not quite sure however, because it could be that the meaning is that the reference ‘file type’ is an obsolete Applescript reference from an old Finder dictionary.
I did the experiment of using a “modern” file and creator type, those for Adobe Acrobat pdf files, at least as they were defined in OS 9. This script
on run
tell application "Finder"
set theList to selection
if (count items in theList) = 1 then
if class of item 1 of theList is application file then
if name of (info for (theList as alias)) is "Edit Type & Creator" then
set theList to {}
end if
end if
end if
if (count items in theList) < 1 then
choose file
copy result as list to theList
end if
end tell
EditTypeCreator(theList)
end run
on open theList
EditTypeCreator(theList)
end open
on EditTypeCreator(theList)
tell application "Finder"
repeat with x in theList
set file type of x to "TEXT"
set creator type of x to "CARO"
end repeat
end tell
end EditTypeCreator
proved to be portable, without needing a recompile on a second OS X machine. I’ve encluded the entire contents of the script here, to eliminate any confusion on how I get ‘theList’.
Nigel and Rob, what happens when you type in a snippet of my original code
tell application "Finder"
set file type of x to "spcF"
end tell
into Script Editor in either 8.6 or 9.2.2? I have been reworking this script over the years, as I learned the little I know about AppleScript, to get the final applet to handle either a single file, a group of files, or a folder of files. I usually started with a fresh, untitled script in Script Editor or Script Debugger, and assembled the pieces as I went. The code was freshly compiled in many OS versions, 8.5.1, 9.0.4, 9.2.1, 10.2.x.
Many thanks for your time and thoughts,
I have neither 8.6 or 9.2.2 but it compiles fine in 9.1 and 10.2.6.
– Rob (who isn’t going to discuss this in two different places on the BBS) 
It worked perfectly on my first 10.2.6 machine as well!
Do you have a second 10.2.6 machine to copy the script, compiled as an application? This is where and when my difficulties began.
Agreed :!:
I wish! Nope, only one X box here.
I have the mixed blessing of caring for (read: administer) almost 20 OS X machines. Along with the eight Unix-only machines I care for, it is great that the Mac OS is blending so well, along with other advantages like Applescript!
So much to learn, and so little time…
Hi, almage.
Your script compiles fine in both 8.6 and 9.2.2. My raving about ‘file type obsolete’ was about the keyword ‘file type’ in the script, not about the “spcF” value to which you were trying to set x’s file type.
When a script’s compiled, the application and OSAX keywords are reduced to short, possibly numeric tokens that the applications (or OSAXen) can handle much more quickly than the keywords themselves. The compiler consults the applications involved about the token to represent each keyword. What you then see on screen is a decompilation of the compiled code back to scripter-readable text. That’s why Script Editor sometimes takes ages to open a long script. It’s having to quizz the various applications and OSAXen on your machine for the keywords that go with the tokens in the script. If you don’t have the relevant applications or OSAXen on your computer, or if none of them recognise the token, Script Editor displays a double-chevron version of the token instead (eg. «class xxxx», «event yyyy»).
If I type this into Script Editor in Mac OS 8.6 or 9.2.2, and compile it:
tell application "Finder"
set «class fitp» of x to "spcF"
end tell
… the decompiled version that appears on screen is:
tell application "Finder"
set file type obsolete of x to "spcF"
end tell
At some time in the past - before Mac OS 8.6 - the Finder’s token for ‘file type’ must have been something other than it is now. When Apple’s Finder AppleScript team decided it was necessary to change to the present token, they left the old token in place so that existing compiled scripts would still work. They changed the Finder’s keyword/token list so that the new token would take over the ‘file type’ keyword and the old token would now be called ‘file type obsolete’. When you open an older compiled script in Script Editor on a machine running a later version of the Finder, ‘file type obsolete’ appears on screen wherever ‘file type’ was used originally. If you delete the word ‘obsolete’ and recompile, the script will now get the new token.
The intriguing mystery for me is how one of your 10.2.6 systems managed to compile the old token into the script and happily run on it, when my 10.2.6 system and the rest of yours can’t even get a keyword for it and error when it’s run. The practical question for you is: how do you ensure your scripts are OK on all your machines?
It may be (though I can’t say for sure) that recompiling an old, compiled script doesn’t always get rid of the old junk. You could try saving the script as text and then quitting Script Editor. Then, using either Script Editor or a text editor - but in any case, before compiling the text - make sure that everything reads as it should - particularly with regard to ‘file type’. Then compile the script in Script Editor and save the freshly compiled version, which should now be OK on all your machines…
Thank you Nigel!
Especially for your compilation/decompilation/token description. This really helps my understanding of what I’ve experienced through years of hacking around with AppleScript, and never really mastering it.
I’ve used such ‘typer’ scripts (spcTyper, bbeditTyper, etc.) since the early days of AppleScript, primarily for our data files that have ‘lost their way’, usually due to transmission through non-Macintosh systems (Windows or Unix). I’ve also used them to coerce files from one application to another, for example, to bulk switch html source files from Explorer or Netscape to BBEdit or Pagespinner.
In my early days, I used a slightly different syntax to access the file type and creator codes, provided by a third-party osax - I think it was either Jon’s Commands or Tanaka’s Osaxen. I used there file and folder access commands as well. In all these cases, as I remember it, similar functionality either did not exist in the Finder, or was difficult for me to implement. Although I’m not even now a sophisticated AppleScript programmer, I was even less able in those days. As you may suspect, this all worked fine on my own computer, but as I began to share these scripts with others in our group, I ran into the problems of making sure that the proper versions of the third-party osaxen were installed on each machine. It was even difficult on my own desktop machine, as I progressed through system updates and cpu upgrades.
Eventually, somewhere around OS 8.5, I began retreading many of my small applet scripts, attempting to only use ‘Apple-native’ osax - those provided by Apple with the system. This helped a lot with portability issues. As you have described Nigel,
I remember this very thing occurring in many of my ‘typer’ scripts. At the time it always confused me, but a quick re-compile and I was up and running.
I believe I’m beginning to understand what may have happened. I typically save my utility scripts compiled as applications, in a folder that also contains a folder I call sources. In the sources folder, it appears that I save the compiled scripts. Contrary to what I previously stated and believed, I suspect that I’ve been bringing along, as ‘source’, compiled scripts, which could then have the obsolete tokens compiled into them, if I correctly understand some of your earlier descriptions. I have a Script Collection folder, that contains all of the third-party osaxen, Mac OS 9.0.4 standard scripting additions, and a lot of script samples, from myself and others. This is buried off in an old folder hierarchy and not knowingly defined as a place to find osaxen, so I think that this is probably not a player in this instance.
This is my challenge. Since I’m early in the stages of building my OS X compiled scripts, I intend to follow your suggestion below:
I may have confused the issue in my early descriptions of my situation. In OS X, I’ve never been able to decompile the obsolete token ‘<>’ , I’ve only ever been able to compile the scripter-readable text ‘file type’. I’ve just entered the following, and only the following, in Script Editor 1.9 on my desktop 10.2.6 machine:
tell application "Finder"
set <<class fitp>> of x to "spcF"
end tell
and it returns the following upon Check Syntax:
Syntax error: expected expression but found "".
Many thanks to you both, Rob and Nigel, I think you’ve helped me get straightened away!
Have a good weekend, and happy scripting…
Aha. I think in this case you used two pairs of single chevrons (<>) instead of a pair of double chevrons («class fitp»). 
On English language Mac keyboards, you get these characters by pressing option- and shift-option- respectively.
Have a great weekend yourself. I hope this is at least one of AppleScript’s many peculiarities that won’t be a problem for you any more. 
[quote=“Nigel Garvey”]
Once again Nigel, your observations are detailed and correct. This awakens yet another very old memory, that once upon a time I knew… :oops:
Thanks again,