A good description of the differences and usage of these two useful command line tools.
Tips & Tricks for Mac Mgmt, by JohnD.
Nice article about how to setup Permissions and Access Control Lists (ACL – i.e. permissions on steroids ;-)) in OSX.
Another article from Ars Technica (although specifically about 10.4 Tiger, things should not be that different in 10.5 Leopard – it’s UNIX after all).
And a some what related article about File Sharing in OSX can be found here.
In Mac OS X v10.4 Tiger, Apple introduced a new system startup program called launchd. The launchd daemon takes over many tasks from cron, xinetd, mach_init, and init, which are UNIX programs that traditionally have handled system initialization, called systems scripts, run startup items, and generally prepared the system for the user. And they still exist on Mac OS X Tiger, but launchd has superseded them in many instances. These venerable programs are widely used by system administrators, open source developers, managers of web services, even consumers who want to use cron to manage iCal scheduling, and they can still be called with launchd.
Playing with launchd in the terminal is not for the faint hearted, so Lingon (from the creators of the well known OSX text editor Smultron) is a very nice GUI that allows anyone to set and manage jobs! 🙂
commandlinefu.com is the place to record those command-line gems that you return to again and again.
It includes a very nice explanation about when and how /etc/profile, ~/profile, ~/.bash_profile, ~/.bash_login and friends are loaded up!
And a more detailed explanation on how PATH is constructed in OSX can be found here. In summary, it goes like this:
- /etc/profile is the default startup script for Bash, which is what I’m using. (If you’re using a different shell, then you may have a different startup script). /etc/profile calls /usr/libexec/path_helper
- path_helper first calls /etc/paths and /etc/manpaths which contain the initial path environment variables. /etc/paths contains system-wide defaults:
/usr/bin /bin /usr/sbin /sbin /usr/local/bin
- path_helper then looks for files in the directories: /etc/paths.d and /etc/manpaths.d and appends the paths found there. On my system, /etc/paths.d and /etc/manpaths.d contain a file named X11 which simply contains the paths for X11.
- After /etc/profile has called path_helper, it then looks for /etc/.bashrc. I have a bashrc (no “.”), but my bashrc only has stuff in it specifying the bash shell prompt (
- Bash next looks for ~/.bash_profile. This is the file where you’ll set file and directory colors and could also be where you place your Path environment variables. Obviously, ~/ represents your user directory, so your settings will only be valid for your user.
- Next, bash looks for ~/.bash_login. I don’t have this on my system so it’s ignored in my case
- next, bash looks for ~/.profile which I did have on my system and is the file that XCode wrote to.
Another file that can contain path variables is ~/.MacOSX/environment.plist. This sets environment variables, including paths, for gui applications. I’m not using it on my system so don’t have anything to say about it.
So, what that all means is that instead of exporting PATH environment variables to a .profile or .bash_profile in a user account directory, you (or your application) can, instead, make PATHs global by adding text files to the /etc/paths.d and /etc/manpaths.d directories.
If you need to control the order of a path, then try this:
Add a line PATH=”” before the call to path_helper like this in /etc/profile:
if [ -x /usr/libexec/path_helper ]; then PATH="" eval `/usr/libexec/path_helper -s` fi
All that said and done … I’ll continue using ~/.bash_profile because it’s got that warm fuzzy familiarity. Personal preference, as always.