I don’t know if it’s of any interest, but a script bundle/app can get its own path:
set myPath to (path to me)
(I’ve used this to access a file I’ve put in the app’s Contents/Resources folder, FWIW)
But, if I write
Property myPath: path to me
myPath
then the script just gives the path to the AppleScript Editor.
Hi drjlevi6,
If I run this in AppleScript Editor:
set my_path to (path to me) as string
display dialog my_path
without saving, I get the Editor. If I save the script, then I get the path to the script.
gl,
kel
Hello.
Yes, it works great when you have saved it, thanks. (I admit I wasn’t aware of this, and it removes a kluge I have made to get at the bundle’s resource folder when running from within Script Debugger.) Thanks. 
This helps when accessing a resources bundle from within a script, I am not sure it evades the other problems with using me, As me will be your editor when run from it, and the app, when the app is run standalone (this holds for current application as well.)
Hi McUsr,
It is strange how it works with ‘path to me’, but not properties:
set my_name to name of me
display dialog my_name
Maybe it has to be in a tell block. Strange.
gl,
kel
I was just reading about how you can tell smart animals have self awareness by using the mirror test. But I digress again.
‘path to me’ is a scripting addition … Can’t figure it out!
Hello.
The path to command seems to be smart enough to be able to diversify, as the current applescript environment, cannot, (that would be intro spection), it makes sense that you need a path to command to do it, as it is external, from Standard Additions Osax. It can better see stuff from the “side-line” : probably figuring out what to return, by looking at the filename.
By the way, there seem to be no deprectation of osax’s in Maverick.
I just reinstalled mountain lion and that was a lot of work. Need to create a new installing routine. Any updates yet on Maverick? I wonder if the question was answered.
The path to command is a Scripting Additions command, just go into the Scripting Additions dictionary and see for yourself.
Once I have an operating system in place, (and I do a lot of tinkering), then I rather not swap it with another, before I swap for good. My tinkering is rather well defined, but there are still things, like the postfix server, and the dns server, and probably some more stuff I have forgotten, like syslog, and others, that needs to be reinstalled. Maybe cloning is the way to go, And only use time machine for transfering.
There are a lot to be read about Maverick at Apple.com, but you’ll need to sign in with your deveoloper id to get at it. (I actually spent several hours reading). I like the App-nap feature best so far, but everything they have done makes a great sense. Especially the ability to tag files from finder at least. This is going to be great.
I am playing with FileMaker Pro, and it is fun fun fun! (It is a very good program as far as I can see.)
The more I use it, the better I like it, you can do pretty much with it, that you can do with any relational database system, and it is easy to use as a backbone in your AppleScripts. It is something totally different from database events, I can assure you of that!
Congratulations on your new toy. 
I’m still waiting for the game Civilization 5 to get an update that works. In jaguar, Apple came up with an update that sped up Civ 3. Maybe Maverick might have a fix in it. I’m not too hopeful though.
What’s good about computers is you can have so many toys!
Have a good day!
Hello.
I stay clear of Civ, too many sessions, that started up as “need a little break”, and ended up in regret some 36 hours later, has learned me that.
(I do have freeCiv, and freeCol here, but I avoid starting them up. )
I play Pacman X, which is free, and works great under Snow Leopard, it is over in just a few minutes, and at least I get bored after 3/4 rounds. Perfect!
You can download Filemaker Pro, for a free 30 day trial from filemaker.com by the way.
This is a great article about scripting FileMaker Pro that is still valid.
As you’ve seen, ‘path to me’ returns the path to AppleScript Editor until the script’s saved and has a file of its own.
The other thing is that the initial values of properties are set when the script’s compiled. So if you use the ‘path to’ function to set the initial value of a property .
property myPath: path to me
. it’ll be executed when the script’s compiled and the value of the property will always be whatever the result was at the moment of compilation. But when used with a run-time command like ‘set’ .
set myPath to (path to me)
. ‘path to’ is executed when the script actually runs and its result is more up-to-date. This is obviously a more sensible context in which to use it.
Maybe I’m wrong but my understanding is that if we want to have the path to the script in a property, the best way is to use :
property myPath : missing value
set myPath to (path to me)
KOENIG Yvan (VALLAURIS, France) samedi 13 juillet 2013 11:23:21
Hello.
No big deal, but I think the best approach is to just use
(path to me)
, if you are not tying up the (path to me) to a property for referential purposes.
And this was a really great tip for me, since I had an unbelievable klu(d)ge for achieving the same.
I am absolutely sure that Stefan has mentioned this once or twice. but I haven’t seen the utility before now.
If you choose a property because the path needs to be persistent and follow when the file moves or changes you can use alias because they’re persistent too.
Hello.
That should work as long as you don’t share the script with someone in compiled form.
Hi,
That’s a good point McUsr. The app needs preferences to match the path with the user.
gl,
kel
Hello.
It is fairly easy to trap that in a try - end try block, as long as there are awareness about it.
Properties is often the best solution, if you want to communicate the apps path with other script objects, I think it soon becomes faster too, if you use (path to me) some times in your script.
By the way kel, there is a message for you in your in-box.
That’s not an issue in this case. Shared script objects have already wrong paths so you can’t use path to me in that situation. A solution will be setting a property after you load the script:
shared script file
property pathToMe : missing value
if not exists pathToMe then set pathToMe to path to me #default
main script
set theScript to load script file theFile
set theScript's pathToMe to theFile
It is an issue if you share a script with the a property set, to path to me, also as an alias, as it will break a script meant to run, if you share it in compiled form.
I never meant that you would set a "path to me property"it in a script-object, I meant that it was good to have it specified in the caller, and maybe send it along, or have your loaded objects access the property by some convention.
I meant a bigger issue overshadows the alias issue, not that the issue is away