A while back, I installed git to download some random open-source code that I’ve since forgotten about. I noticed this when hacking on my .bash_profile paths to add ImageMagick. I saw that git had been inserted into my path and I couldn’t figure out how. I thought they had been screwing around with my system bash scripts but no - something else was going on…

It seems MacOS X has a little known improvement to UNIX life on the desktop. Instead of adding paths login scripts, you can put them in the /etc/paths.d directory. Add a unique text file whose contents are the path to add. You don’t get control over the order of loading, but that (usually) shouldn’t be a big deal. There is also a /etc/manpaths.d as well.

I normally don’t like to put third party stuff in / directories. That is where things get lost when upgrading. I don’t know if I should use this or not, but I don’t want to forget about it.

Perhaps this is it?

applicationWillFinishLaunching:
application:openFile:
applicationDidFinishLaunching:
<run main loop>
applicationShouldTerminate:
reviewUnsavedDocumentsWithAlertTitle:cancellable:delegate:didReviewAllSelector:contextInfo:
closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:
<didReviewAllSelector>
applicationWillTerminate:

I may need a Perl category here shortly.

Once again, I have had to re-find the following information about doing custom installations of CPAN modules. Here are the details…

$ PERL5LIB=$HOME/lib/perl5/5.8.7:$HOME/lib/perl5/site_perl/5.8.7

$ perl Makefile.PL PREFIX=~/lib

$ make
$ make install

OK, this is neither a MacOS X nor a programming item. But I’ve had to look it up twice now. To kill a long-running or runaway MySQL query, follow these instructions:

show processlist;

kill <id>;

A new addition is required to build Universal Binaries in 10.5. Add “-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -mmacosx-version-min=10.4″ for a 10.4 build.

I know this blog is supposed to be about programming. But we programmers sometimes like to squirrel away files in odd places. The standard MacOS X file open dialog doesn’t let you get to those places. Or does it?

I remember long ago finding a keyboard shortcut that would pop up a little window in a file open dialog that would let you type in a path for a directory. Somehow, I managed to find it again. This time, I shan’t forget it.

The keyboard shortcut is Shift-⌘-G

There are some areas of MacOS X where Cocoa just doesn’t do it. Either the Cocoa version doesn’t have all the options you need or Cocoa just doesn’t have the function. In many cases, Apple has quietly updated some ancient MacOS Toolbox function to work in MacOS X. Here are a few of these:

FSFindFolder and FindFolder - Helps you find all those “special” directories.
All of Navigation Services - For when NSOpenPanel just doesn’t cut it.

It is possible to write command-line applications using Cocoa. However, you have to be careful. The only way to test such an app is by ssh’ing into your own box. You can’t just use the Terminal. Some APIs can only be called if they have access to the console or if root is running them. You won’t know that until you run your command-line app via ssh. if You get a message such as:
kCGErrorRangeCheck : Window Server communications from outside of session allowed for root and console user only
INIT_Processeses(), could not establish the default connection to the WindowServer.Abort
That is what’s going on.

The fix is simple, just don’t use the offending code. The offending code could be anything. I haven’t found a definitive list yet. Clearly anything related to the Window Server is out. Also verboten is anything related to the Process Manager.

To compensate, there is the little-known function “NSApplicationLoad” that will bootstrap enough of the Cocoa framework to run things that normally do not work until “awakeFromNib” in a GUI application. If you don’t want to call “NSApplicationMain”, go ahead and call “NSApplicationLoad”, create your own autorelease pool, and go forth on the command line.

Dynamic libraries are difficult on any platform, MacOS X is no different. Basically, there are two kinds of dynamic libraries, those that a vendor installs, and those that you want to ship with an application.

If the dynamic libraries are installed by your OS vendor, no big deal. Those are the dynamic libraries you have available. If the dynamic libraries are installed by some other application, you may have a problem. If all you ever want to do is run programs, those libraries will be fine. If you want to develop your own programs, you will have problems. If the program you want to write depends on that vendor library, you are requiring that anyone who uses your program also has that library installed, preferably in that location. Even worse, you can’t reliably test your program because you now have a non-standard, system requirement that you can’t control. You could always use an installer to install your own system-level shared libraries. Users like that. I know I do. That is what is known as DLL-Hell.

For a developer, the way to solve this is by using the install_name_tool in MacOSX. This tool goes into an application and changes the path for a dynamic library. The idea is that, as one of your build scripts, you copy any required dynamic libraries into the application bundle of your program. Then, use install_name_tool to change the location of that library to @executable_path. Now, your application is linked against itself. It can be distributed to anyone.

Run “otool -L” against your executable to verify that any dynamic libraries are either system libraries or @executable_path libraries.

The downside of this is that a user could have 100 applications, each with the same dynamic library. Perhaps the OS is smart enough to only load one of them. I hope so. This is not quite DLL-Hell, more like DLL-Purgatory. There really is no better solution. You don’t want a user linking their own dynamic library with your app. You don’t want to link with a static library. That would make the application difficult to update and eliminate any possibility of OS efficiency.

Things today are designed to use dynamic libraries. No point in fighting it. Learn to live with it. Just don’t let that cause you to ship applications with odd dependencies or complicated installers. Bundle everything into a standalone app that is easily uninstalled.

Perhaps I should take my own advice and re-work Privoxy into an application bundle. That would be an excellent idea.

Once again today I found myself struggling to remember a certain obscure Unix command to inquire about what files were linked to an executable. That means it’s time to post to Etreblog again. So, for the record:

file 

ar t 

ldd 

otool