Write into Package Contents

[brian_donovan]

Hi, I am trying to do my own app with applescript, its a simple thing so that is not the problem, the problem is that I am trying to add a preference file into it and then have the applescript read and write from/to it. But as any application, the file must be part of the application, so I left clicked my applescript app and selected “Show Package Contents” and add my preference file there, I then added a string of code to my applescript to write any values into it… but I guet an error “file not found”.

Here is the script:

set MyPath to "HD:Users:brian:Desktop:MyApplication:DenyList"
set myFile to open for access MyPath with write permission
write "some text" to myFile
close access myFile

Is there a way of making this work?

Thank you for your time

Brian

[StefanK]

Hi,

you’re trying to open a literal string, not a file. Add file or alias
A more reliable syntax to write text to disk is

set MyPath to "HD:Users:brian:Desktop:MyApplication:DenyList.txt"
try
	set fileReference to open for access file MyPath with write permission
	write "some text" to fileReference
	close access fileReference
on error
	try
		close access file MyPath
	end try
end try

PS: it’s not recommended to write preference files into the application package.
Better use the standard ~/Library/Preferences folder or ~/Library/Application Support/[application name]

[brian_donovan]

Thank you!

[Shane_Stanley]

@StefanK

~/Library/Application Support/[application name]

FWIW, the advice these days is to use ~/Library/Application Support/[bundle ID], which is probably a good idea with scripts, too.

[brian_donovan]

The application support folder asks for a password to create a file in it. not cool

[McUsrII]

Hello.

Are you sure you are in your home folder? That is, that the folder you are not having rights to, is something along /Users/BrianDonovan/Application Support, and not /Library/Application Support? ~ means your home directory, like in /Users/BrianDonovan, just in case.

[McUsrII]

@Shane Stanley

@StefanK

~/Library/Application Support/[application name]

FWIW, the advice these days is to use ~/Library/Application Support/[bundle ID], which is probably a good idea with scripts, too.

Hello. I am actually quite releaved to see the app folders there, and not bundle id’s, I think bundle ids for user applikasjons, in the Application Support folder, defies some of Apple’s policy, of making things non techincal, where they shouldn’t be. I have some folders, there are two of for two different versions of that app, and that is an arrangement I live well with. The stuff that is in the Application Support folder, is ultimately mine, so why shouldn’t I be able to read it out right away, instead of having to painstalkingly get the bundle id of the app, before I can identify its settings in the Application Support folder?

But for for System software, that also stores stuff in the Application Support folder, like quicklook, and the like, am I much more tolerant towards bundleid’s, that is for agents and such, that aren’t end user applications anyways.

[Shane_Stanley]

@McUsrII

I am actually quite releaved to see the app folders there, and not bundle id’s, I think bundle ids for user applikasjons, in the Application Support folder, defies some of Apple’s policy, of making things non techincal, where they shouldn’t be.

I suspect the change was made to ensure uniqueness. Two apps accidentally sharing the same folder could potentially have unfortunate results.

[McUsrII]

@Shane Stanley

@McUsrII

I am actually quite releaved to see the app folders there, and not bundle id’s, I think bundle ids for user applikasjons, in the Application Support folder, defies some of Apple’s policy, of making things non techincal, where they shouldn’t be.

I suspect the change was made to ensure uniqueness. Two apps accidentally sharing the same folder could potentially have unfortunate results.

That is a reasonable approach really, but look at it the other way around, say “Some App”, just hangs for me, and I look a round to find the folder with the preferences file that I want to delte. Say I never cared to figure out the company name, or I don’t remember it. Then I must do some work to figure it out. Wouldn’t it be much better to have AppVendors, read the contents of the folder up front? Besides that, I’snt an appname something that is supposed to be unique by marketing laws etc?

I’d actually go for an approach then, with Appname, version number, and company segment of bundle identifer, but Id like to start looking for the Appname, which the Folders are sorted on, than the app segment of the bundle identifier, which the folder well, not directly can be sorted on.

I think bundle identifiers are a much better choice for IOS apps, because I think that there, the users have limitied access to clean up their preference files.

We’ll see how this plays out in the long run, this a pro for buying apps outside the appstore really, if this becomes a strict rule, and not just a recommendation.

[Shane_Stanley]

@McUsrII

That is a reasonable approach really, but look at it the other way around, say “Some App”, just hangs for me, and I look a round to find the folder with the preferences file that I want to delte. Say I never cared to figure out the company name, or I don’t remember it. Then I must do some work to figure it out.

No, you just type the name in the Finder window search field for Application Support – bundle IDs generally include the app name. It’s certainly no harder than tracking down .plist files in Preferences, and people seem to have coped with that.

It’s just a recommendation, and not many non-iOS apps follow it. Duplicate commercial app names are pretty rare, so it’s no big deal. But I’m not sure people are quite so fussy when it comes to naming applets.