Installing Some Additional Interesting Software

 < Day Day Up > 

Installing Software at the Command Line

The majority of the Unix software you'll find that hasn't been specifically made for Mac OS X is created by other users just like you. Some of them are professional programmers, but the vast majority of them are simply hobbyists who've put together an application because they wanted a program that did something, and they've made it available for you to install out of the sense of team spirit that pervades the Unix and open source communities. Because of the wide range of individuals involved, the possibilities for how the software might be delivered and what you will need to do to install it are truly limitless. We'll do our best to give an overview of the techniques used, but pay attention to the author's instructions to see whether or where they differ from our suggestions. Also, don't be afraid to use your own common sense if you find something that doesn't have instructions and our samples don't appear to apply.

Regardless of the actual steps involved in the installation, there are some things to keep in mind if you want to keep your system in some semblance of order.

  • You'll usually have as much flexibility, and often even more flexibility, about where you install software in Unix as you do in Mac OS. Unfortunately, although the Mac OS Finder invisibly and automatically updates the database of software that's installed for you, Unix doesn't. If you install command-line software in random places throughout the system, you will need to continuously update your PATH variable to reflect the changes. For this reason, despite having the option to install just about anywhere, you'll probably be happiest if you confine your installs to a few common and highly recommended locations. Specifically, those locations are the /usr/local/ and /opt/ directory trees. The popular DarwinPorts installer uses /opt/local/, and the equally popular Fink distribution installer adds /sw/. These are the most common and best places to install software if you want convenience in your system.

  • If you have multiple users on the system, even if you update your own PATH, other users' paths won't be updated, and, consequently, they might not be able to run the software. This can be an advantage or a disadvantage, depending on whether you want to hide the software from others or make it publicly available. If you want the software to be available to your user only, extend your PATH variable in your own .login / .cshrc or .profile / .bashrc files. If you want to make the software available to everyone on the system, extend the systemwide /etc/csh.login / /etc/csh.cshrc or /etc/profile / /etc/bashrc files.

  • If you decide to reconfigure your system or reinstall something, it will be much easier if you keep a complete copy of the distribution and any special options you picked to make it work. Use the tar command and compress or gzip commands (explained in Chapter 10, "Common Unix Shell Commands: File, Directory and Disk Operations," after you've successfully managed to install it. You'll probably want to make clean the distribution first, if possible that incantation will be explained shortly.

  • If you want to maintain your sanity, it will help if you always download software packages into the same location, and do all your configuration and software building in subdirectories of the same directory.

  • Avoid compiling or installing software as the root user. We know, you're going to ignore that suggestion, and compile, install, and run random bits of software you've downloaded as root. Everybody ignores it on occasion we do to. It'll come back and bite you on the butt. Trust us, we've been there. One day you'll run a poorly written (or maliciously written) install script, and it'll go off and damage your system. You'll think, "Why, oh, why did I just run that command as root? Nothing about it required root privileges. If only I'd been a bit more careful." We won't tell you "we told you so," but we will tell you that a lot of the pain is avoidable if you're willing to have some discipline about how you run your system.

    Some software might insist that you install it as root (Fink does, for example), but the root user is the single user with the capacity to destroy your system with a single command (although Apple's done a fair bit of work towards making any group-Admin user have the same capability). It might be preachy to suggest that you're probably better off without most software that requires you to be root to install it, but until you know when it's safe to ignore this suggestion, you'll be much safer following it.


    Some readers with Unix experience, and particularly those experienced in the Linux flavor, might find this caution peculiar in that a considerable amount of third-party software ends up installed in privileged system directories these days. These users are accustomed to needing to be root to do simple installs. Fortunately, this is the wrong way to do things, and it's a rare Unix application that forces you to do things in a poorly thought-out fashion. Almost all non-OS-vendor (in this case non-Apple) software should be installed and owned by non-root users. Even vendor-supplied copies of third-party applications (such as the Apache web server or the Perl programming language) are best owned and installed by non-root users.

    This model makes life a bit more difficult than just having root own everything (and so the vendors of Unix-come-lately versions seem to be leaning toward making everything owned by root), but the benefits of behaving in a responsible and secure fashion far outweigh the minor inconvenience. If you conscientiously make sure that everything that isn't distinctly part of the operating system is owned by a nonprivileged user, you can allow nonprivileged users to modify and maintain those parts of the system with no fear that they are going to damage the OS itself. Even if you, as the person at the keyboard, aren't personally different in any way when you're operating as root, you're inherently putting your machine in more danger than when you're operating as a nonprivileged user. If non-OS-vendor software is installed and owned by a non-root user, any time spent working with and installing that software, and any unfortunate things that happen as a result of code that it runs, are done by a nonprivileged user. The machine is more secure and the danger of a malicious script or an errant keystroke causing damage to the system is significantly reduced. If you have a true multiperson, multiuser system, the workload of managing software can be safely distributed, and users who need to be able to modify configurations (such as changing the web server settings), can do so without having to annoy root or having to develop the meticulous operating habits that someone running as root must conscientiously maintain.

    Implementing this model on your system takes a little additional effort on your part. You won't be able to follow people's simple-minded instructions to sudo make install bits of software. But your machine will be better managed, more secure, and you'll be helping to keep mushy-headed thinking from taking hold of the Mac OS X platform if you just take the time to follow these suggestions and set up a nonprivileged software account to own and install the majority of your third-party software.

  • Another useful trick for keeping your system in order is to create a special user ID that is used solely for software installations and management. The ownership of the /usr/local and /opt directories, as well as the ownership of wherever you download software and where you store it, can be set to this user ID. This user ID does not need to have (and definitely should not have) administrator privileges on the system. This minimizes the risk of simply doing something wrong or accidentally damaging the running system. It also minimizes the impact that a malicious user, distributing damaging scripts in the guise of useful software, can do to your system.


You'll find Unix software being distributed in Usenet newsgroups, on web pages, FTP servers, through email, and other mechanisms. No matter how it's distributed, you are going to need to transfer a copy of the software, from wherever it is stored, to your local machine.

You've got all the tools necessary to accomplish any of these in the command-line programs discussed here and in the previous chapter, as well as in the GUI clients covered earlier.

While acquiring software, keep in mind that things will go smoothest if

  • The software is downloaded by the user who will be responsible for the installation.

  • The software is downloaded into a directory where it can be unpackaged and compiled, if necessary. This includes the requirement for sufficient disk space, as well as the appropriate permissions for the user ID that will be doing the installation. If you have a tendency to download software as your primary logged-in user ID and then try to manage it as a special, limited software-install user, the software user probably won't be able to read or modify your downloaded copies, and you'll just get annoyed with the requirements to move everything around in circles so that both you and the software-install user can access the files. Learn to use curl or lynx for downloading your software so that you can paste links from a web browser that you are running to a terminal where you're logged in as the software user for downloads. Alternatively, make the directory where you download the software group-writeable and put yourself and the software-install user in the same group.

  • If you're using ftp, remember to use binary mode.

  • Put StuffIt Expander in your Dock, so that you can drag and drop onto it conveniently. You'll normally want to use the command-line utilities gunzip and tar, but sometimes StuffIt Expander is just the ticket for getting a packaged-up software distribution out of an archived newsgroup posting that you've found via Google.

  • Sometimes StuffIt Expander eats .tar.gz (or other Unix-compressed) files or at least it regurgitates useless bits after trying to process the file. If you try to build a Unix application from an archive that you've uncompressed through StuffIt Expander, and it complains of things like missing files, remember to try the command-line tools before giving up. StuffIt Expander has problems with some filenames and it's not always forthcoming about the fact that it changed something.


Some software comes as source code (the language that compilers read) that explains to the compiler how to create a finished program. Some comes as final executable programs. Either way, most software comes as a tarfile compressed with either the compress program (usually denoted by a .Z file suffix) or the gzip program (usually denoted by a .gz suffix).

The first thing you'll need to do after downloading, therefore, is usually to uncompress or gunzip the tarfile.

Next you'll usually need to untar the tarfile (with tar -xvf <tarfile>). Before you do that, however, it's usually a good idea to make sure what's in the tarfile. You're interested in the contents as well as where the tarfile wants to put the stuff that's in it. The second item is of particular importance some software authors have the sloppy habit of letting their tarfiles place files in the current directory rather than a subdirectory. Additionally, some packages are distributed as tarfiles that are designed to untar "in place" in the system. That is, they place files directly into their final locations (such as /usr/local/bin) rather than into a temporary subdirectory for subsequent installation.


Some web browsers insist on uncompressing and untarring files for you without asking. This leaves a directory with the contents sitting on your desktop, or elsewhere, where you've specified that downloads should go. This functionality is okay, as far as it goes, but it's not uncommon for file permissions and other important information to get lost or broken when the web browser does this. If everything works properly in the directory as unarchived by the web browser, you're home free; but if it doesn't, don't panic: Delete the directory that the web browser created, redo the uncompress/untar by hand, and try again.


Also keep in mind that if you download with a web browser, it isn't unusual for the browser to remove the file suffix without actually doing anything to the file. This results in downloaded gzip files that are missing their .gz suffix and so on. This confuses some utilities designed to work with these files. If you have downloaded a piece of software with a web browser that arrives as a .tar file but tar refuses to unpack it, try adding a .Z or .gz suffix and see whether uncompress or gunzip will process the renamed file.

If you've downloaded a precompiled application that needs you only to unpack it in place or put it in a final location after unpacking the distribution, you're all set. If you've downloaded a package that is distributed as source code, skip to the next section on compiling software.

Installing a Precompiled Binary by Unarchiving and Putting It Where It Belongs: lynx

The lynx command-line web browser is such a useful tool that we'll do a download and unarchive install right now. A precompiled version of lynx is available from

Before you install lynx, we recommend that you make a change in your system's configuration that helps keep your system safe from malicious software and accidents during software installs. Use the Accounts control pane discussed in Chapter 8, "Customizing User and System Settings," to create a new user to own all your software. There we showed how to create the unprivileged software user with the custom group tire. This is the user who will own and install our programs for us. Because software is not an administrative user and has privileges only in her home directory and in /usr/local/, software can't damage anything outside those locations. At worst, a malicious script or accident at the keyboard will just screw up what software's already installed, leaving the rest of the machine safe.

Next, su to the root user. Finally, change the ownership of the directory /usr/local/ on your machine to belong to the software user and group. If you're using unprivileged user software with group tire, ifrom the command line, the process looks like the following:

 brezup:ray testing $ su Password: brezup:root testing # cd /usr brezup:root usr # chown software.tire /usr/local brezup:root usr # ls -ld local drwxr-xr-x  4 software  tire  92 Apr 21 22:00 local 


Now, log out and log back in as the unprivileged software user that you created. If you prefer, you can start multiple terminals, or use Apple's User Switching technology to flip between sessions logged in as yourself and the unprivileged software user.


Start a terminal and create the directories /usr/local/lib, /usr/local/man, /usr/local/man/man1, and /usr/local/bin (mkdir /usr/local/lib; mkdir /usr/local/man; mkdir /usr/local/man/man1; mkdir /usr/local/bin).


Next, point your browser at and download the files lynx.gz, lynx.1, and lynx.cfg.

Chances are, if you're using Safari or Internet Explorer, it's going to insist on decompressing lynx.gz automatically. If not, you will need to find the file (double-click lynx.gz in the download manager and click Reveal in Finder) and then drag it to your software user's Documents folder.


In the terminal, cd ~/Documents. Uncompress the lynx.gz archive with the command gunzip lynx.gz. If your browser already did this for you, a file named lynx might be in your Desktop folder.


Wherever the file lynx ends up, copy it to /usr/local/bin/. Use cp <path to lynx> /usr/local/bin/. <path to lynx> might just be lynx or it might be ~/Desktop/lynx.

In the same directory, you should find ithe lynx.1 file that you downloaded this is the man page for lynx and belongs in /usr/local/man/man1; copy it there with cp lynx.1 /usr/local/man/man1/. If you want to be able to find it with the whatis or man -k commands, you can makewhatis /usr/local/man now as well.


Read the beginning of lynx.cfg. You can do this with less lynx.cfg. You can set a lot of configuration defaults in this file, but for now, leave the defaults as they are and copy the file to its intended destination. It should tell you that it belongs in /usr/local/lib/lynx.cfg, so cp <path to lynx.cfg> /usr/local/lib/lynx.cfg.


Just to make sure that the lynx file is executable, chmod 755 /usr/local/bin/lynx.


Log out and back in as your normal user. You might need to set your path to include /usr/local/bin, if it doesn't already. The easiest way to do this, as explained in Chapter 10 and detailed in 15, is to extend your path with PATH="$PATH:/usr/local/bin/" in your .bashrc file or set path=($path /usr/local/bin) placed in your .cshrc file, depending on which shell you're using. If you want this path to be available to everyone, all the time, you could put those statements in the systemwide /etc/ versions of the files: /etc/bashrc and /etc/csh.cshrc.

The lynx application should now be executable and behave just as detailed in Chapter 13, "Using Common Command-Line Applications and Application Suites," although there is a bit of weirdness with the man page that we're going to have to fix in the next few pages.

Before you go on, stop and think fori a moment about what you've just done. If the terminal is still a strange place to you, you might be feeling as if you've just uttered some magic incantations and not be too sure you could do this again without the explicit instructions. Most things you come across will have instructions that are relatively explicit, but that's not the point. All that you've done is this: You've downloaded the software you're used to doing that for other software installs in your web browser, FTP client, or the like you've done nothing different here. Then you unpackaged it nothing new there either you've used StuffIt Expander before, right? Finally, you made a few new directories and copied the software where you wanted it to go. None of this was difficult for you and it won't be difficult for you in the future either. Don't let the fact that you're using unfamiliar tools now get in the way of the fact that you know what to do every step of the way. Soon you'll find this way of working to be just as second nature to you as double-clicking an "install" icon.

Building Software from Source Code: Compiling

Compiling source code is still complicated enough and there are plenty of places it can go wrong that most users will at least initially find it less than fun. It'll be the last scary topic we introduce in this book, though everything after this is an application of what you've learned in the last few chapters and this one and the introduction of new programs for you to use. Actually, this stuff isn't that scary either. If you make it through this chapter and we haven't scared you away from the BSD subsystem, you're home free we promise!


Compilation is the process that a program-language compiler uses to take a source code "recipe" and convert it into an actual executable application. It is also used to describe the act of running the compiler to perform the compilation. To those coming from a Macintosh or Windows background, the idea of having to cook your own software from the raw ingredients probably evokes images of impossibly cryptic commands and more headaches than you would ever want to deal with. Thankfully, compiling prepackaged source code isn't quite cooking from the raw ingredients it's usually more like warming up a TV dinner.

If you're interested in learning to cook software from scratch, we recommend Kernigan and Ritchie's excellent The C Programming Language and Donald Knuth's The Art of Computer Programming books on software architecture. There are far simpler books on programming, but nothing beats these seminal and indispensable references on the practice and principles of software design and engineering.


In addition to installing software using GUI installers and compiling your own at the command line, there's a third major way of installing software under Mac OS X. This method, using a software package management system, is explained later in this chapter, when we will use the Fink ports package management system to install some X11 software for the X Window System and the DarwinPorts system to install a spell checker.

Much of what you can install at the command line in this chapter can be more easily installed using the Fink package manager or DarwinPorts. So, if you find this chapter's manipulations to be more than you're willing to deal with, don't worry; there are easier ways to install most of this and other software. The downsides of using the ports systems are that the software in them is rarely as up-to-date as what you can download directly from the authors and you're stuck with whatever compilation options and settings the port maintainers chose for their compilation. Still, despite these limitations, software installed from the Fink or DarwinPorts system is more than adequate for most uses, and the convenience of just typing fink install <package> usually outweighs the flexibility you get from installing manually.

Think of the manual installation examples here mostly as a practice and learning experience. There is more software that's not in either major port system than there is in both put together, so the techniques you'll learn are indispensable, even if these particular applications can be acquired somewhat more easily. We've selected some software that demonstrates many of the characteristics you'll find common among most manual software installs. If you think of building your system this way as an exciting challenge, you'll be able to go well beyond what's available from GUI or package-manager installations. If you look at playing with the guts of the system as an unpleasant exercise best avoided, you probably won't mind trading a bit of a wait for someone else to do the dirty work of fitting new software into Fink or DarwinPorts.

Basic Steps: configure, make

Let's start with an example of a simple software install that requires compilation things can get more complicated than this, but for many applications written by conscientious programmers, these steps will suffice. Installs shown here are also done assuming that you're logged in as your software user and that you've downloaded software into the Documents directory.

Almost universally, the first command you'll issue to compile software is either ./configure (if it's present) or make (if ./configure is not present). For pine, the only things you have to type are

 make build osx cp bin/pine /usr/local/bin/ mkdir /usr/local/man/ mkdir /usr/local/man1/ cp docs/pine.1 /usr/local/man/man1/ 

That doesn't look too hard, does it? The basic operations are simply make, build, and copying some files into standard locations in the file system.

If you want to follow along with this example, the pine package shown here can be downloaded from The simplest way to do this is with curl:

 cd ~/Documents curl -O gunzip pine.tar.gz tar -xf pine.tar 


If you prefer to use the command-line Internet client lynx, you could issue the same download request by using the following command in place of the curl command:

lynx -dump > pine .tar.gz

The developers of lynx are changing and rearranging the way that some of the download functions work in the program. If your version of lynx produces files that can't be gunzipped as shown in the examples, you've been unlucky and gotten one of the versions that automatically uncompresses and gunzips files on download, even when storing them to disk. In this case, remove the gunzip step from the process and start off with the file as a .tar file instead. is always a link to the most recent version, so pine might have advanced beyond 4.61 by the time you're reading this. We know pine4.61 compiles okay, so if you download a more recent version and have problems, you should be able to get 4.61 from its old directory most likely at the URL

After you've downloaded and unpacked your distribution, it's time to dig in and build some software.

 brezup:software source $ cd pine4.61/ brezup:software pine4.61 $ ls -l total 136 -rw-r--r--     1 software  tire   2866 May  7  2004 CPYRIGHT -rw-r--r--     1 software  tire  12229 May  7  2004 README -rwxr-xr-x     1 software  tire  18070 May 17  2004 build -rwxr-xr-x     1 software  tire   6039 Mar 15  1996 build.cmd -rwxr-xr-x     1 software  tire  17118 May  7  2004 buildcyg drwxr-xr-x    10 software  tire    340 Apr 27  2004 contrib drwxr-xr-x    13 software  tire    442 Jul 15 13:38 doc drwxr-xr-x    16 software  tire    544 Jul 15 14:29 imap -rw-r--r--     1 software  tire   1574 Oct  3  2003 makefile drwxr-xr-x     5 software  tire    170 Jul 14 15:28 packages drwxr-xr-x    86 software  tire   2924 Jul 14 15:37 pico drwxr-xr-x   101 software  tire   3434 Jul 15 13:37 pine 

There's no file named configure, so try make:

 brezup:software pine4.61 $ make Use the "build" command (shell script) to make Pine. You can say "build help" for details on how it works. 

So, this software install isn't quite standard it doesn't use make, other than to tell us that it doesn't use make. If you read the README and look at the output of build help, which points you to docs/pine-ports, you'll observe that an osx option already is available, so give that a try:

brezup:software pine4.61 $ ./build osx make args are CC=cc osx <much output deleted> Building c-client for osx... echo `cat SPECIALS` > c-client/SPECIALS cd c-client;make osx EXTRACFLAGS='\ EXTRALDFLAGS='\ EXTRADRIVERS='mbox'\ . . . Building OS-dependent module If you get No such file error messages for files x509.h, ssl.h, pem.h, buffer.h, bio.h, and crypto.h, that means that OpenSSL is not installed on your system. Either install OpenSSL first or build with command: make osx SSLTYPE=none `cat CCTYPE` -c `cat CFLAGS` `cat OSCFLAGS` -c osdep.c `cat CCTYPE` -c `cat CFLAGS` mail.c . . . Building bundled tools... cd mtest;make cc -I../c-client `cat ../c-client/CFLAGS` -c -o mtest.o mtest.c . . . Making Pico and Pilot make CC=cc -f makefile.osx rm -f os.h ln -s osdep/os-osx.h os.h cc -g -DDEBUG -Dbsd -DJOB_CONTROL -c -o main.o main.c cc -g -DDEBUG -Dbsd -DJOB_CONTROL -c -o attach.o attach.c . . . Making Pine and rpload/rpdump. make CC=cc LDAPLIBS=-lldap LDAPCFLAGS=-DENABLE_LDAP -f makefile.osx rm -f os.h ln -s osdep/os-osx.h os.h ./ < pine.hlp > helptext.h cc -g -DDEBUG -DDEBUGJOURNAL -DENABLE_LDAP -Dconst= -DSYSTYPE=\"OSX\" -c -o addrbook .o addrbook.c . . . Links to executables are in bin directory: __TEXT __DATA __OBJC others dec hex 4272128 319488 0 3248128 7839744 77a000 bin/pine 684032 12288 0 684032 1380352 151000 bin/mtest 724992 77824 0 720896 1523712 174000 bin/imapd 278528 12288 0 286720 577536 8d000 bin/pico 274432 12288 0 282624 569344 8b000 bin/pilot 946176 20480 0 946176 1912832 1d3000 bin/rpdump 950272 20480 0 950272 1921024 1d5000 bin/rpload 684032 12288 0 679936 1376256 150000 bin/mailutil 684032 12288 0 679936 1376256 150000 bin/ipop2d 688128 12288 0 679936 1380352 151000 bin/ipop3d Done

Wow, that's a lot of output! If you were watching closely, you'll have seen some warnings fly by in there. But as long as it didn't explicitly say "Error" and, at the end, it tells you that there are executables in the bin directory, you're in good shape. Let's look in the bin directory and see what you've got.

 brezup:software pine4.61 # ls -l bin total 36848 total 38456 -rwxr-xr-x   2 software  tire  1453756 Jan  5 12:25 imapd -rwxr-xr-x   2 software  tire  1368304 Jan  5 12:25 ipop2d -rwxr-xr-x   2 software  tire  1375420 Jan  5 12:25 ipop3d -rwxr-xr-x   2 software  tire  1371568 Jan  5 12:25 mailutil -rwxr-xr-x   2 software  tire  1372536 Jan  5 12:25 mtest -rwxr-xr-x   2 software  tire   566500 Jan  5 12:26 pico -rwxr-xr-x   2 software  tire   559768 Jan  5 12:26 pilot -rwxr-xr-x   2 software  tire  7787980 Jan  5 12:28 pine -rwxr-xr-x   2 software  tire  1902860 Jan  5 12:28 rpdump -rwxr-xr-x   2 software  tire  1910980 Jan  5 12:28 rpload 

We were building pine, and in fact there is an executable pine in the bin directory, as well as a number of other applications. Installing pine now is simply copying it to /usr/local/bin with cp bin/pine /usr/local/bin. After that, pine should function as shown earlier.

 brezup:software pine4.61 $ cp bin/pine /usr/local/bin/ 

A number of other executable applications are in that bin directory, too. You might want to spend the time to find out whether they do anything that you'd find useful for example, along with pine, you've just built pico, which is a popular text editor that's been gaining on emacs and vi for quite a while. If you check the version of pico, a fairly popular and friendly terminal-based text editor included with Mac OS X 10.2 and 10.3, you'll find that it's version 2.5, and you've just built pico version 4.6 possibly a worthwhile upgrade. We'll leave the exercise of reading about the rest of the utilities you've just built up to you.

To make this a little easier, you might have noticed at the first listing of the directory, there is a doc directory. Things such as man pages are probably found there, so let's take a look:

 brezup:software pine4.61 $ ls doc brochure.txt    pico.1          pine.1          tech-notes mailcap.unx     pilot.1         rpdump.1        tech-notes.txt mime.types      pine-ports      rpload.1 

Great! Things that end in .<#> are usually man pages that belong in the man# section of the manual. Let's put the pine.1 page for pine into the appropriate man1 directory in /usr/local/man. If you didn't already create the /usr/local/man/man1 directory when you installed lynx earlier, you'll get a response something like this:

 brezup:software pine4.61 $ cp doc/pine.1 /usr/local/man/man1/ cp: /usr/local/man/man1: No such file or directory 

In such a case, you simply need to make the directory:

 brezup:software pine4.61 $ mkdir /usr/local/man/man1 mkdir: /usr/local/man/man1: No such file or directory 

Of course, if you didn't create these directories already, there's probably no /usr/local/man directory either. Thankfully, you only have to do this kind of directory creation steps once most other command-line software will want the same directory structure, and this will be the only time you have to create these directories.

 brezup:software pine4.61 $ mkdir /usr/local/man brezup:software pine4.61 $ mkdir /usr/local/man/man1 

Alternatively, you could make both directories with the same command, by using the -p "make intermediate directories" (that is make the entire path) option of mkdir:

 brezup:software pine4.61 $ mkdir -p /usr/local/man/man1 

If another application needs another directory, of course you'll need to create it, but you've got almost everything standard covered by now.

 brezup:software pine4.61 $ cp doc/pine.1 /usr/local/man/man1 

And now we can try looking at the man page. If you're using a version of Mac OS X that doesn't include the manpath command (versions more recent than 10.2.5 appear to include it) or you don't have /usr/local/bin added to your executable search path, you'll see something like the following; otherwise, you should see the man page for pine appear, just like any other man page on your system:

 brezup:software pine4.61 $ man pine man: no entry for pine in the manual. 


Depending on your system configuration, system versions more recent than 10.4 might produce this error as well, but for a different reason: Apple has changed a previously working configuration from something that makes sense in the wide world of standard installations to something that might make sense if the rest of the world didn't exist, but breaks things because it the world won't go away. If you see this on 10.4, run the manpath command at the command line. Chances are you'll see /usr/local/share/man in the list instead of /usr/local/man. You have a choice of adjusting the configuration that causes this mis-choice of paths, putting your man pages where Apple has decided that everyone should have been putting them all along, or faking the system into thinking that they're in /usr/local/share/man despite their real, traditional location. The vast majority of the software you install will put its man files in /usr/local/man, so it makes more sense to either change the configuration or add a link from /usr/local/share/man back to /usr/local/man, rather than trying to adjust every installation to meet Apple's new silliness. You can make this adjustment in /usr/share/misc/man.conf (or /etc/manpath.config, depending on the version).Edit the lines that say MANPATH_MAP /usr/local/bin /usr/local/share/man so that they point to /usr/local/man instead, or just comment them out altogether. Alternatively, mkdir /usr/local/share; ln -s /usr/local/man /usr/local/share/man should work.

If you already have both directories, and files living in each, you can copy the contents of one into the other before repairing the configuration, or linking the directories.

This error indicates that the man command doesn't know where to find the man page for pine specifically, that it hasn't been informed of the /usr/local/man/man1 directory that you just put it in. On recent versions of Mac OS X, all you need to do to make that directory visible to man is to include the /usr/local/bin directory in your executable search path (and perhaps fix the configuration as mentioned in the preceding caution), and the manpath command will automatically provide man with likely sounding directory names that are near the executable directories.


Be aware that the automatic manpath finding algorithm can be a little dense. It will look for man directories that parallel any directories in your path that end in <somepath>/bin note that there's no trailing forward slash, despite the fact that it's a directory. If you add /fizbin/wozbot/bin to your PATH environment variable, manpath will correctly identify /fizbin/wozbot/man as a possible location to search for man pages. If you specify /fizbin/wozbot/bin/ in your PATH, manpath will ignore its existence.

If for some reason you really want to stuff man pages off in weird corners where the manpath command can't find them automatically, you can always set the MANPATH environment variable as a way of explicitly telling man where to look.


With bash, the shell is supposed to automatically discover new programs that have been added to directories in your PATH and let you immediately run them by name. This doesn't always work, and the only cure we're aware of is to quit the shell and start another one. With tcsh, you can tell the shell that it's time to refresh its list of available commands by running the rehash command.

In this case, I've deliberately forgotten to set the executable search path to include /usr/local/bin, so the manpath command doesn't know about /usr/local/man as a place to find man pages. Again, fixing these things is best done in your .bashrc or .cshrc file or the system equivalents. Setting it by hand now can be accomplished as follows:

 brezup:software pine4.61 $ echo $PATH /bin:/sbin:/usr/bin:/usr/sbin brezup:software pine4.61 $ PATH=$PATH:/usr/local/bin brezup:software pine4.61 $ echo $PATH /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin brezup:software pine4.61 $ man pine pine(1)                                                                pine(1) NAME        pine - a Program for Internet News and Email SYNTAX        pine [ options ] [ address , address ]        pinef [ options ] [ address , address ] DESCRIPTION        Pine  is  a screen-oriented message-handling tool.  In its default con-        figuration, Pine offers  an  intentionally  limited  set  of  functions        geared  toward  the  novice  user,  but  it  also has a growing list of        optional "power-user" and personal-preference  features.   pinef  is  a        variant  of  Pine  that uses function keys rather than mnemonic single-        letter commands.  Pine's basic feature set includes: . . . 

If you install other programs from the bin directory, you'll want to copy their man pages as well. Finally, clean up after yourself, and put the pine stuff into your installed software directory in case you need it again:

 brezup:software pine4.61 $ make clean ./build clean make args are CC=cc  clean Cleaning c-client and imapd Removing old processed sources and binaries... <deletia> Cleaning Pine rm -f *.o os.h os.c helptext.c helptext.h pine pine.exe rpdump rpdump.exe rpload rpload.exe <more deletia> Cleaning pico rm -f *.a *.o *~ pico_os.c os.h pico pico.exe pilot pilot.exe <and more deletia> Done brezup:software pine4.61 $ cd ../ brezup:software source $ tar -cf installed_pine4.61.tar pine4.61/ brezup:software source $ gzip installed_pine4.61.tar brezup:software source $ mkdir installed brezup:software source $ mv installed_pine4.61.tar.gz installed/ brezup:software source $ \rm -rf pine4.61 brezup:software source $ \rm -rf pine.tar 

That's it! If you've been following along, you've just compiled and installed a piece of software. Is your heart racing or are your palms sweaty? Do you feel like a different person? No? Didn't think so. Most software installations, by and large, are exactly this anticlimactic.


Curious about the \before the rm in the last command of that example? Remember when we suggested aliasing rm to rm -i to help avoid deleting things unintentionally? Remember also that the \character escapes things in the shell? If you precede an aliased command with an \escape character, the effect is that the command, as the command line sees it, isn't exactly the same as the command that you set up the alias for. Effectively, for the execution of this command, the alias does not exist. In this case, it allows us to recursively delete the entire pine4.61 directory and all its contents without needing to repeatedly answer Y to delete each file.


Why did I throw away the tarfile that I downloaded and create another one of the directory I was just working in for archiving in my installed directory? Because I have a terrible time remembering what installation options I might have used, files that I might have edited, and tweaks that I might have had to make to configure and install the software the way that I want it. By archiving a copy of the install directory in exactly the condition it is in when I run my final successful make (or in this case, build), I don't need to remember these things; they're preserved right there for me in the tar file.

Next, let's do a couple of quick installs that use a more standard installation protocol. They're a collection of steps to get you set up for a considerably more difficult install we'll do in the troubleshooting section of this chapter. The first of these is libjpeg and the second is libpng. These are library packages that will be needed later to support the netpbm package an amazingly powerful command-line graphics processing program. The complete standard invocation for configuration and compiling is usually the following:

 configure make make test make install 

If you read the README file for this software, you'll see it gets an additional make install-lib step always read the README and INSTALL files if they are present!


Download both libjpeg and libpng with curl:

 cd ~/Documents/ curl -O curl -O 


Uncompress and unarchive the libjpeg archive:

 brezup:software source $ gunzip jpegsrc.v6b.tar.gz brezup:software source $ tar -xf jpegsrc.v6b.tar 


If you prefer to uncompress and untar the file in one step, you can use tar -xvzf jpegsrc.v6b.tar.gz instead. I habitually do this process as two separate steps because I work between a number of Unix-based platforms, and not all of them have tars that include the uncompress option. Rather than be somewhere in the middle of typing make when I notice that the tar command returned an error, it's easier for me to simply always use two steps.


cd into the directory, check to see whether there's a configure file or only a makefile, and either ./configure or make, as appropriate:

 brezup:software source $ cd jpeg-6b/ brezup:software jpeg-6b $ ls README         jcmarker.c      jdhuff.h       jpegint.h ansi2knr.1     jcmaster.c      jdinput.c      jpeglib.h      makvms.opt ansi2knr.c     jcomapi.c       jdmainct.c     jpegtran.1     rdbmp.c cderror.h      jconfig.bcc     jdmarker.c     jpegtran.c     rdcolmap.c cdjpeg.c       jconfig.cfg     jdmaster.c     jquant1.c      rdgif.c cdjpeg.h      jdmerge.c      jquant2.c      rdjpgcom.1 change.log     jconfig.doc     jdphuff.c      jutils.c       rdjpgcom.c cjpeg.1        jconfig.mac     jdpostct.c     jversion.h     rdppm.c cjpeg.c        jconfig.manx    jdsample.c     libjpeg.doc    rdrle.c ckconfig.c     jconfig.mc6     jdtrans.c      ltconfig       rdswitch.c coderules.doc     jerror.c      rdtarga.c config.guess      jerror.h    structure.doc config.sub      jfdctflt.c    testimg.bmp configure      jconfig.vms     jfdctfst.c     makeapps.ds    testimg.jpg djpeg.1        jconfig.wat     jfdctint.c     makefile.ansi  testimg.ppm djpeg.c        jcparam.c       jidctflt.c     makefile.bcc    testimgp.jpg example.c      jcphuff.c       jidctfst.c     makefile.cfg   testorig.jpg filelist.doc   jcprepct.c      jidctint.c    testprog.jpg install-sh     jcsample.c      jidctred.c     makefile.manx  transupp.c install.doc    jctrans.c       jinclude.h     makefile.mc6   transupp.h jcapimin.c     jdapimin.c      jmemansi.c     makefile.mms   usage.doc jcapistd.c     jdapistd.c      jmemdos.c   wizard.doc jccoefct.c     jdatadst.c      jmemdosa.asm   makefile.unix  wrbmp.c jccolor.c      jdatasrc.c      jmemmac.c    wrgif.c jcdctmgr.c     jdcoefct.c      jmemmgr.c      makefile.vms   wrjpgcom.1 jchuff.c       jdcolor.c       jmemname.c     makefile.wat   wrjpgcom.c jchuff.h       jdct.h          jmemnobs.c     makelib.ds     wrppm.c jcinit.c       jddctmgr.c      jmemsys.h      makeproj.mac   wrrle.c jcmainct.c     jdhuff.c        jmorecfg.h    wrtarga.c 

Yes, that's a bunch of files it's nothing to worry about, though. The configuration and build scripts put together by the author will take care of the details; all you need to do is remember the general steps for building and respond as requested if there's something the software or READMEs ask you to do. There's a configure file, so call ./configure:

 brezup:software jpeg-6b $ ./configure checking for gcc... gcc checking whether the C compiler (gcc  ) works... yes checking whether the C compiler (gcc  ) is a cross-compiler... no checking whether we are using GNU C... yes checking how to run the C preprocessor... gcc -E checking for function prototypes... yes checking for stddef.h... yes checking for stdlib.h... yes checking for string.h... yes checking for size_t... yes checking for type unsigned char... yes checking for type unsigned short... yes checking for type void... yes checking for working const... yes checking for inline... __inline__ checking for broken incomplete types... ok checking for short external names... ok checking to see if char is signed... yes checking to see if right shift is signed... yes checking to see if fopen accepts b spec... yes checking for a BSD compatible install... /usr/bin/install -c checking for ranlib... ranlib checking libjpeg version number... 62 creating ./config.status creating Makefile creating jconfig.h 


Why ./configure instead of just configure? Because there might be many different executables named configure on your machine and you want to be sure to run only this one in this directory. As a matter of fact, on most competent Unix installations, typing configure (or any program name) at the command line will most frequently not run a version of that command that's in the current directory. Mac OS X seems currently to be reasonably well configured with respect to default paths, so if you want the command line to search the current directory for executables, you'll have to add it to your path.

configure runs and drops you back to the command line with no complaints, so now it's time to run make:

 brezup:software jpeg-6b $ make gcc -O2  -I.   -c -o jcapimin.o jcapimin.c gcc -O2  -I.   -c -o jcapistd.o jcapistd.c gcc -O2  -I.   -c -o jctrans.o jctrans.c gcc -O2  -I.   -c -o jcparam.o jcparam.c gcc -O2  -I.   -c -o jdatadst.o jdatadst.c . . . rm -f libjpeg.a ar rc libjpeg.a  jcapimin.o jcapistd.o jctrans.o jcparam.o jdatadst.o \ jcinit.o jcmaster.o jcmarker.o jcmainct.o jcprepct.o jccoefct.ojccolor.o \ jcsample.o jchuff.o jcphuff.o jcdctmgr.o jfdctfst.o jfdctflt.o jfdctint.o \ jdapimin.o jdapistd.o jdtrans.o jdatasrc.o jdmaster.o jdinput.o jdmarker.o \ jdhuff.o jdphuff.o jdmainct.o jdcoefct.o jdpostct.o jddctmgr.o jidctfst.o \ jidctflt.o jidctint.o jidctred.o jdsample.o jdcolor.o jquant1.o jquant2.o \ jdmerge.o jcomapi.o jutils.o jerror.o jmemmgr.o jmemnobs.o ranlib libjpeg.a gcc -O2  -I.   -c -o cjpeg.o cjpeg.c gcc -O2  -I.   -c -o rdppm.o rdppm.c . . . gcc -O2  -I.   -c -o wrjpgcom.o wrjpgcom.c gcc  -o wrjpgcom wrjpgcom.o 

Again, you arrive back at the command line, so it's time to try make test:

 brezup:software jpeg-6b $ make test rm -f testout* ./djpeg -dct int -ppm -outfile testout.ppm  ./testorig.jpg ./djpeg -dct int -bmp -colors 256 -outfile testout.bmp  ./testorig.jpg ./cjpeg -dct int -outfile testout.jpg  ./testimg.ppm ./djpeg -dct int -ppm -outfile testoutp.ppm ./testprog.jpg ./cjpeg -dct int -progressive -opt -outfile testoutp.jpg ./testimg.ppm ./jpegtran -outfile testoutt.jpg ./testprog.jpg cmp ./testimg.ppm testout.ppm cmp ./testimg.bmp testout.bmp cmp ./testimg.jpg testout.jpg cmp ./testimg.ppm testoutp.ppm cmp ./testimgp.jpg testoutp.jpg cmp ./testorig.jpg testoutt.jpg 

If there was a problem, make test would have spit out some error diagnostics and told you that it had encountered trouble. Because it didn't, you're ready to move on to make install:

 brezup:software jpeg-6b $ make install /usr/bin/install -c cjpeg /usr/local/bin/cjpeg /usr/bin/install -c djpeg /usr/local/bin/djpeg /usr/bin/install -c jpegtran /usr/local/bin/jpegtran /usr/bin/install -c rdjpgcom /usr/local/bin/rdjpgcom /usr/bin/install -c wrjpgcom /usr/local/bin/wrjpgcom /usr/bin/install -c -m 644 ./cjpeg.1 /usr/local/man/man1/cjpeg.1 /usr/bin/install -c -m 644 ./djpeg.1 /usr/local/man/man1/djpeg.1 /usr/bin/install -c -m 644 ./jpegtran.1 /usr/local/man/man1/jpegtran.1 /usr/bin/install -c -m 644 ./rdjpgcom.1 /usr/local/man/man1/rdjpgcom.1 /usr/bin/install -c -m 644 ./wrjpgcom.1 /usr/local/man/man1/wrjpgcom.1 

Notice that it's using the /usr/local/man/man1 directory that you created earlier. If you hadn't done so, it would be complaining here.


Sometimes make install rules automatically create directories needed for installation, but this particular install doesn't do this. Many authors assume that any sane version of Unix would already have directories such as /usr/local/bin and /usr/local/man and that creating them should never be necessary. Within a few installations, you'll have created all the directories that are customarily present, and then things should take care of themselves because authors tend to be more careful to explicitly create directories that aren't in the "normally present" tree.

Finally, if you read the README, you'd see that we need a make install-lib step here, too:

 brezup:software jpeg-6b $ make install-lib /usr/bin/install -c -m 644 jconfig.h /usr/local/include/jconfig.h /usr/bin/install: /usr/local/include/jconfig.h: No such file or directory make: *** [install-headers] Error 1 

What did I say about that installer not creating directories? Now it needs a /usr/local/include directory as well:

 brezup:software jpeg-6b $ mkdir /usr/local/include brezup:software jpeg-6b $ make install-lib /usr/bin/install -c -m 644 jconfig.h /usr/local/include/jconfig.h /usr/bin/install -c -m 644 ./jpeglib.h /usr/local/include/jpeglib.h /usr/bin/install -c -m 644 ./jmorecfg.h /usr/local/include/jmorecfg.h /usr/bin/install -c -m 644 ./jerror.h /usr/local/include/jerror.h /usr/bin/install -c -m 644 libjpeg.a /usr/local/lib/libjpeg.a 

Then you're finished. To tidy things up, make clean, delete the original tar file, tar and then delete the directory you've been working in, gzip the new tar file, and store it in your installed directory.

Now let's take a look at what you just did. Other than creating a directory to fix the not-quite-functional installer, the entire process was: ./configure, which guessed a few settings about your machine, and then a series of make, make test, make install, and make install-lib. Other than the ./configure, the actual program called in each case was make, and it was directed to make different things with each call. The identities of these things are defined by the software author in a control file called a makefile and named, unsurprisingly, either Makefile or makefile. With any well-written software package, the makefile will direct make (called with no arguments) to compile the software with default settings. Frequently, but not always, a test suite is provided that can be invoked with make test.

Finally, an installer routine is invoked, by convention, with make install. In the case of libjpeg, the package provides both a few small executables and some library functions for other software, should you want them. The basic make install process puts the small executables in /usr/local/bin but doesn't install the libraries because not everyone wants them. Therefore, there's an optional make install-lib step to install the libraries and support files. If you've followed along this far, your /usr/local structure should be fairly mature and most software won't need you to create any more directories for it.


Some software that you try to install will want you to use the bsdmake version of the make program instead of just make (which in Apple's case is currently GNUmake). Apple has also provided a separate gnumake executable should you find software that wants GNUmake to be named gnumake or gmake. If you find a request for bsdmake in a README file (or software that complains about syntax errors in the makefile), try substituting bsdmake or gnumake for make at the command line. If you find a program that outputs what seems to be incomprehensible gibberish when you type make, give the other versions a try and see whether they do any better.

The configure step is typical as well, although the mechanics vary depending on the application you're compiling. Most of the time, configure can examine your system and either determine or make an educated guess about configuration options. Occasionally, it requires you to provide it with some information, but in most cases it's all right to accept the default answers suggested by configure if you don't have a better answer or don't know the answer.

Finally, let's run through the install of libpng because without it, the broken netpbm we're going to fix in the next section is truly hopeless:

 brezup:software source $ gunzip libpng-1.2.8-config.tar.gz brezup:software source $ tar -xf libpng-1.2.8-config.tar brezup:software source $ cd libpng-1.2.8-config brezup:software libpng-1.2.8 $ ls ANNOUNCE        config.sub      png.c           pngrutil.c CHANGES         configure       png.h           pngset.c INSTALL    pngbar.jpg      pngtest.c KNOWNBUG        contrib         pngbar.png      pngtest.png LICENSE         depcomp         pngconf.h       pngtrans.c     example.c       pngerror.c      pngvcrd.c     install-sh      pnggccrd.c      pngwio.c README          libpng.3        pngget.c        pngwrite.c TODO            libpng.txt      pngmem.c        pngwtran.c Y2KINFO         libpngpf.3      pngnow.png      pngwutil.c aclocal.m4       pngpread.c      projects      missing         pngread.c       scripts config.guess    mkinstalldirs   pngrio.c     png.5           pngrtran.c 

It has a configure, so use it:

 brezup:software libpng-1.2.8 $ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no ... config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands brezup:software libpng-1.2.8 $ 

Well, that's pleasant. It seems to have configured itself. Now it's time to try make:

brezup:software libpng-1.2.5 $ make make all-am if /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT png.lo -MD -MP -MF ".deps/png.Tpo" \ -c -o png.lo `test -f 'png.c' || echo './'`png.c; \ then mv ".deps/png.Tpo" ".deps/png.Plo"; \ else rm -f ".deps/png.Tpo"; exit 1; \. ... echo R_opts=\"-Wl,-rpath,/usr/local/lib\"; \ echo libs=\"-lpng12 -lz -lm\"; \ cat ./scripts/ ) > libpng-config cp libpng-config libpng12-config brezup:software libpng-1.2.8 $

If I had been working with an earlier version of libpng, that command would have stopped with an error, and I would have had to search around the documentation and FTP site to discover that there was an updated, custom makefile available for Mac OS X. Now, due to the magic of open source development, someone's fixed the bug for me and it all appears to have worked neatly.

Because there were no errors, and the installer doesn't appear to have a make test step, we're on to make install:

 brezup:software libpng-1.2.8 $ make install /bin/sh ./mkinstalldirs /usr/local/bin  /usr/bin/install -c libpng-config /usr/local/bin/libpng-config  /usr/bin/install -c libpng12-config /usr/local/bin/libpng12-config /bin/sh ./mkinstalldirs /usr/local/lib ... ---------------------------------------------------------------------- Libraries have been installed in:    /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:    - add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable      during execution See any operating system documentation about shared libraries for more information, such as the ld(1) and manual pages. ---------------------------------------------------------------------- ... mkdir -p -- /usr/local/man/man5  /usr/bin/install -c -m 644 ./png.5 /usr/local/man/man5/png.5 /bin/sh ./mkinstalldirs /usr/local/include/libpng mkdir -p -- /usr/local/include/libpng  /usr/bin/install -c -m 644 png.h /usr/local/include/libpng/png.h  /usr/bin/install -c -m 644 pngconf.h /usr/local/include/libpng/pngconf.h brezup:software libpng-1.2.8 $ 

All done. You've survived yet another software install. By now, this should be starting to look a bit more tedious than double-clicking an installer but no more threatening. Unfortunately, Mac OS X isn't as well supported in the configure scripts as some major Unix flavors just yet, so there are still a few rough spots like the makefile you would have needed to discover with the earlier versions. It's catching on quickly though, so soon, expect that 90% of all software will install with ./configure, make, make test, and make install, and no further interaction from you.


How can you enhance your chance of compilation success? You can make more installs work using the configure command by copying some files that Apple has provided into the software directory where you will be running configure. None of the installs shown here benefit from this, but copying /usr/share/automake-1.6/config.guess and /usr/share/automake-1.6/config.sub to the directory where you run configure might help with some compilations.

Installing the fink Ports and Packages Manager

Fink is a porting project, and fink is the software package manager it has produced for Mac OS X. It's an open source community project intended to bring the wide wild world of Unix applications to Mac OS X at a level of difficulty that the average Macintosh user won't find frustrating or, hopefully, even annoying. Because this book is being written on the bleeding edge of the release of Mac OS X 10.4, fink itself hasn't yet been updated to work with Tiger. Overall this isn't a large problem; fink will work in Tiger much like it works in earlier versions of the Mac OS, it simply might have some different defaults and might require a few months after the release to come up to full speed with respect to supporting applications. Hopefully, by the time you're reading this, everything will be working exactly as shown. If not, check the fink home page periodically (, because being able to use a package manager to facilitate large, multipackage software installs really is a huge convenience. There's even a GUI front end (available from that makes the installation of hundreds of useful applications that were historically installed from the command line into a point-and-click experience.


DarwinPorts, which we cover in the next section, is another, complementary ports management system for Mac OS X. At one point DarwinPorts was supposed to be incorporated directly into the operating system, but we've seen neither hide nor hair of this plan since Steve Jobs announced it at one of the MacWorld Expos. Still, installing it yourself isn't difficult and it's an incredibly useful tool to have for software installation.

When using fink, you have the choice of installing precompiled binary applications out of Fink's library or using fink as an automated system to work out and apply compilation details, building the software on your own system. Because the binary application library always lags a few versions behind what's available through the source distribution, and sometimes doesn't even provide versions of some software, we'll cover how to use the source distribution in this chapter. Using the source distribution is relatively easy easier than any of the command-line software installations you've seen. Using the binary distribution is even easier, if you've a reason to prefer to work with it (for example, it doesn't require that you have the developer tools installed).

Because we seem to constantly be revising this book on the cusp of major operating system changes, we've gotten used to the fact that the corresponding Fink version is rarely finished when we're writing. As a result, you get to have the most grueling introduction possible to using fink pretty much building everything from scratch, straight from the command line. Don't let this bother you. The Fink system is a study in automation the "most grueling introduction possible" requires you to type about a half-dozen commands, press the Return key to accept a few default prompts, and go have dinner. After you've done this, you can build entire applications with the simple command fink install <packagename>. The maintainers of Fink application porting projects do all the hard work of figuring out the quirks of making software work with Mac OS X and then package it so that all the interdependencies are known and codified. When a package is made available, all you need to do is ask fink to install it, and, along with any other required software, it'll be automatically downloaded, configured, and installed.


As the Tiger release approaches, we're becoming certain that these instructions won't exactly match what you'll see when you try to use the Fink system. Fink hasn't been updated to use the most recent Xcode (gcc) compilers, so portions of this will almost definitely not work on April 29th. Hopefully, Fink will catch up with Apple's changes again quickly!


Fink ( and DarwinPorts ( aren't the only package systems being promoted for Mac OS X, but they're among the best supported and the most honest. The gnu-darwin group ( is also doing very nice work. There's also a collaboration going on between a number of the porting projects, with news and links maintained at There are, however, other groups out there operating less from a desire to help further open source computing and Mac OS X than to line their own pockets by preying on the fact that many traditional Macintosh users find the command line intimidating.

If you're really willing to pay $30 to avoid having to type one single line at the command prompt, these people provide the service you're looking for. If you're not too intimidated by the command line, however, be mildly suspicious of people who want to sell you ported Unix software. Some of them are doing a fine job of providing ported software and additional value-added features or documentation that make their commercial distribution of free software well worth the money. However, the migration of Mac users to a Unix-based operating system has brought a whole crowd of vultures out of the woods hoping to make a quick buck. If it's a Unix application, there's a good chance you can find it for free from Fink, DarwinPorts, gnu-darwin, or another porting group on the Net. This isn't to say that gnu-darwin's ports CD is not a great deal at $30 that's only five cents per megabyte that you don't have to download and install. But when someone tries to charge you $30 for 5MB, or is downloading and selling web access to packages compiled and provided for free by Fink, DarwinPorts, and gnu-darwin, it should raise some eyebrows.

The first step in using fink to install software is to install fink itself. You need to do this only once, and despite the large volume of interaction we show here, it's really a simple process.

 brezup:ray Software $ mkdir finkcvs brezup:ray Software $ cd finkcvs brezup:ray finkcvs $ cvs login (Logging in to CVS password: 

The CVS password for anonymous, download-only access is empty, so just press the Return key at the password prompt.

brezup:ray finkcvs $ cvs -d:pserver:anonymous@ checkout fink cvs server: Updating fink U fink/.cvsignore U fink/AUTHORS U fink/COPYING U fink/ChangeLog U fink/INSTALL U fink/INSTALL.html . . . cvs server: Updating fink/update U fink/update/ChangeLog U fink/update/ U fink/update/config.guess U fink/update/config.sub U fink/update/ltconfig U fink/update/

Alternatively, you might be able to avoid the CVS checkout step and download a tarfile of the base fink installer source from Fink's downloads page as well ( This has the advantage of getting you the base system in a lump, but it will be several revisions behind the most recent, and you'll have to remove and install new versions to update, rather than simply being able to ask the CVS version to update and rebuild itself. Regardless of how you obtain the base distribution, your next step is to cd in to the directory (which might be named different things, depending on how you acquired it) and run the script to get everything configured.

 brezup:ray finkcvs $ cd fink brezup:ray fink $ ./ Welcome to Fink. This script will install Fink into a directory of your choice, setup a configuration file and conduct a bootstrap of the installation. Found perl version 5.008004. Checking package... looks good. Checking system... powerpc-apple-darwin8.0.0b2 This system was not released at the time this Fink release was made. Prerelease versions of Mac OS X might work with Fink, but there are no guarantees. Distribution 10.3 Fink must be installed and run with superuser (root) privileges. Fink can automatically try to become root when it's run from a user account. Avaliable methods: (1)  Use sudo (2)  Use su (3)  None, fink must be run as root Choose a method: [1] 3 ERROR: Can't continue as non-root. brezup:ray fink $ 

fink must have some way to run by the root user so that it can modify various things in semiprivileged directories. This is a poor design, but it's because Apple put things that shouldn't be root-owned, in places that only root can write. The script halted here because I don't like giving software the option of "becoming root itself," and I forgot to su or sudo at the start of the process. fink is capable of updating many Apple-supplied packages to more current versions, and the maintainers seem committed to keeping their software as Apple-friendly as possible. They appear to be making a conscientious effort to keep their installers from conflicting with Apple installations while providing updated versions of Apple-supplied software. I'm not a big fan of running installations as root, but given the level of attention that the fink project maintainers are paying to the quality of their code, I feel better about giving this software the go-ahead.

 brezup:ray fink $ sudo ./ Password: Welcome to Fink. ... Fink must be installed and run with superuser (root) privileges. Fink can automatically try to become root when it's run from a user account. Avaliable methods: (1)  Use sudo (2)  Use su (3)  None, fink must be run as root Choose a method: [3] 3 Checking cc... looks good. Checking make... looks good. Checking head... looks good. Please choose the path where Fink should be installed. [/sw] /sw OK, installing into '/sw'. Creating directories... mkdir -p /sw mkdir /sw/etc mkdir /sw/etc/alternatives . . . mkdir /sw/fink/10.2/local/main/finkinfo mkdir /sw/fink/10.2/local/main/binary-darwin-powerpc Copying package descriptions... . . . USAGE.html ChangeLog VERSION perlmod update mirror Creating initial configuration... OK, I'll ask you some questions and update the configuration file in '/sw/etc/fink.conf'. 

A considerable number of configuration choices follow, enabling you to suggest preferred locations of where you want to download various software bits as the system needs them. If you change your mind later, you can modify these choices with the command fink configure. Make choices that are appropriate for your system I've mostly just chosen the default values here.

 In what additional directory should Fink look for downloaded tarballs? [] (1)  Quiet (don't show download stats) (2)  Low (don't show tarballs being expanded) (3)  Medium (shows almost everything) (4)  High (shows everything) How verbose should Fink be? [4] 4 Proxy/Firewall settings Enter the URL of the HTTP proxy to use, or 'none' for no proxy. The URL should  start with http:// and may contain username, password or port specifications. [none] none Enter the URL of the proxy to use for FTP, or 'none' for no proxy. The URL should start with http:// and may contain username, password or port specifications. [none] none Use passive mode FTP transfers (to get through a firewall)? [Y/n] Y Mirror selection Choose a continent: (1)  Africa (2)  Asia (3)  Australia (4)  Europe (5)  North America (6)  South America, Middle America and Caribbean Your continent? [1] 5 Choose a country: (1)  No selection - display all mirrors on the continent (2)  Canada (3)  Mexico (4)  United States Your country? [1] 4 

A dozen or so configuration options sets go by, but despite the volume of options, accepting the defaults appears to work just fine. Next the program starts downloading and building the bits and pieces that it needs to construct itself. Self-collecting and building software neat, huh?

 BOOTSTRAP PHASE ONE: download tarballs. pkg gettext  version ### pkg gettext  version 0.10.40-3 pkg tar  version ### ... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl  -I/sw/bootstrap/include \ -g -O2 -c `test -f hash.c || echo './'`hash.c source='human.c' object='human.o' libtool=no \ depfile='.deps/human.Po' tmpdepfile='.deps/human.TPo' \ depmode=gcc /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl  -I/sw/bootstrap/include \ -g -O2 -c `test -f human.c || echo './'`human.c source='modechange.c' object='modechange.o' libtool=no \ depfile='.deps/modechange.Po' tmpdepfile='.deps/modechange.TPo' \ depmode=gcc /bin/sh ../depcomp \ ... 

(A very long time passes go have dinner!)

 ... BOOTSTRAP DONE. Cleaning up. rm -rf /sw/bootstrap dpkg-scanpackages dists/local/main/binary-darwin-powerpc override | gzip >dists/local/main/binary-darwin-powerpc/Packages.gz ... dpkg-scanpackages dists/local/bootstrap/binary-darwin-powerpc override | gzip >dists/local/bootstrap/binary-darwin-powerpc/Packages.gz  Wrote 14 entries to output Packages file. You should now have a working Fink installation in '/sw'. You still need package descriptions if you want to compile packages yourself. You can get them from CVS or by installing the packages.tar.gz tarball. Run 'source /sw/bin/init.csh ; rehash' to set up this Terminal's environment to use Fink. To make the software installed by Fink available in all of your shells, add 'source /sw/bin/init.csh' to the init script '.cshrc' in your home directory. Enjoy. 


If you're running tcsh, the rehash command is necessary. If you're running bash, it's not.

Now you almost have a working copy of the fink software installation system. The first thing to do when the prompt returns is to edit the file /sw/etc/fink.conf and change the line that reads

 Trees: local/main stable/main stable/crypto local/bootstrap 


 Trees: local/main stable/main stable/crypto local/bootstrap unstable/main unstable/crypto 


The exact list of trees that you'll want to configure is somewhat variable and depends on the state of the fink ports for both your current operating system and your version of the developer tools. This list shown is representative of a Mac OS X 10.2 installation using gcc 3.1, and allows fink to make available a number of applications that haven't been thoroughly tested but that largely work well nonetheless.

If you're interested in only stable release software (by stable, fink means "well tested"; much of the unstable software is considerably more stable than many commercial packages you probably use every day, but it hasn't been examined and tested to verify that it qualifies as stable by the rules of the project maintainers), you don't need to add the unstable/* entries. There's a fair quantity of interesting software that lives in the unstable branches, though, so it's probably worth leaving in there. You aren't obliged to install any of the software in those branches, but having the entry in the .conf file enables you to see the software in them from the installation interface, and you can make an informed choice.

The next thing to do is make that recommended change to your .bashrc or .cshrc file (add . /sw/bin/ or source /sw/bin/init.csh to the bottom of the appropriate shell startup file or watch to see what fink recommends as it finishes its run this syntax changes occasionally), and at the command line execute the file to load its configuration into your running shell (. /sw/bin/ or source /sw/bin/init.csh ; rehash, as appropriate).


This is important! fink installs software in a number of noncanonical places and a number of places that won't be in your path as provided by Apple or your previous modifications of your .bashrc/.cshrc file. /sw/bin/init.csh and /sw/bin/ set up a number of directory paths that fink uses, and if you don't add lines that run these files in your shell startup file, you won't be able to run any of the software the next time you log in.

Now you need to tell fink to update portions of itself using the software it just constructed in the bootstrap phase. (Again, tcsh syntax is used here because we can't stand bash as a user shell. If you're running bash, use . /sw/bin/, and ignore the rehash command.)

 brezup:ray fink $ source /sw/bin/init.csh ; rehash brezup:ray fink $ sudo fink selfupdate-cvs The selfupdate function can track point releases or it can set up your Fink installation to update package descriptions from CVS. Updating from CVS has the advantage that it is more up to date than the last point release. On the other hand, the point release may be more mature or have less bugs. Nevertheless, CVS is recommended. Do you want to set up direct CVS updating? [Y/n] Y Fink has the capability to run the CVS commands as a normal user. That has some advantages - it uses that user's CVS settings files and allows the package descriptions to be edited and updated without becoming root Please specify the user login name that should be used: [root] root For Fink developers only: Enter your SourceForge login name to set up full CVS access. Other users, just press return to set up anonymous read-only access. [anonymous] anonymous mkdir -p /sw/fink.tmp Checking to see if we can use hard links to merge the existing tree. Please ignore errors on the next few lines. touch /sw/fink/README; ln /sw/fink/README /sw/fink.tmp/README Now logging into the CVS server. When CVS asks you for a password, just press return (i.e. the password is empty). cvs login (Logging in to CVS password: Now downloading package descriptions... cvs -z3 checkout -d fink dists cvs server: Updating fink U fink/.cvsignore U fink/ChangeLog ... pkg apt-shlibs  version ### pkg apt-shlibs  version 0.5.4-5 pkg storable-pm  version ### pkg storable-pm  version 1.0.14-1 No packages to install. The core packages have been updated. You should now update the other packages using commands like 'fink update-all'. brezup:ray fink $ 

When this step finishes, you're ready to start using fink to install software. fink is also done with the finkcvs directory (it's the source and build directory for the fink command and related software, not for the software fink installs), so you can delete it now as well. All other installing, configuring, and updating is carried out in the /sw directory (or another location that you specified instead).

You have a choice of using fink to carry out software installations directly from the command line or from a menu-driven interface to the fink system. These options differ in a fundamental way: The command-line version uses the fink system to download and compile source directly on your computer, whereas the menu-driven system downloads precompiled binaries and installs them. There are advantages and disadvantages to each approach. A precompiled binary is usually quicker to download and install, but it might be out of phase with the software on your system, and you could be stuck waiting for someone else to submit a compiled version before you can download something that works on your system.

Using fink to compile, on the other hand, is generally slower, and you run a different but similarly annoying risk of the compilation parameters supplied by fink not being in sync with the compilers and libraries available on your machine. The maintainers of fink packages do a wonderful job of making installation via compilation simple and painless, but regardless of how carefully they try, there are always going to be machines configured by users who "think just a little more differently" than the fink maintainers anticipated in their installer scripts.


When we were writing for release 10.2 of Mac OS X, (September 17, 2002), the argument for the command-line compilation option won: The binaries available through fink hadn't been updated to be 10.2 compatible yet, but the source distribution had been updated to compile on 10.2. As of Sept 14, 2003, the binaries were winning for 10.3, as most of the binaries that worked on 10.2 also worked on 10.3, whereas the source distribution wasn't quite working yet. By the middle of 2004, the source distribution was back in the lead, and now that we're on the cusp of a Tiger release, it looks like binaries will have an advantage again for a short while. By the time you're reading this, though, the binary distribution will probably be behind again (being largely stuck in an earlier version of the compiler gcc), and the source distribution will be updated to work with your new operating system and corresponding new developer tools.

     < Day Day Up > 

    Mac OS X Tiger Unleashed
    Mac OS X Tiger Unleashed
    ISBN: 0672327465
    EAN: 2147483647
    Year: 2005
    Pages: 251 © 2008-2017.
    If you may any questions please contact us: