Brew sandbox fails for apps using FileManager.SearchPathDirectory.applicationSupportDirectory
#5966
Replies: 2 comments 1 reply
-
|
This isn't possible. Formulae are only installed into the Homebrew prefix. You will be better off creating a cask. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the formula installs into the homebrew prefix. The problem is the test, which breaks when the tool tries to write to the That link doesn't explain what a cask is, but my understanding is that casks are generally for pre-built binaries or GUI apps, neither of which apply here. Are you suggesting a cask as a workaround to get around the sandbox limitations for the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Output of
brew configOutput of
brew doctorDescription of issue
I am developing a formula to build and install a mac command line tool. On startup, the tool writes settings to the user's
Application Supportdirectory usingFileManager.SearchPathDirectory.applicationSupportDirectoryper mac best practices.This works fine in real life, but it fails in the brew sandbox. The brew sandbox remaps
$HOMEto a directory in /tmp, but it does not remapFileManager.SearchPathDirectory.applicationSupportDirectorywhich still points to/Users/brew/Library/Application Supportwhen runningbrew test. The sandbox rejects any attempt to write toApplication SupportwithI tried symlinking
ln -s #/tmp/.../StateSmith.Cli /Users/brew/Library/Application Support/StateSmith.Clibut it does not fool the sandbox, thelnfails withOperation not permitted.What is the best way to test this app, which writes to
Application Supporton startup?Beta Was this translation helpful? Give feedback.
All reactions