Mac OS X Power Tools

Because Unix is used on wildly different equipment, and because Unix users have traditionally customized their software much more than Mac users, Unix software is normally distributed in source kits. Source kits are basically raw programming code that users can then compileto run on their own system. (Compiling is a process by which source code is processed to run on a particular platform or operating system.) Increasingly, developers have been adding support for Darwin to their source kits, bringing a wealth of "new" software to OS X.

Under OS 9, software was normally compiled by the developer and packaged with an installer before distribution to the user for installation. Unix software installation is a bit more complicated; because of this, there are actually three methods of installing software on OS X:

• OS 9 style Traditional pre-compiled software with an installer or script (like Apple's software), or as an application package that takes advantage of drag-and-drop installation.

• Traditional Unix style Source code designed for manual compilation and installation by the user.

• Newer Unix style Scripted porting.

In Chapter 7, I covered software distributed via the first method. Here's some information on the others.

• Source code kits Source kits typically include the software's source code, documentation files, a configuration script, and a Makefile, which actually provides the procedure that should be used to compile and install the software. Each kit is different, but the most common procedure for installing software from source kits is the following (using a fictional software program-1.2.3):

  1. Unpack the software: tar xzf program-1.2.3.tar.gz <RETURN>. Most source kits are distributed as tar archives that are then compressed with gz; such compressed archives are called tarballs, and may also use the .tgz suffix. You can also expand such archives using StuffIt Expander. Tarballs generally unpack to create a directory named with the program name (program-1.2.3) that contains all the files needed to build the program. The tar program normally creates this directory inside the current working directory.

  2. Change to the newly created directory: cd program-1.2.3 <RETURN> (or cd ~/Desktop/program-1.2.3 <RETURN> if you used StuffIt Expander to unpack the tarball to your Desktop folder).

  3. See what you've just unpacked: ls -F <RETURN>. Documentation filenames are often all caps.

  4. Read the documentation for the software: more README INSTALL <RETURN> (or whatever the documentation files are named). Find the exact procedure to follow, along with any desired options to specify in the next step.

  5. Configure the Makefile: ./configure <RETURN>. This command runs a configure program included with most kits that inspects your system and creates or adjusts theMakefile as necessary. The ./ is necessary because the configure program is in the newly extracted directory, which is probably not listed in your PATH.

  6. Compile the software using instructions in the Makefile by typing make <RETURN>. The make program follows a procedure in Makefile (capitalization may vary) in the current directory.

  7. Install the compiled software: sudo make install <RETURN>. The make program runs again—this time following a different procedure within the Makefile—to copy the previously compiled files to their final locations.

     Note

     Compilation can usually be done as a normal user, but the actual installation of the compiled software generally requires making changes to system directories like /usr/local/bin, which requires root-level access (sudo). This is the reason Apple's Installer often prompts for an administrative password.

  8. Update the list of available commands: rehash <RETURN>. The csh-based shells keep an internal list of known commands so they don't have to scan all the directories in your PATH each time you execute a command; rehash updates that list.

  Note

  In an attempt to avoid conflicts with core OS software installed in /usr/bin and /bin (for user-level programs) and /usr/sbin and /sbin (for root-level programs), most third-party programs are installed in /usr/local/bin. Unfortunately, /usr/local/bin is no longer in the default PATH Apple supplies. This means that if you install software from a source kit, you may need to add /usr/local/bin to your PATH. You can do this in one of two ways: (1) type setenv PATH $PATH":/usr/local/bin" <RETURN> in Terminal; or (2) add the line setenv PATH $PATH":/usr/local/bin" to your ~/.cshrc or ~/.tcshrc file.

• Scripted porting If the procedure described above looks like a lot of trouble to you, scripted porting may be the answer. In this scenario, a group of people figures out how to compile and install several pieces of software on a given operating system, and then generates scripts for a porting program that allows that program to follow their procedures and build the software automatically. These people are called porters, because to port software is to alter it so it works on a different platform. On OS X, Fink (http://fink.sourceforge.net/) is by far the most advanced and popular porting system. At the time of this writing, Fink provides almost 2,000 ports, and installation of Fink packages is normally as simple as typing fink install packagename <RETURN>. The Fink User's Guide says it best: "Fink is a distribution of Unix Open Source software for Mac OS X and Darwin. It brings a wide range of free command-line and graphical software developed for Linux and similar operating systems to your Mac." Fink can download source files from the Internet, patch (modify) them to work on OS X if necessary, compile the patched software, and then install the compiled software inside the Fink directory (normally /sw).

Because it's so useful, I'll show you how to use Fink in the next section.

I mentioned in the Introduction that you should install Apple's Developer Tools on your Mac—either using the CD that came with OS X or your Mac, or by downloading it from Apple's Developer site. For advanced Unix work, the Developer Tools aren't just recommended—they're required. Apple's tools include a current compiler set that allows you to actually build the software we're looking at here.

In addition, once you've installed the Developer Tools, you'll have a host of new programs in /usr/bin. (If you already had Terminal windows open when you installed the Developer Tools, type rehash <RETURN> in each one to recognize these newly installed programs.) If you're curious, type ls -lt /usr/bin <RETURN>, to see a list of things installed along with Apple's compiler. Apple's tools are based on gcc, the GNU Compiler Collection. You can learn more about gcc at http://www.gnu.org/software/gcc/.

Installing Fink

The Fink system is available in two different versions. The Fink Binary Installer is a doubleclickable .pkg file for Apple's Installer, and the Fink Source Release is a pure command-line installer. Both provide a basic set of command-line tools to get Fink running (including the fink program itself), and a set of package files that Fink can use to install other programs. In addition, the Fink Binary Installer includes a selection of pre-compiled packages (to save time) and is based around the dselect and apt-get programs, which provide a text-based menu system to control Fink. (Unfortunately, dselect and apt-get don't work well in Fink yet.) The Fink Source Release uses the fink command instead of dselect and apt-get, and is also able to download, patch, compile, and install software; list installed and available packages; and update itself from the master Internet site. As of this writing, the Source Release is much easier to use.

To install the Fink Source Release, follow this procedure (version numbers and URLs may be different by the time you read this):

1. Check http://fink.sourceforge.net/ for any warnings or important notes about Fink.

2. Download the Source Release from http://fink.sourceforge.net/download/srcdist.php. If StuffIt Expander automatically unpacks it, throw away the extracted directory; as of this writing, StuffIt Expander "expands" Fink incorrectly.

3. In Terminal, cd to the directory where you downloaded the tarball (called fink-0.5.1-full.tar.gz at the time of this writing). If downloads are saved to your Desktop folder, you would type cd ~/Desktop <RETURN>.

4. Use the tar program to extract the archive by typing tar xzf fink-0.5.1-full.tar.gz <RETURN>. (Remember that the name of the file you download and extract will probably be different than my example here.)

5. Change to the directory you just created: cd fink-0.5.1-full <RETURN>. (Again, the name of the directory may be different.)

6. Run the bootstrap.sh script: sh bootstrap.sh <RETURN>.

7. The bootstrap script asks a series of questions, showing suggested answers in square brackets. To accept the default, just press the return key. Many of these questions concern which mirror sites should be used for downloading source files—local mirrors are generally faster than remote ones, and master sites (listed first by the script), are frequently overloaded. Once it finishes gathering information, the bootstrap script will download the required software, compile it, and install the resulting files in a new /sw directory.

8. Among other items, Fink installs startup scripts as /sw/bin/init.csh and /sw/bin/init.sh. To activate Fink, /sw/bin must be added to your PATH environment variable; these scripts take care of that and some additional steps to activate Fink. To complete the installation, you'll have to add a line to source the appropriate script to a shell initialization file; the bootstrap script instructs you on how to do this and then exits. If you have multiple users, each user should add the command to their own initialization file, or you can make the change to a shared initialization file in /etc, as described in "Startup and shutdown" in the tcsh manual page. Assuming you are using tcsh or csh, you can also activate Fink for currently running shells with source /sw/bin/init.csh; rehash <RETURN>. (The semicolon allows you to type two commands on one line; it's more compact than typing the first command, hitting return, then typing the second command and hitting return again, but accomplishes the same thing.)

