Installing into an app's resource folder?

I’m trying to create a script to install an update to a file within a sub-folder of a program’s resource folder. Sounds simple?
I know this practice is no doubt frowned upon particularly with the newer OSX systems. However this updater is intended for two older ‘Open Source’ sister apps that have not been updated in 5 to 6 years.

The 2nd part of the script runs on error & will show an option to find the app if it does not exist in apps folder. (Not everyone ‘in past at least’ always installs apps into the apps folder. Personally I’ve used a small apps partition for 3rd party apps since my G4 days.)

tell application "Finder"
	try
		set apps_path to (path to applications folder from local domain) & (path to resource "CX.app" in directory "J")
		duplicate H to apps_path with replacing
	end try
end tell

What am I doing incorrectly for installing the file into folder J of CX.app’s resources?

Hi,

the main error is you can’t concatenate (&) two alias specifiers. Only strings can be concatenated.

Assuming H is a Finder object oder alias specifier, otherwise put the keyword file in front of H

set apps_path to (path to applications folder as text) & "CX.app:Contents:Resources:J:"
tell application "Finder"
	duplicate H to folder apps_path with replacing
end tell

While developing scripts it’s always recommended to comment out or remove any try blocks to get error messages

Or alternatively:

set theApp to path to application "CX"
set apps_path to path to resource "J" in bundle theApp
tell application "Finder"
	move H to apps_path with replacing
end tell

Many thanks both StefanK and Shane Stanley. Both approaches work fine except for one side-effect.
Shane’s approach is able to find the app regardless of where it is. The side-effect however is it launches the app each time.
Stefan’s approach doesn’t do that.

interesting, I see that here, too, under Yosemite. I don’t think it always used to be the case.

from my experience path to application causes the app to launch at least since Leopard

Using the keyword application followed by a static string will try to launch the application, no matter how you use it. The difference is that when using application events it starts the application at compile time, otherwise it will be launched at run time. This Includes earlier versions of Mac OS X.

However there are exceptions like Microsoft Excel for instance.

Thanks – that’s quite a while! I’m surprised I didn’t notice.

Not quite:

tell application "iBooks"
	running --> false
end tell

Like I said there are exceptions including Apple’s own shell applications. Maps, FireFox, QuarkXress, Textedit, just to name a few, requires just as Safari to be launched at compile time.

Hello.

I realize there may be differences between theory and practice here, but:

So, I really guess that Shane meant by using the running property,that an app doesn’t necessarily launch because it is addressed in a tell block.

On the other hand, it makes sense that the event path to application “Some App”, “awakens” “Some App”, in order to resolve the path to it, so that the path to the correct app, the one that will be launched, is returned, this can’t really be done by “dry-testing”, since launchservices is the one that determines which app will be launched. The problem is if there are more apps with the same name with different short version strings, lingering on different places locally or if there are Apps with the same name, but with different version numbers in the name, residing on different places locally.

Edit
My version of Excel (2008) becomes activated, when I run the snippet below:

set mpath to (path to application "Microsoft Excel" as text)

I would also believe that it would happen with every App, that are addressed through path to application since it is a Standard Additions command. But, there may be things I don’t know of. :slight_smile:

The same goes for “TextEdit”, I am talking about run time and not compile time.

Edit

I have Excel 2008 and not 2004. :slight_smile:

Right.

And yet Cocoa does this very thing:

use framework "Foundation"

set theNSWorkspace to current application's NSWorkspace's sharedWorkspace()
set thePath to (theNSWorkspace's fullPathForApplication:"iMovie") as string
set thePath2 to (theNSWorkspace's URLForApplicationWithBundleIdentifier:"com.apple.iMovieApp")'s |path|() as string
return {thePath, thePath2}
  -->	{"/Applications/iMovie.app", "/Applications/iMovie.app"}

No launching involved.

That is disturbing, I’m not sure how to interpret that, but I’ll give a guess; it either means, that the NSWorkspace messages, doesn’t count for the fact that there may lay newer unexecuted apps on the disk but goes directly for the last one executed, that probably lies within the launch services database, or something new has happened, that automatically registers new apps, as they enter the file system.

I have lived in the belief, that an app had to be executed once, in order to register it. Newer unexecuted apps, wont be “discovered” by those NSWorkspace messages. On the other hand, the NSWorkspace messages, may be a safer approach than path to application, since they won’t start up something never started before, that may have been “sneaked” onto the system. :confused:

I’m on Mavericks still, maybe things have changed for path to application on Yosemite?

For the second part of the script which runs on error from the above portion, this is what I’ve done (which works fine):

set f1 to (choose file with prompt "Please find CX")
set destinationF to path to resource "J" in bundle f1
		
duplicate H to folder destinationF with replacing

Is this ideal? Is there a better way to achieve this. Should I be looking at app’s ID?
Is there a way to filter out all file or app results in the prompt search window except the app in question so no accidental selections are possible? I ask this because I selected the sister app as a test for selection error & it was updated.

What’s about that?


repeat
	set cxApp to (choose application with prompt "Please find CX" as alias)
	tell application "Finder"
		set appNameIsCX to name of cxApp is "CX"
		set jResourcesFolderExists to exists folder "Contents:Resources:J:" of cxApp
	end tell
	if appNameIsCX and jResourcesFolderExists then
		tell application "Finder" to duplicate H to folder "Contents:Resources:J:" of cxApp with replacing
		exit repeat
	else
		display dialog "The application seems not to be CX.app" buttons {"Cancel", "Try it Again"} default button 2
	end if
end repeat

Wow that’s one great script StefanK, thank you very much.

I found I needed to change

set appNameIsCX to name of cxApp is "CX"

to “CX.app” for it to be recognised.
Problem solved. :slight_smile:

My point exactly. Launching the application is not caused by ‘tell’ or a command like ‘path to’, it’s caused by the application specifier itself. This is caused by the fact that an application specifier needs the dictionary of the application if it doesn’t have one yet, for Safari it is required to launch the application and send an (ascr/gdte) event and reply back with the scripting dictionary in it. However the exception I mentioned has become more and more a rule. Not all applications use the gdte event and therefore doesn’t need to be launched. But that’s not what your quote from ASLG meant.

I’m using 2011, who doesn’t launch.

The reason is probably that more and more applications use the .sdef technology.
From the AppleScript 10.5 Release Notes:
AppleScript can now read an application’s sdef directly. This means that an application with only an sdef no longer needs to be launched to get its scripting terminology.

By the way, the running property is not required to be wrapped into a application tell block, this is sufficient


set excelIsRunning to application "Microsoft Excel" is running

I guess the information is retrieved from NSRunningApplication, not from sending an Apple Event to the application

Hello.

I can confirm that Safari needs to be launched, in order to get at its dictionary, when running is tried to be used from within a tell application Safari block, and that it it isn’t when something like if running of Application “Safari” is used.

Damn, this means that all my rather far flung speculations in the posts above are probably invalid. :slight_smile:

Correct, the example applications meant earlier have have scripting suite/terminology files, old carbon resources files or one or more sdef files but haven’t defined them in the info.plist (OSAScriptingDefinition key).