I know this is not an applescript question but I think this is probably a reasonably good choice for asking this question.
I will have a command line tool and some ruby scripts that are included inside an application bundle that isn’t installed via the App Store. The application and disk image will be code signed for gatekeeper. This is only for 10.9.
The application should be installed as expected from the disk image into the Applications folder.
My question is about the command line tool and the ruby scripts. I will want the command line tool and the ruby scripts to be included in the unix search path so that the full path to run these commands will not be necessary. The application is really only a user interface for setting up the command line tools (1 of the options below, or perhaps offering a choice of options) and in future a monitor for the Launch Agent.
What is the appropriate way to get the command and scripts included in the unix search path?
I could install the tools in /usr/bin or /usr/local/bin or add symlinks to the command line tool and the scripts. If it was just the command line tool and not the scripts I think this might be the solution. The number of ruby scripts is not that many so this solution might work for them now, but this might end up being unwieldy as a larger number of ruby scripts is developed.
I could install or just add a symlink to the command line tool and do something else with the scripts, but for some reason I find this solution messy because it would still make sense to add to the unix search path the folder containing the ruby scripts.
I could just add to the unix path for the user a path to the folder in the application package containing the command line tool and scripts. This doesn’t seem right to me, (adding to the users unix search a folder in an application) secondly it leaves the ruby scripts hidden inside the application package which makes it harder to discover them so that they can be copied and used as a starting point for developing custom ruby scripts by the user. It might work for Applescript programmers who would access the command line tool or ruby scripts via do shell script since you would have no interest in writing your own ruby scripts.
I could create a folder in the users home folder and copy the command line tool and ruby scripts to that folder, and add that folder to the unix search path.
I would be interested in your thoughts and what you think would be the solution that would work best for you as a scripter.
I consider the best practice to put whatever commandline stuff you use for your app in a directory inside your bundle for obvious reasons: Then there can’t be any conflict. I am not totally sure if this is the practice Apple endorse, but IMHO, the only sane thing to do if you care about your app working at all times.
There is still a wildwest out there, there is no clear boundaries between package repositories, for instance homebrew doesn’t respect macports, and moves their whole repository aside. The other thing is the avid user that compiles/installs his own command line tools, or utilites that fetch and compile code on their own.
The only way to play safe is to keep it in your own bundle.
Putting it in a Library/Application Support directory of your application is the next best thing, because it is more exposed there. Having it all in your bundle also gives you the greatest uninstall experience.
The way you have written your reply though, I get the impression that you are thinking of the command line tool and scripts as helpers to the application. In this case the application itself is really just there to make it easy to get the installation of the command line tool and scripts right so that there is no complication for accessing them by scripters like yourself. What would work best for you as a scripter using these tools? Perhaps think about it from the perspective of making the image magic command line tools trivial to install and for you to use, and for them to be installed by customers of the scripts you wrote.
If I’ve misinterpreted your response just let me know.
Homebrew, works for most people, but when it hasn’t the muscle to deal with the “edgy” corners. And then you still have the conflicts, with other package managers. My package manager of choice is much more complicated, and robust → macports.org. You can turn a macports package into an installer that installs software with package manager easily!
If I were to install a separate commandline tool at a user just for the user, then I’d make a directory ~/opt/bin in ($HOME) for binaries, ~/opt/share/your-pkg-name for any datafiles. - dotfiles for the user (config file for your utility starting with “.”) in the $HOME directory.
if it is to work for all user account, then I’d have any commen datafiles put into then I’d make /usr/local/share/your-pkg-name , and your binaries in /usr/local/bin.
Maybe you would have to add /usr/local/bin to the paths but I think it is default. For single user installment I know positively that you’d have to add ~/opt/bin to the path. (This is something I have figured out, for avoiding overwrites by package managers.).
Firstly could you follow up to my reply to your first response in this topic. That would be appreciated thanks.
As to Macports, like home-brew it looks like it needs Xcode and developer tools installed.
I really want to avoid that path. Gigabytes of download just so that the installation tool can work to install a tool that is at most a few tens of megabytes in size. I want the users experience for installation to be as trivial as possible.
You mention the users opt directory. I’m assuming that there is nothing special about a directory called opt, is there a convention or anything like that for naming a directory opt and the sub directories (~/opt/bin) for a single user or is that just the convention you use. (I know the convention for bin is where binaries go, and lib is where libraries go).
The appropriate way for single user installment is to add a statement like PATH=$PATH:yourpath into the users ~/.bashrc file, but the filename can vary according to what shell the user uses.
A much safer approach, is to sit down and read the docs for launchd, and figure out how you can set individual settings with it. Hopefully you won’t need an admin password for this.
And for the rest of it. I only find it acceptable to have the command installed somewhere, and not using any symlinks or anything, as long as it isn’t a framework provided with the machine. (Personal Opinon).
I have already written that it is a very good idea to create opt for option in the users homedirectory, and put it there, since this is a place the otherwise rude package managers stays clear of.
The other advantage, is that if the user updates his operating system, and copies over his old homefolder, he’d soon be good to go again, (if the path is set in some shell-init file.)
I’m using launchd because it is a daemon designed to launch other services like LaunchAgents, LaunchDaemons and XPC Services. I’ve got it successfully starting my LaunchAgent. I didn’t read anything in its documentation or the documentation for launchctl when getting my LaunchAgent up and running about using it to set persistent settings like the unix search path for the terminal.
I mentioned sym links because I noticed that TextWrangler has installed sysmlinks into /usr/local/bin which point to command line tools within it’s own application bundle. Because of this I thought this might be an acceptable approach.
I just noticed that they had changed the path when I updated the command line tools of TextWrangler yesterday, I didn’t check and see that they were symlinks.
Maybe that is a way to install tools that goes with your app, that is endorsed by Apple nowadays then. I doubt that BareBones would do anything not endorsed by Apple. But then again, in their case, they have used those names for a long time.
My personal preference is, that things are where they are, and not some alias to something somewhere else, when it comes to command line tools, it makes it more complicated when you have to nest up things. That is my preference as a user, it might be the fact, with this new reality an operationg system is, that I also at some point will adopt that scheme as a developer. But as a user/administrator, I prefer not to deal with symlinks to executables, unless it can’t be avoided.
One immediate advantage of using symlinks into some known directory, is that you don’t have to adjust the path.
The disadvantage is, that your symlink may be removed, if Apple decide to update the whole contents of that directory during a system update. Now that isn’t much of problem for TextWrangler, since you can just “install” the command line tools from the TextWrangler menu. It may be more clunky if you don’t have a Cocoa app to “install” the utility from.