Since open source software is often worked on by large, disjointed groups of people, and the development process is much more public than that of commercial software, version numbers of open source software often mean significantly different things than they do with commercial software.

• Alpha and beta versions of open source software are often publicly available.

• Developers often encourage the use of alpha and beta versions, both because they fix known bugs, and because they get more useful feedback (feedback on released versions is likely to cover popular and already fixed bugs).

• Many open source software projects are stable and usable before the "final" release or version 1.0. The OpenSSL program, for instance, has been used to provide SSL encryption in the Apache web server and OpenSSH for years, but remains at version 0.9.xx.

• Development versions are generally kept in the Concurrent Version System (CVS) to facilitate collaboration by developers, and the CVS repository is often publicly accessible by non-developers. Apple includes the cvs command in OS X.

• With software stored in CVS, the latest and greatest version available in CVS is called HEAD, and developers often suggest that users "check out" the latest version from CVS and use it.

Using the fink Command

Fink provides several subcommands in addition to install, including list (type fink list -i <RETURN> to list installed packages, or fink list name <RETURN> to see packages that match name), and describe (type fink describe packagename <RETURN> to see details on packagename). For a helpful list of fink subcommands, use fink <RETURN>. For more on the fink command, you can read the fink manual page, and the documentation at http://fink.sourceforge.net/.

It's also a good idea (but not absolutely necessary) to periodically type fink selfupdate update-all <RETURN>, which will make fink update its packages to the latest versions via the Internet. The selfupdate subcommand will even offer to get the latest version of the Fink packages from CVS, rather than the latest "released" versions (which may in fact be older).

FinkCommander

If you'd like to control Fink without using the command line, FinkCommander (http://finkcommander.sourceforge.net/) is just the ticket. FinkCommander is a simple program with a graphical user interface that provides a list of available packages, and lets you drive the fink, dselect, and apt-get programs via contextual menus or menu commands. Like fink list, FinkCommander can filter programs by partial name matches, but it also adds sorting and improved filtering capabilities.