AppleScript 1.8.1 for Mac OS X 10.1.2 is the version of AppleScript installed by Software Update 10.1.2 on Mac OS X systems. It is primarily intended for use in developing and running applications with AppleScript Studio.
The main features of this release are support for AppleScript Studio development and debugging, and access to UNIX functionality from any script.
This release also fixes 13 problems in AppleScript that are present in AppleScript 1.7 on Mac OS X.
Version 1.8 is installed by the December 2001 Developer Tools Update and is very similar to version 1.8.1. The only difference is that the problem of applets crashing when certain multimedia software is installed is fixed in version 1.8.1.
AppleScript 1.8.1 can use scripts developed for any version of AppleScript from 1.1 through 1.7, any scripting addition created for AppleScript 1.5 or later for Mac OS X, and any scriptable application for Mac OS 7.1 or later.
A script created with AppleScript 1.8.1 can be used by any version of AppleScript back to version 1.1, provided it does not use features of AppleScript, scripting additions, or scriptable applications that are unavailable in that version.
| FEATURES: |
Standard Additions
To provide better access to Mac OS X's underlying UNIX functionality from AppleScript, Standard Additions 1.8 adds a new command and extends the functionality of another.
The new do shell script command takes a string as its direct parameter and executes that string in a UNIX shell. The text can be anything from a single command with parameters to a long script. The results of the script execution ("standard out") are returned as the result of the command; if there is an error (or no output), the error output ("standard error") are returned as the error message and can be processed in an AppleScript on error handler.
Note that the environment in which a shell script is executed is a separate process in the user's process group, and does not have a terminal set up, so commands that require interaction (vi, top) will not function. There is no way at present to direct any information to "standard in" of a shell script.
Note also that do shell script uses the sh shell, which is different than the default tcsh shell used in the Terminal. command paths and environment variables are different in sh; you'll need to adjust your shell scripts accordingly.
The system attribute command has been extended to provide information on the user's environment variables. These are set up at user login time and cannot be altered. If the direct parameter to system attribute is a four-character Gestalt code, it is executed as in Standard Additions 1.7; if not, it attempts to get an environment variable by that name, returning either the value of the variable or an empty string. (Note that system attribute now will not fail with an error; it simply returns an empty string.) If called with no parameters, system attribute returns a list of all currently-defined environment variables.
AppleScript Language
The do shell script command and the scriptable Terminal allow AppleScript scripts to
execute strings of text as UNIX shell scripts. Many interesting shell commands act on files,
and require POSIX-style file paths as input parameters. To create POSIX-style file paths from
AppleScript file objects, the property POSIX path has been added to the
file and alias classes.
(All file types, including file specification
and file reference, support this property.)
Its use is straightforward:
set this_file to choose file
POSIX path of this_file
The do shell script command and the scriptable Terminal allow AppleScript to execute
UNIX shell scripts and get the results as strings of text. Frequently these strings are
the pathnames of files in the UNIX format, i.e. starting at "root" with directory names
separated by forward slashes. To convert these "POSIX paths" into an AppleScript file object,
you can use the POSIX file object:
set this_path to "/etc/passwd" -- or any path returned from do shell script
set the new_path to POSIX file this_path
--> file "Mac OS X:etc:passwd"
AppleScript's default formatting has been changed in AppleScript 1.7 and later.
If you have already used AppleScript on a given machine, you won't notice this change.
The change will only be seen if you do any of the following:
| BUG FIXES: |
AppleScript Language
AppleScript 1.7 could not perform certain operations on file names or file paths that contain certain characters (such as accented characters like é). This has been fixed in AppleScript 1.8. [2816363]
In AppleScript 1.7, references to the process class of the Finder on a remote machine did not work. This has been fixed in AppleScript 1.8 and later. Note that you need to be running Mac OS X 10.1 or later on the target machine, and Mac OS X 10.1.2 or later on the machine executing the script. [2775419]
With AppleScript 1.6 and 1.7, applications that attempted to convert Unicode text to plain text would get an error (though AppleScript itself could perform such conversions successfully). This prevented older applications from being able to use information (such as file names) that is now supplied as Unicode text. This has been fixed in OpenScripting.framework version 1.8 and later. [2816500]
Certain development environments can create scripts whose parent is an application object, rather than a top-level script. Attempting to get any parent properties of such objects (including the information returned by OSAGetScriptInfo) would cause AppleScript to crash. This has been fixed in AppleScript 1.8. [2755096]
AppleScript Applications: Applets
In Mac OS X version 10.1 and 10.1.1, installing certain multimedia software (such as Roxio Toast or QuickTime 5) would cause all applets to crash on launching. This has been fixed with AppleScript 1.8.1 [2785067]
With AppleScript 1.7 in Mac OS 10.1, applets that are set to show their startup ("splash") screens occasionally failed to do so. This has been fixed in AppleScript 1.8. The applications do not need to be recompiled or re-saved. [2756226]
Standard Additions
In Standard Additions 1.7, if the path to command was requested to return the path of a folder that did not exist (such as scripting additions folder from local domain), it would fail. In previous versions, and now in 1.8 as well, it creates the folder and returns the path to the created folder. Note that if the user does not have authorization to create the folder (e.g. is not an administrator and requests a nonexistent folder in the System domain), the operation will still fail. [2751119]
In Standard Additions 1.7 and earlier for Mac OS X, the description of the choose application command stated that it allows users to choose a running application. On Mac OS X it allows users to choose any application, running or not. [2785713]
In Standard Additions 1.7, using the mount volume command with an AppleTalk server name in a on server parameter did not work. This has been fixed in Standard Additions 1.8. [2656820]
In Standard Additions 1.7, the store script command would crash if no in parameter was supplied. This has been fixed in Standard Additions 1.8. [2782590]
Previous versions of Standard Additions improperly list the parameters for the store script command. Both the direct parameter (the script) and the in parameter (the file) are optional. If the script is omitted, an empty script is stored in the file; if the in parameter is omitted, the user is prompted for a file name. [2784735]
The path to command in the Classic environment of Mac OS X 10.1.1 and earlier returns the path to the script when asked for the path to an application. This has been fixed in the Classic environment of Mac OS X version 10.1.2. [2747285]
The choose application command in the Classic environment of Mac OS X 10.1.1 and earlier fails with a memory full error (-108). This has been fixed in the Classic environment of Mac OS X version 10.1.2. [2804619]
Commands
The osacompile command would fail if provided with an -i parameter specifying a nonexistent file. In Mac OS X 10.1.2 it is more lenient and issues a warning, but continues compilation. [2796415]
| KNOWN PROBLEMS: |
Some applications that create and/or execute scripts (such as Script Debugger) will occasionally crash when trying to get certain information about a script. If you need to use these applications, do not upgrade to AppleScript 1.8. [2811897]
AppleScript 1.7 could not open scripts saved on Mac OS 9 by any version of AppleScript if those scripts contained references to applications on remote machines. AppleScript 1.8 and later can open those scripts, but omits the first two characters of the host name in the application's URL. You must manually correct the application URL and recompile the scripts. [2781523]
On some rare occasions (often during recording), the name of an application in a tell statement is changed to "AEServer.". Change the name back to the original application name and recompile the script. [2822232]
AppleScript Studio applications occasionally crash while being debugged. [2793351]
In AppleScript 1.6 and earlier, the alias and file classes previously used Macintosh File System functionality to interpret pathnames. As a side effect, expressions like alias ":" and file (myPath & "::") would do interesting things, like return an alias to the directory containing the current application, or navigate up a file hierarchy. In AppleScript 1.7 and later, alias and file support long and Unicode file and path names, using Core Foundation functionality to interpret pathnames, with different side effects. On Mac OS X, alias ":" specifies the root directory, and on both Mac OS 9 and X, sequences of multiple colons are ignored. To get the path to the current application, use path to me; to navigate up a folder hierarchy, use the Finder's container property. [2833120]
The osascript command-line tool will truncate output text if it contains a null character. [2827241]
Developer Release Notes
In Mac OS X 10.1 through 10.1.1, scripting additions would have their initialization function called at application launch time, but their termination functions would not be called when the application quit. Scripting additions that used system resources would not get a chance to release those resources. In OpenScripting.framework version 1.8 and later, every scripting addition termination function is called when an application exits. [2811696]