Re: osascript - path to me
Re: osascript - path to me
- Subject: Re: osascript - path to me
- From: Timothy Bates <email@hidden>
- Date: Sun, 19 May 2002 13:05:11 +1000
- .mxoez?+: O?W^h1]g}IB\WO2A=6#`2^rL?jAu,r8EcKz@UG.r.7[$&Ym;j8^Wp;/KAlcda MO/$} $"[ c?\#d@cuN
- 9+kli1>@: KaeEcbn$EIG)tY@^[7y`lyrI<4S(cnqzmTD&4<tTkuNR(4dweN}SUlDX/X^c>"
>
> how can a system of bundles help with shared resources?
>
> 2 scripts both expect to find 20 sound files in a "Resources" folder beside
>
> them. They use the same resources (about 20 MB worth).
>
You should put your sound files folder in "/Library/Application Support",
>
"/Network/Application Support" or "~/Library/Application Support". That's
>
what these locations are for.
I (and most others deploying scripts that need other bits and bobs) can't do
that for several practical and absolute reasons.
Firstly, there are dozens of scripts involved, many will use resources with
conflicting names. So I would have to create a hierarchy of support folders
in the support system.
I then have to hard code in the script where its resources lie in this
hierarchy of support folders. But of course now I can't make a single object
( a folder containing the script and its "Resources" and "Results" folders)
that the user drags into my app's scripts folder. Why not? Because these
scripts are not installed by an installer - they are just drag and drop by
the user. So I would need the script to be able to install its resources,
but to do that I need a copy of the resources and ... Guess what: I would
need to know the path to myself ...
All of these ideas are unbelievably error prone (what happens when something
moves? Or the script name is changed?) and hard (now I need to coordinate
the installation of things in two places instead of one AND take care of
naming conflicts AND update this in hard coded info in the scripts) and
opaque (currently the user knows exactly where the resources are, in these
new scenarios they are either invisible (in a bundle) or in some arbitrary
locaiton in a hierarchy in the system folder, that they will have to open
the script in order to find). It is totally impractical. And all for why?
Because someone wants path to me to return the path to the Script Editor
instead of the script. But they have zero reasons for this.
What next? Maybe when my script says "my handlerx()", script editor will
grab this and return a "Script Editor cannot continue handlerx() error?
(forget the fact that a perfectly good handlerx() exists in my script, me is
me: the Script Editor - surely you mean me? Don't you ...
Maybe the error should just be "I am sorry Dave, I can't do that"
>
With regard to "path to me", remember that scripts aren't file system
>
objects. To see that, ask yourself what
>
>
run script "path to me"
A script need not be a file system object, but it is always the case that it
is either a direct file object itself (90%) of cases, or is owned by a
script which IS a file object: the other 10% of cases.
So, "path to me" can always return the path to a file, which will be
unambiguous and predictable.
>
what should
>
echo "path to me"| /usr/bin/osascript
>
return, if not the path to the application executing the script.
Given the number of emails generated, I think that almost no one using
AppleScript has a clue what should happen with anything on the command line
:-) :-)
But ... For my money, this should return the "/usr/bin/osascript"
It is the same as asking what should happen in this case
A script file called "theScript" contains the following
Script innerScript
whereAreWe()
return path to me
end
end
InnerScript's whereAreWe()
What happens when we run this? Easy:
--> path to theScript's location in the file system
tim
_______________________________________________
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.