Re: osascript - path to me
Re: osascript - path to me
- Subject: Re: osascript - path to me
- From: Chris Espinosa <email@hidden>
- Date: Tue, 21 May 2002 11:30:41 -0700
Let me start by saying that I appreciate the original request: that a script should be able to get a reference to the file that originally contained it, so it can load resources that are in known locations relative to that file. This is a worthy and useful goal and is already accomplished in the leading development environments. I'm explaining here why "making 'path to me' work correctly" isn't the right way to achieve that goal.
There are three things interacting here: the application that finds, loads, and asks AppleScript to execute a script; the AppleScript engine itself; and the 'path to' scripting addition in the Standard Additions package.
When you execute a script that contains the statement 'path to me', here's what happens, step by step:
- The application loads the script from some place it knows about: perhaps a file, perhaps (in the case of applets) a resource in the applet file. Perhaps the script is dynamically compiled on the fly, or is fetched from a database or from the Internet, so it isn't associated with a file at all.
- The application sends the script to AppleScript in compiled or uncompiled form. Note that there is no defined way for the application to associate the script with the file it came from, if any, so at this point the script is an independent entity.
- AppleScript first evaluates the 'me' special variable. As defined in the AppleScript Language Guide, the purpose of 'me' is to distinguish the script's properties from the current Tell block's application properties. When AppleScript sees 'me' in an object reference in a Tell block, it doesn't send an Apple event to an application; it tries to evaluate it locally. 'me' only has meaning to AppleScript, not to applications or scripting additions.
- The 'path to me' statement invokes the 'path to' scripting addition, but since 'me' is meaningless outside of AppleScript, it sends a null value instead. By an unfortunate coincidence, the null value is also used to denote 'current application', and 'path to' can accept application references, so 'path to me' is interpreted as 'path to current application' -- which is not what most scripters expect.
It's simply not possible to make the 'path to' scripting addition return the result you desire. In the first place, when the application compiles a script, it does not pass on any information about the file from which the script was loaded. So the AppleScript engine has no knowledge whatsoever about the location of the script file. (Even if it did, there would be ambiguity: do you want the compiled script file or the uncompiled source file?) In the second place, 'me' is defined to have meaning only inside a script, and has no meaning for scripting additions, so 'me' can never work with 'path to' (or 'open for access' or 'info for' for that matter).
(The fact that 'path to me' returns a misleading but somewhat useful result is a bug, and because it's somewhat useful. changing it would break scripts that do use it. For example, since applets are a single file that contain both the application and the script, 'path to me' returns the path to the script, because it shares a file with the application).
Each AppleScript development environment has the choice to create its own script packaging scheme, thus also the responsibility to provide access to that packaging scheme. FaceSpan, Script Debugger, and AppleScript Studio all provide ways to do this. Script Editor doesn't, because it offers no packaging scheme. (If you use ResEdit to graft resources into a script file, you're on your own.) Applications that execute scripts like Script Runner, OSA Menu, Script Menu, FileMaker Pro, Folder Actions, etc. generally require scripts to be put in a known place, so you can put the script's resources in that known place as well and encode that knowledge into your script.
It might be interesting for us to define a "script bundle", a package that contains one main script, a number of other scripts that share the script's context, and a known location for resources, and change AppleScript to store the location of the bundle in a property of each script, so your scripts could have a reliable way of finding their bundle resources. We could then change all of the things that load and execute scripts (Script Editor, Script Runner, the applet shell, Script Menu, Folder Actions) to be able to load script bundles, so you could have one consistent way of referring to script resources. We'll look at when we can schedule this work, and try to get the developers who load and execute scripts to support it.
I hope this explanation has shown that we understand the problem, that we believe the solution is not to try to make 'path to me' work as desired, but are thinking about more comprehensive and useful solutions to the problem.
Chris Espinosa
Manager, Components & Scripting
Apple
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.