I have Firefox 10.6.3 installed on Mac OS X Snow Leopard from the DMG. I can run firefox from the terminal using /Applications/Firefox.app/Contents/MacOS/firefox-bin. However, if I create a symbolic link:

sudo ln -s /Applications/Firefox.app/Contents/MacOS/firefox-bin /bin/firefox

then it refuses to run, or at least display. When I issue "firefox" from the terminal, I can see the process in top, but never get the GUI to appear.

ls -lr /bin/firefox 
lrwxr-xr-x  1 root  wheel  52 May  5 15:19 /bin/firefox -> /Applications/Firefox.app/Contents/MacOS/firefox-bin

Any ideas?

migrated from stackoverflow.com May 5 '10 at 19:48

This question came from our site for professional and enthusiast programmers.


Mac OS X applications use relative paths to find other files in their application bundle. I couldn't reproduce your issue, but the Firefox started via symlink didn't have a Dock icon or menu bar for me. Other applications printed the following error:

2011-03-05 15:20:03.083 appname[25356:903] No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting

The proper way to achieve what you want is to create a script that calls the executable, or better (if you don't have multiple different versions of Firefox running for whatever reason), use Launch Services:

#!/usr/bin/env bash
open -a Firefox

This launches the Firefox instance registered with Launch Services. The advantage is that you can move the application bundle around and it'll still work, or the Firefox folks could rename the binary and it'd continue to work anyway.


I noticed something like this a while ago (Firefox 3.6.3 on Mac OS X 10.4: it displays its main window, but not its menu bar; all keyboard input goes to the most recently active app, not Firefox). I replaced by symlink with a script:

exec '/Applications/Firefox.app/Contents/MacOS/firefox-bin' "$@"

I liked the symlink better, but not enough to track down the problem. There are some possibly related bugs in Mozilla's Bugzilla (like “Starting firefox, menu's don't appear and text input is disabled”), but nothing that looked like an exact match.


Is this perhaps a problem of the executable linking to shared libraries using relative paths? This has prevented symbolic links to exes working for me in the past on OSX 10.6.3.

You can check for absolute or relative paths in the definitions using,

otool -L /Applications/Firefox.app/Contents/MacOS/firefox-bin

Things like @loader_path in the embedded library paths often won't work when the exe is called from a link. You can change relative paths in the exe using install_name_tool, as per this answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy