Re: Osascript: Portable Path to Icon
Re: Osascript: Portable Path to Icon
- Subject: Re: Osascript: Portable Path to Icon
- From: has <email@hidden>
- Date: Tue, 12 May 2015 22:26:47 +0100
Oakman wrote:
> I have an osascript that displays a dialog using:
>
> set iconPath to ((path to applications folder as text) &
"foo.app:Contents:Resources:OsascriptDir:IconsDir:foo.icns")
> The osascript will reside in the "OsascriptDir" folder. How can I
code the icon path so it is portable so no matter where the end user
puts the app it will always show the icon in the dialog? Apparently
'path to me' does not work in osascripts.
Works here (10.10), e.g. Saving the following plain text script in my
home folder, then running it in Terminal:
#!/usr/bin/osascript
return posix path of (path to me)
gives:
mac:~ has$ osascript test
/Users/has/test
Likewise when saving it as a compiled .scpt file:
mac:~ has$ osascript test.scpt
/Users/has/test.scpt
You are using `osascript` to execute an actual AppleScript file, not
just passing lines of AS code directly via `-e` options, yes?
If you're on an older OS version, it may not work anyway since whether
it works or not is completely app-dependent[1]. `path to me` only works
in apps that support this "feature" either by loading the script via
OSALoadFile() (or its Cocoa equivalent) or by calling OSASetInfo() to
assign a path to an already-loaded script. If the app doesn't tell the
script which file path it was loaded from, AS has no other way of
knowing this information, in which case `path to me` reverts to its
original undocumented behavior, which is to return the path to the
*process running the script* instead of to the script itself. [2]
Anyway, the following commands should do near enough what you want; just
replace the example bundle ID with your own:
set iconPath to path to resource "foo.icns" in bundle (path to
application id "com.example.foo")
It's not ideal; e.g. if you've two copies of the same app on the same
machine, there's no guarantee this code won't look in the other one. But
if you can't supply your .app bundle's path to your script any other way
(e.g. by having your calling code pass the bundle path to your
AppleScript as an extra argument) then it's probably good enough.
HTH
has
[1] You'd need to check the AppleScript release notes to see when
`osascript` started supporting `path to me` (though Apple is bad at
keeping these notes either up-to-date or complete so it might not be
mentioned at all).
[2] Longer explanation: `path to me` translates to `path to null` when
packed into an Apple event, which StandardAdditions in turn interprets
as `path to current application`. (Object specifiers always use `null`
to indicate the root object, which in AppleScript is your script, and in
a scriptable application is its application object.) Over time,
AppleScripters accidentally discovered that using `path to me` in an AS
applet would usefully return the path to that applet, but this was an
entirely accidental, unintended behavior and not an actual documented
feature. They would've got exactly the same result using the [correct]
`path to current application` command, but somehow `path to me` entered
AppleScript lore and got stuck there, even though it didn't really do
what users thought it did.
I think it was circa AppleScript 2.0 that `path to me` actually became
an official feature, which is a polite way of saying the AS devs hacked
the AppleScript component to intercept `path to` commands _before_ they
were dispatched to StandardAdditions. This allowed AS to handle `path to
me` commands as a special exception itself, returning the file value
that was previously set by OSALoadFile()/OSASetInfo() (if available), or
else passing it onto StandardAdditions to proceed with its original,
undocumented behavior (if not).
It's a hacky, confusing, and unpredictable mess, in other words. Short
of throwing out the whole OSA mess and rebuilding it right from scratch,
the sane, sensible, logical thing would've been to leave the old,
broken, undocumented behavior well alone, instead adding another option
to the `path to` command (e.g. `path to this script`) that returned the
correct path if known or reported an "unknown" error if not. But
apparently returning a totally different and entirely wrong value
instead is perfectly normal on htraE or wherever the heck it is
AppleScript comes from these days, so who are we poor users to judge...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden