My goal is to add an entry to a plist file located in an application.
I want to be able to have the script ask the user to select the application, rather than use an absolute path.
From there, I want to use the “do shell command write defaults” to append a particular key inside the application bundle.
Here is what I started with
do shell script "defaults write /Volumes/Installers/MyProject/SampleApplication.app/Contents/Info NSUIElement 1"
and here is what I’d like:
tell application "Finder"
set the sourceApp to POSIX path of (choose file with prompt "Please select the application you wish to update.")
set the drill_into_app to POSIX path of sourceApp & "Contents/Info"
set new_value to "NSUIElement 1"
do shell script "defaults write " & quoted form of POSIX path of drill_into_app & " " & new_value
end tell
The problem is with the line containing "do shell script “defaults write " & quoted form of POSIX path of drill_into_app & " " & new_value” appears to modify the plist so that it is garbled when viewed in TextEdit. Any ideas?
Mikey-San’s exhortation not to change resources inside application bundles sounds like good advice!
With regard to the code you’ve posted:
There are too many ‘POSIX path ofs’ in the build-up of the path for the shell script string. Notice the interchange of slashes and colons in the intermediate and final results:
set the sourceApp to POSIX path of (choose file with prompt "Please select the application you wish to update.")
--> "/Applications/Calculator.app/"
set the drill_into_app to POSIX path of sourceApp & "Contents/Info"
--> "/:Applications:Calculator.app:Contents/Info"
set new_value to "NSUIElement 1"
"defaults write " & quoted form of POSIX path of drill_into_app & " " & new_value
--> "defaults write '/Applications/Calculator.app/Contents:Info' NSUIElement 1"
You should either build the path as a POSIX path, or build it as an HFS path and then convert it to a POSIX path.
set the sourceApp to POSIX path of (choose file with prompt "Please select the application you wish to update.")
--> "/Applications/Calculator.app/"
set the drill_into_app to sourceApp & "Contents/Info"
--> "/Applications/Calculator.app/Contents/Info"
set new_value to "NSUIElement 1"
"defaults write " & quoted form of drill_into_app & " " & new_value
--> "defaults write '/Applications/Calculator.app/Contents/Info' NSUIElement 1"
Or:
set the sourceApp to (choose file with prompt "Please select the application you wish to update.") as Unicode text
--> "Macintosh HD:Applications:Calculator.app:"
set the drill_into_app to sourceApp & "Contents:Info"
--> "Macintosh HD:Applications:Calculator.app:Contents:Info"
set new_value to "NSUIElement 1"
"defaults write " & quoted form of POSIX path of drill_into_app & " " & new_value
--> "defaults write '/Applications/Calculator.app/Contents/Info' NSUIElement 1"
You don’t need the Finder for these actions.
Not all application files are bundles, so if this script were a good idea, you’d need to include a check for a trailing slash or colon in the initial path to make sure that the user had chosen a suitable application.
I haven’t tried using the script on any of my own apps (!), but I’d guess, in view of the malformed path in the shell script, that it hasn’t done anything at all to the plist. Also, not all plists are text, so it may not be the script that’s responsible for the garbling. I don’t know if either of these points applies here, but you may like to keep them in mind.
Unfortunatly, I do not have control of the development of the application. I only have a say in the modification of the plist. I agree that modifying a plist within an application is not recommended by Apple, however the design is out of my hands.
Thanks everyone for your help!! I spoke with a software engineer and it appears that TextEdit doesn’t handle plists in Tiger. However, Panther version of TextEdit handles these fine. I confirmed this by dragging an apple plist file into Tiger’s TextEdit and sure enough it is garbage.
I’m running 10.4.6 Intel.
For the simple reason that every copy of that application will thereafter be different from every other. If, for example, you put any machine details in a preference inside the application the app will not work if you move it to any another machine. That’s why ~/Library/Preferences exists.
Ok, it is for simple reasons of use, I believed that Mikey-San and Nigel wanted to speak about the possible dangers or risks when we handle files inside the package of an application…
Lastly, they are choices of development, if it there does not have a danger or risks particular, there is no reason to be deprived to manage data in the package of the application, it is sometimes necessary for a wandering use…
There are a LOT of reasons you SHOULD NOT MODIFY AN APPLICATION’S INTERNAL RESOURCES, one of which being that you are never guaranteed that a user has permission to do so. This is why we have home directories we are guaranteed to be able to write to, as well as the user defaults (preferences) system to handle some aspects of this for us. Your development team is clueless if they’re writing apps that modify themselves.
Do. Not. Make. Configuration. Changes. To. Internal. Application. Resources.
The applications that I am modifying are being modified prior to even being installed on a users system. The script I’m writing is used silently by Install VISE during it’s build phase, so the script is really part of the development process, not to be ran by the end user.
Why do you shout?
We exchange just opinions, it is not worth while to irritate you.
Ok, so, if I wish to use an application starting from a key USB, in displacement among customers for example, which solution recommend you to store the information collected thus?
Would you have links, or references, about the recommendation of Apple on this subject?
I’m not yelling; I’m being obvious for anyone who reads this thread and gets lost in the sea of words here. Think of it as waving a giant flag. To be 100% honest, I’m more concerned with developers coming here and not getting that message, and thus writing bad applications that make it into the wild, than mistakenly offending someone on the Internet.
risc:
You didn’t say that earlier. You can probably just use different files with different build targets within Xcode. You might be able to script the build process. I’m not really sure.
Fredo:
I could post a dozen links, or you could simply read Apple’s developer documentation. It’s an overall theory of good application design that is made clear in the different API documentation. (They talk about this in the Core Foundation documentation in at least one place.) You’re never guaranteed the ability to write to an application package, and if you DO write changes to an application package, you force other users to use the data that you’ve modified. This is bad design. CS 101.
Applications are to be installed, read from, or deleted. Never written to, unless you’re performing a software update operation.
If you want to take an app from computer to computer with a USB key, you should be storing your data in a separate file that your application reads or can export to. (Core Data, for example, makes this very easy.)
Ok, I understand, but i think that to put the sentence in bold would have been sufficient…
You are right, on the principle, Apple indeed suggests placing the various resources files and the data files at places planned especially for them, but certain things remain a little ambiguous. for example this sentence: “All of the resources and data files required for an application to run should reside inside the application bundle” (Where to Put Application Files).
Now, certain data, without being really essential to operate correctly an application, them are nevertheless useful.
In this case, do we have to insert them in the package of the application?
Can we do it, anyway, without betraying the recommendations of Apple?
I already developed some programs (AppleScript-Studio) which manage a certain number of data directly inside the package of the application, this never yet posed the least problem, but I from now on will better reflect on the relevance of this method.
Thank you, in any case, to have drawn our attention to this aspect of things, which I was personally unaware…
