I used Packages to create a.pkg installer for a Mac OS X LaunchDaemon.
During install, I would like the user to be able to provide a few values for the configuration file. The resulting file is a simple text configuration file which will be sourced by a shell script when it is run.
Is there some tool that would make it easy to create a fill-in form with a few text fields? This would be presented to the user during install, and then save the values provided (or make them available to a postinstall shell script).
If there is no such tool, I guess I could do it with the shell and a few reads in a Terminal. But in that case, how to start that interactive shell script from my postinstall script?
Not sure, you can do it with the Distribution.dist XML file. It is JavaScript, but I have not looked though the definitions, since it comes out all garbled on my current version of Safari.
The easiest would be to create a small applications dialog run from the script, which you have full control over.
Related
I am trying to make an executable link in an email for mac, so I don't want it to be a .exe file. I tried using a .command file so that it will run when you click on it, but it said it's from an unidentified developer and I don't want the recipient to have to change their security settings. So I want to use a .tar.gz file that has a shell script in it.
The problem is that when you click the link, it downloads but doesn't automatically run the shell script. I need to know when the file is unzipped so I can run the shell script inside. Does anyone know how to do that?
It isn't reasonable to expect to be able to run an arbitrary script on user's machine, without him explicitly asking to run it (e.g. if all he's doing is downloading a file, or opening a non-executable file).
If the OS allowed that, it would be a serious security breach.
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 using Mac 10.8 and latest version of Package Maker. My product destination path (Install Location) contains our Product version.
Eg. Test/1.1.0.1/Sample.
We have planned to automate the process. We will increase the build number in each automation. So I need to change the Version number in destination path in every automation. I am using below command to make the Packages using Terminal.
PackageMaker –v –d Test.pmdoc –o TestSample.pkg
Is there any option to pass the version number from this argument? Shall we implement this using a preinstall script? Please provide same samples if any option from Preinstall Scripts, since I am new to shell scripts. Please help me to solve this issue.
Personally I found it much easier to do this:
copy the package folder from a common location (ie /project-redist-master)
modify package contents as desired (see below)
create package
If you need more personalization, for example the version number somewhere inside the package, I found it most convenient to simple search & replace strings. For example you could write ___PROJECTVERSION___ to any text or resource file (ie pmdoc) where the version number is used. Then, before creating the package, run a little tool (bash script, personally I prefer writing Cocoa command line tools) that searches and replaces such placeholder strings. That tool would also get the version string from somewhere, for example a version.h header or the changelist number from source control.
PackageMaker always was buggy has hell, and got deprecated with Mac OS X 10.6 Snow Leopard.
I recommend to use pkgbuild together with productbuild.
It looks like xcode's $PATH environment setting is different from my user shell environment.
Where does xcode get the $PATH setting from and what's the best way to append to the search path?
if you're writing a Run Shell Script build phase, you can just do:
PATH=${PATH}:/opt/local/bin
or whatever inside the script content.
There's some confusion in these answers, as some of them are trying to solve the $PATH for the built executable being run by Xcode. But the question is about Xcode, implying that it's about the build process itself.
For example, in a Build Phase Run Script step that runs an executable installed by Homebrew. It's not a good idea to hard-code the build process to include a path that is specific to one build machine (New macOS versions come out, new developers join the team, etc.)
The problem has multiple layers:
Changing $PATH in bashrc/zshrc/profile takes effect on shell sessions, but not in macOS applications
To solve this, you can set the PATH for applications using:
sudo launchctl config user path $PATH
You will then need to restart your machine for the change to take effect. You will need to run this again if you change your $PATH.
(This came from a comment on GitHub.)
Xcode by default does not use the system $PATH, and replaces it with its own sanitized value
This is solved by changing a User Default. This probably has some risk, since Xcode does this sanitization to ensure that its own build tools are used, and if you have executables with the same name in other places, they might be run instead. Caveat emptor!
defaults write com.apple.dt.Xcode UseSanitizedBuildSystemEnvironment -bool NO
And it looks like this gets reset on every restart of macOS, so be prepared to issue this command every time you restart.
(This part came from this answer.)
The easiest solution is to add the PATH variable in Xcode.
PATH=${PATH}:/usr/local/bin
This applies for OSX 10.7 and earlier ONLY.
XCode gets its environment variables the same way as other OS X processes, from ~/.MacOSX/environment.plist.
Check developer.apple.com/qa/qa2001/qa1067.html for details on how to set things.
In Xcode 5 you can add your PATH as a variable to either a target or the project settings.
Add a custom variable with the +sign on the top of the page
Edit the name of the variable to be PATH and add your preferred value (e.g. /usr/local/bin for a default install of homebrew.
If you are talking specifically about the executable search path environment variable named PATH, then there are a few places that it is set:
In your shell settings if it is a command line tool. Depending on your shell, this could be ~/.cshrc, ~/.profile, ~/.bash_profile, etc.
In the environment.plist file that was mentioned earlier.
If you are in a debugger, then it is whatever gdb uses. I believe that gdb will read commands from ~/.gdbinit if it exists.
XCode lets you set environment variables within the Info page for executables.
This is an update for later versions of macOS and Xcode as things have altered. This is with Xcode 11.0 and macOS 10.14
The biggest issue is that ~/.MacOSX/environment.plist does not get read now.
Build Settings
This means that if in the build you need the PATH set, e.g. for external builds and they run executables there is no simple solution. /etc/paths does not seem to be read either.
The solution is as in #GhostLyrics answer to add the PATH variable in Build Settings. However as noted in comments Xcode will not just use that value but it puts its own values before that. Also it does a straight textual substitution and so you need to also add the separator that PATH uses i.e. the : (colon). The value I have added is :opt/local/bin I also found that you can only do this for a target and not at the project level.
Run Shell Script
This is the simple case as in this answer
PATH=${PATH}:/opt/local/bin
or whatever inside the script content.
Alternatively put this change in your non login shell starter file e.g. ~/.bashrc ~/.zshrc
Running the executable
This is done in the Schema in the Run portion.
Set PATH in the environment variables as stated in answers here. Note I have not tried this and I am not certain how much of the PATH needs setting.
Xcode doesn't look at your shell path environment.
Have a look at NSProcessInfo; and do an NSLog to see what comes up.
If you want a path to apply to all graphical programs you need to set up the ~/.MacOSX/environment.plist. as described.
The recommended way to set the environmen variables are actually in /etc/paths and etc/paths.d although these are also not picked up by Xcode.
I asked about this here.
Nothing was working for me in XCode 7.
You need to set the PATH variable in XCode schemes.
Found the solution at:
Where to set environment variables for app?
Try opening your xcode project from the terminal, this worked for me: open some.xcodeproj
Instead of opening xcode and then loading the project or double clicking on it.
I know... silly
I am distributing a Java program where I want a double-clickable file to run
java -cp MyProgram.jar;MyLib.jar my.program.Main
On Windows I simply distribute a .bat file, for *nix an executable .sh file. Problem is, double-clicking the .sh file just opens it up in a text editor on Mac. What should I do for Mac?
On mac, there is a specific extension for executing shell scripts by double clicking them: this is .command.
For Java applications on Mac, you really should use Apple's Jar Bundler (in the Developer Tools/Applications/Utilities folder; really a symlink to /usr/share/java/Tools/Jar Bundler). It lets you make a proper OS X double-clickable app, including setting preferences for e.g. using the Mac toolbar, JVM version, graphics system, OS X app metadata and classpath/resources.
You can use a .sh (Shell Script), after all MacOSX is Unix!
The answer about using the Jar Bundler tool is correct, but if you want to use a .sh file, make sure the unix permissions are set properly to something like 755 with CHMOD, and make sure the first line contains the path to a shell installed by default on Mac OS X. Also note that even with the +x bit set, it may still ask the user whether they want to open it or run it.