Do shell script with code-signed application

Hello all,

Not really understanding why this is happening, but I am having an issue with my AppleScriptObjC application that only arrises when I choose to code-sign the application. The application has a “do shell script” that returns a list of files from a directory. Here’s what the code looks like:

Without code-signing:

set launchAgents to (do shell script "ls ~/Library/LaunchAgents")

This results in a properly assigned variable “file1, file2, file3, etc.”

With code-signing:
I get the following error:
/Users/x74353/Library/Containers/IFx.Plisterine/Data/Library/LaunchAgents: No such file or directory (error 1)

For some reason, the bundleID of my app is inserted in-between Library and LaunchAgents. Is this a sandboxing thing? I have my entitlements file set with the following: (array)
/Library/LaunchAgents/ (item 0)

Any ideas? Thanks in advance!

Yes, that’s a sandboxing issue. For a sandboxed app, home is in the app’s sandbox, and your path has been adjusted accordingly. A sandboxed app has no access to the normal Library’s files.

First off, thanks for your response!

From what i have read, it seems like by using entitlements, other files outside the sandbox can be accessed. Is ts not possible to use these temporary entitlements to directly access ~/Library/LaunchAgents ?

I can understand how the use of a tilde in the ‘do shell script’ directs to the app’s home and not the user’s home. Is there a way, using AppleScript, to specify the user’s home folder (and then /Library/LaunchAgents) ?

Something along the lines of:

set homeFolder to (path to home folder)

What is really strange to me is why the app works fine when sandboxed (but not code signed), and has the issue only when using code signing.

So I tested this in my app and found that, as expected, “set homeFolder to (path to home folder)” has the same result as using a tilde. I also found that specifying an absolute path in the “do shell script” does not result in this error. So for example:

do shell script "ls /Users/x74353/Library/LaunchAgents"

The above works without issue and returns the list of files.

So now, the issue is accounting for different user folder names across different computers and/or accounts. My first thought was to use do shell script “whoami” – but does whoami always return the user folder name or just the short name? I know in 10.8 that a user can’t create a new account with a short name that contains spaces, but I seem to remember in previous versions of OS X this was possible. Example: adminuser VS. admin user.

A temporary entitlement is just that: temporary. And just because you can set one up in your app does not mean it will be accepted in the App store – many won’t.

The first thing you should do is see if there is an alternative. What are you looking in ~/Library/LaunchAgents for?

Something like?

set homeFolder to do shell script "echo $HOME"


set launchAgents to every paragraph of (do shell script "ls $HOME/Library/LaunchAgents")

I am looking in ~/Library/LaunchAgents because my app allows loading / unloading of launch agents. The “list” that is generated from “ls ~/Library/LaunchAgents” is checked against “launchctl list” to figure out what is loaded / unloaded. Also the app allows the creation of simple, time-based launch agents, so the app needs write access to ~/Library/LaunchAgents as well. I’m not too concerned with whether it gets rejected or not, this is more of a learning process for me. Thanks for all your help!

I can’t imagine how there would be any alternatives to using entitlements to complete these tasks…

And for anyone who is curious, “set launchAgents to every paragraph of (do shell script “ls $HOME/Library/LaunchAgents”)” results in the same error as mentioned above. Seems the only way I can figure out how to get this done is with the following:

set shortName to (do shell script "whoami")
set launchAgents to (do shell script "ls /Users/" & shortName & "/Library/LaunchAgents")