I create an app bundle which has a shell script as main executable.
This then runs "exec /path/to/other/executable" as its last action.
(The reason for this is that I download new executables through an update system, and I don't want to write into the app bundle which typically is in /Applications. Instead I write updates to the user directory, and aim to let the app bundle itself be just a kind of launcher)
The problem is that this makes OS X think that the bundle directory is the one in which the second executable is. This causes it to not respect Info.plist, and all kinds of badness. (If I move the real executable into the MacOS folder of the bundle, everything is peachy, but as I said this is not really an option)
This guide led me to believe that something like this was possible:
http://mjhutchinson.com/journal/2010/01/24/creating_mac_app_bundle_for_gtk_app
Here they run "exec mono ..." as the last action in their shellscript, where "mono" is a binary residing outside of the app bundle somewhere. And I assume their bundles end up being well behaved.
Is this possible then?
Related
To where a pkg installer package on MacOS should install global application data ? All users of this specific system as well as the app itself should have read and write access to this data. Atm I install it to /Library/Application Support/"mycompany"/"MyApp" and modify the permissions. Is this a good practise for all MacOS versions ?
Thank you !
EDIT:
Meanwhile I have tested to r/w access files in this directory on Sierra and Mojave. It works like a charm when I set the permissions in my custom library folder recursively with chmod -R 777 (well, less would be enough).
BTW I do this with a batch post installation shell script in the packages app here. It's a great UI based app (instead of using a bunch of command line tools). Building the pkg can be automated by a single command line: /usr/local/bin/packagesbuild /path/to/the/project.pkgproj, so integration into a flawless workflow is easy.
Yes. The only change I'm aware of related to this was in 10.7 when Apple changed the /Library folder to a hidden directory. (unlisted in finder unless specified) The path remains unchanged.
https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html
My use-case was converting a ruby application into an executable app on a mac. When I created a release on github ... meaning users would download the project as a zip and run the program.
error message: script missing from application bundle
I had all checkboxes selected when creating application as shown:
I put my answer below. This was a quick solution. However, may not be best practice. If anyone puts forth a better answer determined by the community. I will make that the answer. The answer to this question regarding a ruby script should work for other scripts Platypus turns into .app's
My solution, after app is created;
right click .app file
select "show package" contents
navigate to path ...
Contents -> Resources
copy the script that you linked to ... in my case it was a ruby script.rb
delete the script alias names "script"
rename your copied script "script" without the .rb extension.
now since the script is inside the app
it will no longer have an issue finding the script location.
I have an executable terminal program (built on MacOS from Haskell code with GHC) which runs when I double-click it in the Finder. I want to put this on my website, from which people can download and run it from their Finder by double-clicking.
Somehow in this exchange the file loses the "+x" bit so that when it's re-downloaded it can't be run by double-clicking anymore. I can still run it but I have to do "chmod +x" first. What can I do so that the downloaded file will be executable by default? Do I have to package it inside a ".app" file? Right now it's ".command".
Regardless of whether it's part of an app bundle, the executable itself needs to be… executable. To ensure executability, you should put it in a zip or dmg file, which will preserve its 'executable' flag.
If you want to make it into an app bundle, there's a simple way to do that. If the executable is named PROGRAMNAME, then just put it in a folder called PROGRAMNAME.app. Double-clicking should run the file.
If you want to create a more proper app bundle, use this:
APP_NAME='My Awesome App.app'
EXE_NAME='PROGRAMNAME'
mkdir -p "$APP_NAME"/Contents
defaults write "`pwd`"/"$APP_NAME"/Contents/Info CFBundleExecutable "$EXE_NAME"
mkdir "$APP_NAME"/Contents/MacOS
cp "$EXE_NAME" "$APP_NAME"/Contents/MacOS
chmod a+x "$APP_NAME"/Contents/MacOS/"$EXE_NAME"
App bundles will not display Terminal output or report errors, so if you need that you should keep it as a raw executable. Also, simple apps made in the above manner will not have a GUI and will appear to not respond and will exit when they finish running.
Also, if you get the following message, it might be because the executable is too short (add more characters to it) or because of quarantining restrictions (try editing the executable and save it with an app like TextEdit to make it trusted).
I'm looking for a way to package my application with the added requirement that I need to add a python script to always run on startup.
What I've been trying so far is having a .pkg that installs the .app into the applications folder and adds the python script (wrapped in a .plist launch daemon) to the user's LaunchAgents folder.
I've tried a lot of different things, but for whatever reason the python script runs fine on the command line and just doesn't work when running through launchctrl. I could go into what the problems were, but I feel that would make more sense as a separate question.
I am wondering if I should be using a different approach to achieve my goal of installing the app in Applications and having a python script run on boot. Is there a more standard solution that I am missing perhaps? Thanks.
I am trying to run our App on Mac Lion. App is built on Snow Leopard 10.6.8, packaged using package maker. We are linking dynamically to libCurl(3rd party lib). On snow leopard it works. On Lion when I install and click the app icon it fails in call to curl_easy_perform (from libCurl). But when I right click the app icon, click show package contents, and goto /Applications/MyDir/OurApp.app/Contents/MacOS/OurApp and then try to run that unix executable, then it works. I used otool to check the lib paths and they all seem correct.
Can someone help me why it fails when I click the .app? I thought .app is a soft link to the main executable. so if the executable works, then .app should also work.
Do I have to tell the path of the lib in .app? if so, how?
The dynamic linker "dyld" and related programs such as "otool" are influenced by environment variables. Environment variables can vary by process: the Finder has a unique copy of environment variable settings, and so does each shell in a terminal window.
As you can see if you run "man dyld", there are many variables that can influence the behavior of these programs.
If you're seeing different behavior from the command line than in the Finder, I imagine that at least one of the special linker variables has been set in your terminal. It is probably instructing the linker to look in places for libraries that are different from the linker's defaults (or whatever the Finder uses).
You can run "env | sort" from your terminal to see what's been set.