AppleScript 1.5.5 (Mac OS 9.1)


There are a number of reported new AppleScript bugs in Mac OS 9.1.

The announcement of AppleScript 1.5.5 from The AppleScript Team noted that certain operations on Unicode text (concatenation, equality testing, word or character access) will cause an error or crash. This will be fixed when Mac OS X is released (scheduled for March 24, 2001). See Unicode AppleScript Text Coercions May Fail (TIL #106096 1/4/01, updated 1/16/01).

The same announcement reported that, [d]ue to an error in integrating a new feature, some features of the Read/Write scripting additions are not working. Specifically, writing a list to a text file will corrupt the text file. This, too, will be fixed when Mac OS X is released. Chris Nebel addressed this issue as early as October 24, 2000 in a message to the AppleScript-Users mailing list, reporting that read/write is fundamentally broken in a number of ways, especially when it comes to reading and writing lists and records as binary data. I think it works for flat lists, but nothing else. A workaround is to use Sigma’s Coercions or some other third-party solution.

Mac OS 9.1: Dialog Box Does Not Cancel on First Attempt (TIL #106091 12/19/00, updated 1/9/01) reports that in Mac OS 9.1 the AppleScript dialog box asking you to locate an application if the application cannot be found reopens after you click Cancel. The workaround is to click Cancel three or four times. This problem reportedly also existed in AppleScript 1.4.3 (Mac OS 9.0.4). I have found at least one other dialog that behaves in this fashion, in an Apple scripting addition, so I wonder if it may be a CarbonLib bug. 2/28/01

A number of users have reported that the Path To command in the Standard Additions scripting addition has problems when invoked inside a Finder tell block, at least with respect to the Startup Disk special folder. Workarounds include moving the Path To command outside the Finder tell block and using the Finder’s own command for obtaining the path to the startup disk.

A number of users have reported that the File or other menu titles in Script Editor sometimes flash rapidly. Mr. Tea pointed out that what triggers this misbehavior is the use of a command-key equivalent to exercise a menu command. The flickering stops when you switch to another application and back. It appears to be harmless, if somewhat distracting. Contrary to my earlier belief, it is not cured if you install CarbonLib 1.2 or 1.2.5. I have seen it happen in other Carbonized applications, as well. Some report that it is caused by an interaction with Leonard Rosenthol’s OSA Menu; he is working on an update. 2/28/01

On January 19, 2001, Chris Nebel confirmed on the AppleScript-Users mailing list a reported bug in Mac OS 9.1 in which the Status property in the Remote Access configuration class defined in Network Setup Scripting does not work correctly.

On October 7, 2000, Chris Nebel confirmed on the AppleScript-Users mailing list a reported bug in Mac OS 9.0.4, which persists in Mac OS 9.1, causing your Mac to appear to freeze (actually, to slow down significantly) if you click on the menu bar after double-clicking an already-running applet. On December 10, 2000, Chris indicated that this was actually a pair of bugs, one in the applet shell and one in the default active proc, which he expects to fix for the upcoming release of AppleScript to coordinate with Mac OS X. If you encounter this obscure bug, workarounds are to let the applet’s run handler complete or terminate the applet with command-period.

There have been reports of problems using Apple Data Detectors (ADD) in Mac OS 9.1, at least on newer computers. ADD works correctly for me on a PowerBook G3 Series (Wallstreet). 1/23/01

Apple’s Chris Nebel reported that the improved random number generator in 1.5.5 also changed the seed behavior, so the manual is incorrect. In 1.5.5, if you use ‘with seed 0’, it actually resets the seed to zero. Also, it used to be that if you didn’t supply a seed at all, it would use the current time as the initial seed; now it uses zero… [Y]our best bet is to use the time as seed. In the startup of your script, say ‘random number with seed time of (current date)’. Then use just ‘random number’ (i.e., with no seed) when you need a random number. 9/22/01

Chris Nebel gave some details on formatting bugs that plague the use of long prompt strings in the Choose From List command in Standard Additions. The real problem is that choose from list doesn’t use anything even resembling a line-breaking algorithm to figure out how many lines the prompt is: it just calls StringWidth and divides by the width of the dialog (which depends on how long the list items are; see below.) This means that (1) depending on how the word wrapping works out, you might lose a couple of words off the end, and (2) because StringWidth considers carriage returns to take up no space, you get completely incorrect results if the prompt contains one. On a related point, Chris stated that the maximum visible number of items in the list depends on your screen size, actually. AppleScript 1.4 always used a list big enough for 12 items, no matter how many items you gave it. 1.5.5 adjusts the height of the dialog to show all the items that will fit… It doesn’t take the prompt height into account, so a very long prompt combined with lots of short items will push the buttons off the bottom of the screen. Chris indicated that these problems would persist in AppleScript 1.6 but might be resolved in a later versioin. 9/22/01

Some reported issues aren’t really bugs:

Some users have complained of errors when using commands in Standard Additions or other scripting additions. Others have reported, however, that this is merely a side effect of disabling the various security-related extensions that now must be active in the Extensions folder. These extensions are: Security Cert Module, Security Library, Security Manager, Security Policy Module, and Security Storage Module. Reportedly, only the Security Library must be enabled to make Standard Additions work correctly. 1/23/01

Jon Pugh has noted that the old trick of placing a dummy ObjectSupportLib folder in your extensions folder, to prevent ill-behaved installers from installing an unneeded copy of the library file, prevents installation of Mac OS 9.1. If you use this trick, remove or rename the folder before installing Mac OS 9.1, then reinstate it.

Two of the special folders recognized by the Path To command in the Standard Additions scripting addition are still named At Ease applications folder and At Ease documents folder, although At Ease has been eliminated (or renamed) in favor of the more general multiuser capability. Path to At Ease applications folder returns an alias to the Applications (Mac OS 9) folder under Mac OS 9.1, and path to At Ease documents folder returns an alias to the Documents folder, both at the root level of your startup disk. 1/28/01

I have noticed that use of the Finder’s Computer command apparently now sometimes requires placing it in parentheses to avoid a runtime error. For an example, see the script for testing system versions in the Testing Whether AppleScript 1.5.5 is Installed section, above.


The following is the full text of the announcement of AppleScript 1.5.5 from The AppleScript Team to the AppleScript-Users mailing list on January 9, 2001:

Apple announced today it will immediately begin shipping Mac OS 9.1, the latest update of Mac OS 9. Designed to ensure a smooth transition to Mac OS X, Mac OS 9.1 serves as the basis for Classic, the technology in Mac OS X that ensures compatibility with today’s application software.

The AppleScript team has been working to keep the AppleScript implementation in Mac OS 9 in synch with that in Mac OS X to ensure maximum script compatability between the two OS environments and to make your transition easier. To that end, Mac OS 9.1 includes AppleScript 1.5.5, which has similar features to the version of AppleScript that shipped in the Mac OS X Public Beta.


When Mac OS X ships March, we will release an update to AppleScript for Mac OS 9 to bring it up to date with features and bug fixes in AppleScript for Mac OS X. Two specific issues that are known in AppleScript 1.5.5 will be addressed then:

  • While AppleScript 1.5.5 improves support for Unicode text, it is limited to getting, sending, and displaying Unicode text. Other operations on Unicode text (concatenation, equality testing, word or character access) will cause an error or crash.

  • Due to an error in integrating a new feature, some features of the Read/Write scripting additions are not working. Specifically, writing a list to a text file will corrupt the text file.

Both of these issues will be addressed in the AppleScript release for Mac OS X and a corresponding Software Update for Mac OS 9.


ONLY RUNS ON MAC OS 9.1 AppleScript 1.5.5 requires Mac OS 9.1 and cannot be used on earlier versions of the Mac OS.

MOUNT VOLUME USES KEYCHAIN As of AppleScript 1.5 and later, the ‘mount volume’ scripting addition will look in the Keychain to see if there is a password for the requested server. Note that keychain passwords are stored according to the connection protocol: a key for a server accessed via AppleTalk is different than a key for accessing the same server through TCP/IP. So if you’ve created a key for that server connected via TCP/IP, you must use the TCP/IP form of ‘mount volume’ (using a URL of the form afp:// in order to have the keychain key work correctly. Similarly, if you created the key while connected to the server via AppleTalk, you must use the AppleTalk form of ‘mount volume’ to use that key.

ROUND LIKE TAUGHT IN SCHOOL In AppleScript 1.5 and later, the ‘round’ scripting addition now can take an additional enumerated parameter: ‘like taught in school’. With this parameter, numbers whose fractional parts are less than .5 are rounded towards zero, and fractional parts of .5 and above are rounded away from zero.

UNICODE SUPPORT In AppleScript 1.3, initial support was added for Unicode data. AppleScript could send, receive, load, and store Unicode strings, and convert between text strings and Unicode strings. It could not display them or perform any operations on them. In AppleScript 1.5 and later, Unicode strings can be displayed in script editors (if the appropriate fonts are installed in the system). CAUTION: In AppleScript 1.5.5, certain operations on Unicode text can cause AppleScript to crash or hang. Apple advises that if your script is handling Unicode text, you should convert the Unicode text to a string before attempting to manipulate the text in any way. Full Unicode support is provided in AppleScript 1.5 for Mac OS X and will be provided as an update for AppleScript on Mac OS 9.

Unicode support in AppleScript 1.5 and later has been improved to correctly convert Unicode strings of mixed languages to the appropriate language-specific characters if the necessary Language Kits are installed.

In AppleScript 1.4.3, an option was introduced to save scripts as Mac OS X applets. Due to changes in Mac OS X, these do not actually work on that system. As of AppleScript 1.5 and later, applets saved as Mac OS X applets will work on Mac OS X Public Beta and later.

AppleScript version 1.5 and later can now handle script files in which the script data is stored in the data fork, rather than the resource fork. All scripts that ship with Mac OS X will be stored in the data fork, but the Script Editor by default will continue to save script data in the resource fork for compatability with previous versions of AppleScript.

As of AppleScript 1.5, AppleScript and the Script Editor recognize files that end in ‘.scpt’ as script files, if they are missing other type and creation data. This should make it easier to transfer script files using media or communications methods that do not retain Mac type and creator data.

AppleScript 1.5 and later now accept all styles of line endings for the purposes of finding paragraph breaks in strings. The expression ‘every paragraph of s’ will break paragraphs correctly whether the string is Mac-style (paragraphs end with 0x0D), UNIX style (lines end with 0x0A), or DOS style (lines end with 0x0D0A).

The Script Editor in AppleScript 1.4.3 introduced a proxy icon in the title bar of script windows: an icon that represents the saved script file on disk. Unfortunately, dragging that icon to a disk folder did not move the script file to that folder; in AppleScript 1.5 and later, it does.

In Script Editor 1.4.3 and earlier, command-clicking on the title of a script window that is not frontmost would bring up a pop-up menu for that script’s path. Users expect command-dragging the titles of background windows to drag those windows without bringing them to the front; in Script Editor 1.5 and later, that is indeed what happens.

In AppleScript 1.5 and later, the Where is application ? dialog box now uses Navigation Services instead of Standard File.

In AppleScript 1.5 and later, the info for scripting addition now returns the size of the file or folder as a real number, not an integer. This accomodates files or folders that are greater than 2 Gigabytes in size.

In AppleScript 1.4.3 and earlier, certain arithmetic operations on odd integers were handled differently from the same operations on even integers, making those operations approximately half as fast. Odd integers are now treated the same as even integers, so certain repetitive arithmetic operations on odd integers will be faster in AppleScript 1.5 and later.

AppleScript documentation erroneously reports the effective range of AppleScript integers: the true range is 2^29-1 to -2^29 (i.e. 536870911 to -536870912). In AppleScript 1.3 through 1.4.3, integer addition and subtraction handled arithmetic operations at the extremes of this range incorrectly; for example, 536870911 + 1 would return -536870912. In AppleScript 1.5 and later, operations on large-magnitude integers will be promoted to reals, so for example 536870911 + 1 returns 5.36870912E+8.

In AppleScript versions 1.4.3 and earlier, asking for the middle item of an empty list (e.g. ‘middle item of {}’) would cause AppleScript to crash. This has been fixed in 1.5 and later.

In AppleScript 1.4.3, running multiple applets simultaneously could occasionally cause AppleScript to crash. This has been fixed in AppleScript 1.5 and later.

In AppleScript 1.4.3 and earlier, providind large numbers as the ‘seed’ parameter to the ‘random number’ scripting addition would have undesired effects: similar large numbers would consistently produce the same initial random value (though subsequent values would be more randomly distributed). This is especially troublesome because AppleScript itself uses the system clock as a seed value if none is provided, and most system clock values tend to be similar large numbers. In AppleScript 1.5 and later, large seed values produce more evenly distributed initial values.

In AppleScript 1.3 through 1.4.3, on rare occasions the ‘random number’ scripting addition, when given real numbers for its range, would generate a number fractionally larger than the upper bound of the range. In AppleScript 1.5 and later, all random numbers are assured to be no greater than the upper bound.

In AppleScript 1.4.3 and earlier, attempting to access item 0 of a list (e.g. ‘item 0 of {2, 3, 4}’) would produce no error and no result. In AppleScript 1.5 and later, it produces an ‘index out of range’ error.

In AppleScript 1.4.3 and earlier, creating a script with no ‘run’ handler (explicit or implicit), but having a ‘parent’ property of a script with an implicit run handler, would work in the Script Editor but crash if the script were saved as an applet. For example:

script crasher property parent : current application 
display dialog "This hasn't crashed"
end script						
property parent : crasher

Note the script has no statements other than the script and property definition, so there is no ‘run’ handler; when AppleScript tries to run it, it looks in its ‘parent’ script (‘crasher’) and tries to run its run handler. But because there is no explicit run handler in the ‘crasher’ script, it tries to get the run handler from its parent, and loops infinitely. This has been fixed in AppleScript 1.5 and later.

In Folder Actions 1.4.3 and earlier, Folder Actions would create an invisible Icon\n file in any folder you control-clicked, whether you attached a Folder Action to it or not. As of Folder Actions 1.5.5, the file is created only if you actually attach a folder action.

In Folder Actions 1.5.5 the ‘action name’ and ‘action number’ parameters of the ‘remove action from’ and ‘edit action of’ events have been changed to ‘using action name’ and ‘using action number’ for readibility. Older scripts should decompile to the new form automatically.