From Unix to Mac OS X

OS X subsystem lingo

As a Unix user, you've unwittingly built up a quite a vocabulary of Unix-related terminology: kernel, X11, shell, xterm, package manager, window manager, GNOME, KDE, OpenGL, etc.. Though OS X has Unix underpinnings, it has its own systems layered on its Unix core, with their own terminology. Here's a quick primer on high-level terminology you're likely to come across sooner or later as a Mac OS X user (with the most important terms highlighted in bold).

Mac OS versions: Classic and the version-10 felines (Jaguar, Panther, Tiger, Leopard)

OS X (officially pronounced "oh ess ten," interpreting the "X" as a roman numeral, though in other settings—such as "X Server" and "Xcode"—it is pronounced as "ex") is the BSD Unix/NEXTSTEP-based successor to nine earlier versions of the Mac OS. Mac OS 9, the immediate predecessor, is called the Classic Mac OS, or just Classic for short. The successors are given "10.x" version numbers; they also have code names referring to large cats. As I write, OS 10.4, aka Tiger, is the current version; its predecessors were Panther (10.3), Jaguar (10.2), Puma (10.1), and Cheetah (10.0, a developer-only release?). The upcoming version is Leopard (10.5). Despite the increment in what appears to be a "minor" version number, each version offered significant feature additions to its predecessors. They've been spaced in time by roughly a year and a half. Jaguar is widely considered the first truly usable version of OS X; you'll seldom hear references to Cheetah and Puma. Despite Jaguar's success as a consumer platform, its Unix implementation had enough quirks that it was frustrating for Unix users. Panther greatly improved the situation. With Tiger, OS X provides a very solid Unix foundation for those migrating from "real" Unixes.

Core OS: Darwin

Darwin (Darwin @ Wikipedia) is the core of OS X. Its foundation is a version of the NEXTSTEP XNU kernel (XNU @ Wikipedia), a hybrid of the pioneering Mach microkernel (Mach @ Wikipedia)developed at CMU, and elements of the FreeBSD kernel. It integrates a customized version of the BSD Unix OS with Mac-specific services. Darwin also includes device driver support (via the I/O Kit object-oriented driver API), and the OS X file system. It can run independently of the rest of OS X; for example, GNOME can run on top of Darwin. Darwin is an open source effort moderated by Apple.

Low-level graphics: Quartz and OpenGL

Quartz (Quartz @ Wikipedia) is roughly the "X11 of OS X." Quartz is the low-level system that provides 2D rendering services and the core of the OS X windowing system, including window drawing, event routing, and cursor management. Like X11, it has a client/server architecture, though it doesn't offer the relatively transparent window networking of X11. The client is Quartz 2D (Quartz 2D @ Wikipedia) and is the API layer programmers typically access. The window server is Quartz Compositor (Quartz Compositor @ Wikipedia), the layer that handles communication with a graphics card.
Quartz's image model is a version of Adobe's PDF, providing very precise display control and facilitating easy and accurate printing of window content.
OS X includes an OpenGL implementation for 3D graphics. It renders in windows via the OpenGL "glue routine" API, which implements communication between OpenGL and Quartz Compositor.

Graphical user interface: Aqua

Aqua is not a technology per se, but rather a set of strict guidelines specifying the expected appearance and behavior ("look and feel") of OS X GUI elements. It gets its name from its water-inspired visual theme. Aqua is what gives unity to the Mac OS X GUI user experience. Various software systems provide much Aqua-compliant capability; e.g., Carbon and Cocoa (see below) implement windows and controls that follow the Aqua guidelines.

X11

OS X comes with the X11 windowing system, the familiar foundation of Unix window management. However, OS X does not use X11 itself, and the X11 server does not run by default. If you want to use X11 applications, you will need to start the X11 server (or the application's launch script must start it). Just double-click the X11 application to start the X11 server (it's in the Applications/Utilities folder; if you don't see it there, see the install instructions below). By default it will launch an xterm running your default shell, but you can alter this if you wish.
There are 3rd party X11 servers available for OS X. Apple's uses the Quartz environment to implement X11 in a way that attempts to give X11 windows a native look-and-feel, including provision of limited integration with native OS X applications (e.g., some drag-and-drop support). Apple's early X11 had enough differences from standard Unix versions that "power" X11 users had good reasons to consider alternatives (or hack Apple's X11). Recent versions appear to be more fully compliant with standard Unix X11 implementations.
Apple hosts an X11 FAQ addressing questions about X11 on OS X.

Carbon and Cocoa

Carbon and Cocoa are APIs for developing OS X applications. They include routines for everything from string handling and file system access, to window, menu and control implementations.
Carbon is a set of C APIs that implement a large subset of the earlier Mac OS 9 interfaces, as well as providing C access to new OS X technology. Carbon is especially suitable for porting older Mac OS applications, or for building new applications when developers want to use C or C++.
Cocoa is a very sophisticated set of object-oriented Objective-C APIs that provide high level access to OS X capability, allowing application development with a significantly reduced amount of code. Most modern OS X-specific applications are developed using Cocoa.

A Plethora of Subsystems: QuickTime, Core Graphics, Core Audio, Core Data...

Apple has created a large number of sophisticated technologies that operate as systems on top of Darwin and Quartz. They are not simply replacements for existing Unix counterparts; they are innovative extensions to the OS, several with no obvious Unix counterparts. They don't play any role in normal command line software development, so as a Unix developer you can safely ignore them. But as a Mac user you'll come upon some of them in one way or another.
The best-known such technology is QuickTime, a high-level API for handling audio, images, and movies, including support for many file formats and compression algorithms. Core Graphics ??? Core Audio provides OS X with professional-level audio processing capability, ensuring glitchless recording and playback, and providing extensive multi-channel processing capability. Core Data appeared in OS 10.4, and provides OS X developers with a high level API front end to powerful OS-level database capability based on SQL. These are just a few of the most prominent OS X technologies you'll bump into.

PowerPC and Intel processors: Universal binaries

Until 2006, OS X Macs all relied on PowerPC (PPC) processors from IBM and Motorola, starting with the G3 PPC version, and continuing through G4 and G5 versions. Tiger officially requires G4 processors, though it reportedly runs fine on G3s if you're clever enough to figure out how to circumvent the installer's G4 requirement. At the time of writing (early 2007), Apple ships a G5 Mac tower, but otherwise all new Macs run Intel processors. PPC and Intel processors have different architectures and instruction sets and cannot run the same executable code. You'll find some OS X software in two versions, PPC and Intel. But increasingly commonly you'll find universal binaries, application bundles that include both PPC and Intel executable code. The OS uses the code appropriate to the host.

The OS X file system

Though OS X is built on a Unix foundation, its file system isn't identical to that of any Unix platform. This is partly due to the need to support legacy files from earlier versions of Mac OS, and partly due to innovations unique to OS X. The following notes provide basic information about the OS X file system, highlighting some quirks that may be stumbling blocks for Unix users coming to OS X.

Volume formats

OS X has built-in support for the following volume formats:
• HFS+ (Hierarchical File System Plus, aka Mac OS Extended Format) - the default, recommended format for Mac-only volumes
• HFS (aka Mac OS Standard Format) - a legacy format supporting volumes dating to before Mac OS 8.1
• UFS (Unix File System) - an old and basic Unix-compatible format
• UDF (Universal Disk Format) - used for optical disks
• ISO 9660 - for CD-ROM volumes
• NTFS (NT File System) - a Windows format; OS X can read but not write to NTFS volumes
• FAT (MS-DOS File Allocation Table) - Windows format, with read and write access
Be aware that the various formats support different metadata; in particular, only the Mac OS formats support resource forks and other OS X-specific metadata (see below), and HFS+ includes support for standard Unix metadata. Stick with HFS+ if at all possible.
Note that many Unix systems include kernel-level support for the HFS+ format for removable media such as flash drives. This means you can use HFS+ formatted removable media both to store OS X files (preserving all metadata), and to transfer files to many Unix environments (the metadata will be lost in the transfer). For example, I have had no problems sharing OS X files with Fedora using HFS+ formatted flash drives (FAT also works); in contrast, UFS support of my flash drives proved problematic on the Unix side.
If you are using removable media to transfer files solely between OS X and Unix, I recommend HFS+ (if your Unix supports it). If you must maintain compatibility with Windows, use FAT. The most important benefit of HFS+ over FAT is that the former preserves Unix file metadata, including file permissions; FAT format does not. My main flash drive is in HFS+ format, supporting my Mac-Unix workflow, but I also keep a small flash drive in FAT format for storeing things like professional presentations that I may need to transfer to Windows computers.

Path separators: colon vs. slash

Earlier "Classic" versions of Mac OS used colons as separators in file path names. You may occasionally see paths specified with colons in documentation; just interpret them as Unix slash path separators.
For backward compatibility, OS X handles colons in file names specially. For example, if you create a file with a colon in its name via command line tools (e.g., " mv Junk.txt Junk:3.txt"), that file will appear in the finder with a slash character (not a path separator) in its name in place of the colon (e.g., "Junk/3.txt"). To avoid confusion, avoid colons in file names.

Case-preserving but case-ignoring

OS X preserves the case of file and directory names. But at the file-system level names are not distinguished by case. This was done in part for backward compatibility with Classic Mac OS. As a result, file names that differ only by character case collide. Thus, if "Junk.txt" exists in the current working directory, the following occurs:
$ cp Junk.txt junk.txt
cp: junk.txt and Junk.txt are identical (not copied).
$ ls Junk.txt
Junk.txt
$ ls junk.txt
junk.txt
A plain "ls" will list the file as a single file with its originally specified case, "Junk.txt" here.
Thus you may not use case alone to distinguish files within a single directory. This has the potential to cause problems with Unix software that uses case this way. But in practice I have never come across such problems.
Since case is ignored, if you rely on readline for name completion at the command line, consider putting this line in a .inputrc file in your home directory (this is the file the readline library reads for customizations):
set completion-ignore-case on
With this set, typing "ls ju<tab>" would complete to "cd Junk.txt".
Be careful about case when using removable media to transfer files to other computers. Not all volume formats handle case the same way.

Spaces in path names

Spaces are common in Mac OS file and folder names; they are directly supported by the Finder (i.e., you needn't escape them to use them). In a Unix terminal, they appear simply as spaces in a file listing, but at a prompt they must be entered via the usual Unix escape sequence, "\ " (backslash-space).
The installation process for some Unix software relies on slightly flawed configure scripts that cannot handle spaces in path names. If you attempt to install such software from a location with a space somewhere in its full path name, running "./configure" will fail, with confusing error messages about missing files that you know are present. If this occurs, rename enclosing folders or relocate the software to avoid spaces in the enclosing path.

Nonstandard hard links

OS X handles hard links differently than other Unix implementations.

Line endings in plain text files

The character codes that represent a newline in a plain text file vary between Unix (LF, i.e., line feed), Windows (CR+LF, i.e., carriage return followed by line feed), and Classic Mac OS (CR). Despite its Mac heritage, OS X adopts the Unix convention (LF). But many OS X applications that read plain text files can recognize the line ending automatically on examination of the file. This is true of the popular text editors discussed below. Keep this in mind if you are using an OS X text editor on a file that you intend to transfer to a Unix machine. Depending on the file's origin, it may have non-Unix line endings. Most text editors allow trivial transformation of a file from one convention to another; you can also find simple Perl and Python scripts to convert line endings. For more details, see Newline @ Wikipedia.

Access partitions and removable media via /Volumes

In the Finder, hard drive partitions and removable media can be accessed via icons on the Desktop, or via a Finder window opened to "Computer" (e.g., via the "Go" menu). At the command line, you can access these items via pathnames starting with "/Volumes". You can use "ls /Volumes" to identify the names of mounted partitions and media.

Bundles and packages

Bundles are directories that contain related content meant to be kept together, most often executable code along with resources related to that code (such as header files, help files, etc.). Most often, bundles have a special flag set so that they appear in the Finder as a single, simple file (i.e., not as a folder). OS X uses them to encapsulate related resources in a way that presents those resources to the user as a single unit. Applications (OS X GUI programs) are the most commonly encountered examples of bundles, but many other items are implemented as bundles, including plug-ins, preference panes, and frameworks (see below).
Most bundles you will encounter in OS X are packages, bundles that contain files and directories with a specific expected arrangement. Applications are packages (identified in part by a ".app" suffix, usually hidden by the Finder but visible at the command line). Also, OS X software installation is handled by distributing the software to be installed in an installation package. Apple's Installer application knows how to process the contents of such packages to install applications, libraries, and documentation in the right places in the file system.
In the Unix environment, bundles appear as directories; you may "cd" into them and do what you will with their content. But most bundles you encounter will be packages, whose contents must meet specific requirements for the package to operate as intended. Examine bundle content as you will, but modify it only if you know what you are doing.
The Finder supports access to bundle contents. If you Ctl-click a Finder item that is a bundle, the pop-up menu that appears will contain a "Show package contents" item. Selecting it will open a Finder window providing you access to the bundle content as if it were a normal OS X folder.

Dynamic libraries: Frameworks

Dynamic shared libraries are a mainstay of modern computing. To use libraries, you need access, not only to the binary file comprising the library's executable code, but also to header files for the library, and probably documentation. In a Unix environment, this material is stored in several locations adopted by convention: a lib directory for the executable (such as /usr/lib or /usr/local/lib), an include directory for the headers (such as /usr/include or /usr/local/include), and perhaps one of the man or info directories for documentation.
In OS X, you'll find /usr/lib, /usr/include, /usr/share/man and other such directories, just as on a Unix system (they are hidden in the Finder, but accessible from the command line). Many standard Unix libraries are maintained in these directories (thought note that the Mac file suffix for a shared library is ".dylib" rather than the ".so" common on Unix systems). But in addition, OS X supports another mechanism for maintaining dynamic shared libraries.
Frameworks are bundles that contain all the resources associated with a dynamic shared library, including the executable code, headers, and documentation. This nicely encapsulates all library resources, making it easy to switch between library versions or to uninstall a library. Most of the frameworks intended for system-wide use are stored in /Library/Frameworks, and appear in the Finder as normal folders with names ending with a ".framework" suffix. For the most part you will not need to know about these frameworks if you are developing command-line or X11 applications; they largely support OS X GUI and media-handling capabilities. But in some cases you'll need to know about a framework.
For example, although Apple ships a basic command-line version of Python with OS X (as /usr/bin/python), you can install a framework build of Python that allows interaction with the OS X GUI and application environment from within Python scripts. It gets installed as "Python.framework" in /Library/Frameworks (with a link to its command-line executable installed in /usr/local/bin/python). If you want to use it from the command line, you must make sure that your PATH provides access to it (e.g., put /usr/local/bin before /usr/bin in your PATH). And you may need to know about some of the scripts and files stored within Python.framework (e.g., if you want to build Fortran or C extensions to Python).

Metadata, file suffixes, and default applications

OS X supports the usual Unix file metadata, including the directory flag, file permissions (owner, group and others), creation date, etc.. But the OS X file system includes support for much additional metadata.
Users have easy access to some of this metadata via the Finder. If you select a file and then click on the "More info" button (if you are using Column view) or hit Cmd-I, the file's Info window will open, displaying a variety of metadata. You'll see creation and modification dates, and you can access Unix file permissions in the "Ownership & Permissions" part of the window (you can also read and alter these at a shell prompt as usual, with "ls -l" and "chmod"). You will also find various non-Unix metadata, known as extended attributes. These include a "Comments" field where you can enter plain text comments (these get examined when you use the Spotlight search tool), and specification of the default application for opening the document when it is opened in the finder. Some file types display other metadata as well.
There is metadata besides what you see in the Info window, however. You can view much of it via the command line with the mdls command. In fact, OS X file metadata is arbitrarily extensible, a feat made possible because the OS X file system supports forked files. A single OS X file-system file is actually potentially two files on its host volume: the data fork holding the data comprising the file's main content, and the resource fork holding metadata for the file. Unix commands typically access only the data fork.
Classic Mac OS relied heavily on resource forks. For example, applications would store the text for their menus and controls in the application resource fork. This simplified localization or customization of an application; the language used for menu items and buttons could be changed without having to recompile the application, simply by editing the resource fork contents. Applications could also store file-specific settings in the resource forks of documents, including such things as window size and position at the time of last use, or application-specific settings such as whether a text file should have Mac, Windows, or Unix line endings, or whether line numbers should be displayed during editing.
Most importantly, every Classic Mac OS file stored two fundamental resources in its resource fork, the file type and creator (encoded as 4-character strings). The type indicated, for example, whether the file was a plain text file, a rich text file (RTF), a Word file, an AIFF or WAV audio file, a Quicktime movie, etc.. The creator indicated the program the Finder should launch to open the file (e.g., Word for a Word or RTF file, Quicktime Player for a Quicktime movie, etc.). Apple maintained a database of registered type and creator IDs. Each application had a table of file types it was able to open. For backward compatibility, OS X has support for similar metadata, but the need for Unix compatibility makes such support complicated.
Mac OS X metadata presents two challenges for Unix command line users. First, important metadata must be preserved when using Unix commands to manipulate the file-system. The Unix implementation in Darwin mostly knows about OS X metadata, so basic commands like "mv" and "cp" preserve metadata (including resource forks). But more care must be taken when using command-line tools to archive files or to move OS X files back and forth between OS X file systems and other file systems. For example, "tar" does not archive file resource folks, "rsync" and "scp" do not copy resource forks unless given a special flag, and "sftp" only transfers data forks. This is particularly an issue if you use command-line tools for backups; more on this below.
The second challenge is in regard to file types and creators. Classic Mac OS use of type and creator resources made OS X support of legacy documents and applications a complex issue. The standard Unix file system has no formal support for file types and creators. Most typically, file suffixes indicate the file type merely by convention (e.g., ".txt" for text files, ".c" for C language source code files, ".mp3" for MPEG 2 layer 3 audio files, ".mpg" for MPEG movies, ".py" for Python scripts, etc.). Shell scripts might indicate a default program for running the script via the "pound-bang hack" ("#! /usr/bin/env ..."), but at the command line it is largely up to the user to figure out what program to associate with a given file. Window managers like GNOME can provide default application support for launching files from a file browser, but it is based on associating a file suffix globally with a single application. The default file creator cannot be altered for different files; you can't have one .jpg file open in XV by default, and another in the Gimp. Microsoft Windows operates similarly, with file suffixes tying files to applications.
OS X lives somewhat uncomfortably in both worlds. It has OS-level support for default applications associated with file suffixes, like Unix window managers. The Finder hides file suffixes from users by default (this can be altered), but they are there and play a role in identifying a file's default launcher (you can see them via a file's Info window). But OS X metadata can override the file suffix, allowing you to specify the default launch application for a file arbitrarily, regardless of its suffix. You can access this metadata via the Finder in two ways. If you Ctl-click on a file, the popup menu that appears offers an "Open with..." item. If you select it, you can choose the application with which to launch the file. If you hit the Option key before you select "Open with...", the menu item will change to "Always open with...". In this case, when you select an application, the file's metadata will be changed to reflect your choice of default application for the file. Alternatively, if you open a file's Info window, you'll find an "Open with" item allowing you to select its default application.
You can override the Finder's default choice of application associated with a file suffix as follows. Find any file with the suffix of interest, select it, and open its Info window. Choose the new default application. When you make your choice, click on the "Change all..." button in the same area of the Info window. This updates the Finder's suffix-application association table.
OS X metadata and its interoperability with Unix is a rich and complex topic. If you find you need to learn more about it, I recommend two documents:
•The challenge of integrating the Unix and Mac OS environments (a Usenix 2000 presentation by one of Apple's software engineers, Wilfredo Sánchez)
• Metadata, the Mac, and you
The bottom line is just to be aware that metadata is there; metadata issues may be the cause of subtle problems you come across. More often, they will just be a source of minor frustration if you work in a cross-platform environment. For example, if you use an OS X text editor to edit source code on your Mac, when you transfer the files to a Unix machine (say, via rsync to a flash drive or via sftp), work on them there and then transfer them back, their content will be as expected, but document-specific settings stored by the OS X application (such as window location and size) will be lost.

User accounts

Administrator & sudo

When you first started your Mac, OS X walked you through a process that set up your machine's first user account. Your first account's password is also the computer's adminstrator password. When you normally start OS X, even if you are the only defined user (and thus share the admin password), you are logged in as a normal user, not as the administrator. This protects the many system resources that should not be modified in normal use. However, your user account is automatically included in the "sudoer" list, giving you access to most root privileges when you request them via the "sudo" command.
By default, your Mac will not prompt you for your password when you turn it on. But make sure you remember it! When you use Apple's Installer or 3rd-party installers to install new software that writes into protected locations, OS X will prompt you for the admin password. You must know the admin password to install system-level software.
When you install Unix software at the command line (e.g., with the standard "./configure-make-make install" sequence), you will need admin access for the install step if it writes to protected locations such as /usr (and in some rare cases you'll need admin access for the make step). You needn't log in as "root" to install such software. Use your normal account, but rather than "make install," use "sudo make install." This will prompt you for the admin password, and run that single command with admin privileges. If you need to run a further command with admin privileges (e.g., if you are installing mutiple programs), just prepend "sudo" for any steps requiring admin access. You will not be prompted for the password every time, so long as you stay within a single shell process. A sudo authorization persists for 5 minutes since the last authorized sudo use (this can be changed; run "man sudoers" to learn how).
You will probably never need to log in as "root" on OS X; sudo should provide all the admin access you need.

Creating and changing accounts: Accounts preference pane

You can create new user accounts via the System Preferences application (available via the Apple Menu and in the Applications folder; you may want to add it to the Dock). Click on "Accounts" (in the System section); this will open the Accounts preference pane. You will have to click on the lock at the bottom to alter or add accounts; it will prompt you for the admin password.

Changing your default shell: Netinfo Manager

The Accounts preference pane suffices for standard OS X usage, but if you heavily use the command line, you should also know about the Netinfo Manager application (in Applications/Utilities). This application manages an XML database defining many properties for each user. Probably the most important is the choice of a default shell. OS X creates new accounts with bash as the default shell (for OS 10.3 and 10.4; earlier versions used tcsh). If you want to change this, launch Netinfo Manager. Select "users" in the tree navigator, select the username of interest, and a list of properties and values will appear in the lower window. Click on the lock to get admin access if you'd like to change any values. The default shell is determined by the "shell" property value.

Home directory

Special folders

When you first set up your OS X account, a home directory is created for you and populated with a number of folders. These serve special purposes and have unique icons identifying them as special. Do not rename these folders, and be cautious using them. In particular, don't move or delete any content in these folders unless you placed the content there, or you know what you are doing with "official" content.
The special folders include:
• Desktop - Items placed here appear on the user's desktop. You can access this folder in a Finder window to easily search for, add, or delete desktop files.
• Documents - Some software creates folders in Documents for storing user-specific databases. E.g., Quicken stores its user financial data here by default.
• Library - User-specific system preferences and application preferences are stored here, as are various resources that can enhance application behavior on a user-specific basis. For example, extra fonts, scripts (for automating actions of an application), and plug-ins may be stored here if they are not intended for use by all users. Use great care when modifying anything here.
• Movies, Music, Pictures - Apple applications such as iTunes and iPhoto store media in these folders (though the location can be safely changed via application preferences).
• Public, Sites - These folders facilitate sharing material with other users, either on your Mac, or via a network connection. Public is a read-only folder for OS X access; Sites is the default location exposed by the OS X HTTP server.
To learn more about these folders, launch Help Viewer (e.g., via the Help menu in the Finder) and search for "folders for personal items".

Changing your home directory: Netinfo Manager

Netinfo Manager, mentioned above for the default shell setting, is also the tool for altering the location of your home directory. However, as noted above, OS X keeps special material in your home directory, and Apple updaters may occasionally alter this material. If you alter the default home directory location, the updaters may not properly update this material. There are reports of such problems with early OS X versions; recent versions may have fixed this.
To play it safe, leave your home directory in its default location, if only to hold "official" user-specific resources. If you'd like to keep your main work in another location, simply create another directory there and work there. If you'd like your shell to open in that location instead of your home directory, you can accomplish this via the Terminal application preferences (more on Terminal below). If you do work largely in another location, make sure when you do backups that you still backup your official OS X home directory.

Network administration

Network protocols

OS X supports all the common network protocols at the core level, including DHCP, FTP, SFTP, SSH, HTTP, HTTPS, LDAP, PPP, SOAP, etc.. They are often handled by standard Unix tools; e.g., HTTP is handled via Apache.

Network services: Network & Sharing preference panes

You can control your network connection via the "Network" preference pane in System Preferences. For example, this is where you manage your TCP/IP connection, or a PPP connection for a modem. If you specified network settings during your initial Mac setup, you'll see them here. You may modify them, or define new network "locations"—collections of network settings. E.g., you might define separate network locations for your home and office.
You can easily activate and deactivate network services that expose your Mac to the outside world via the "Sharing" preferences pane (in the "System" section of System Preferences). For example, turn on "Personal web sharing" to activate the Apache HTTP server; turn on "Personal File Sharing" to share files with another Mac on your network via Apple's own AppleShare file sharing protocol.

System maintenance

Software update

Apple regularly posts updates to the current and previous version of OS X, including security updates, bug fixes, and occasional feature enhancements. You can find out if you need any updates by running Software Update (via the Apple menu) when you are online. You can even set Software Update to run on a regular schedule, to automatically keep you up to date. You may think of Software Update as OS X's counterpart to "yum update" or other Unix package manager updaters.
If you have a fast internet connection, use Software Update to download and install the updates it identifies (note that some updates may require you to restart your computer after installation; you will be warned about this before you commit to the install). If you have a slow connection, note the updates you need and quit Software Update. Download the required updates from Apple's web site using a machine with a fast connection. You'll find them in the "Support: Downloads" section of Apple.com (Apple: Support: Downloads). You can download the update files (installer packages with a ".dmg" suffix) onto a Windows or Unix computer, copy them to removable media, and then bring them to your Mac, and they will work just fine.
If you have multiple Macs, you needn't repeat the download for each Mac. When you run Software Update on the first one, click on the "Update" menu and select "Install and keep package." When installation is complete, you will be told where the packages were saved. You can then copy them to your other machines and launch them to install them.

Hardware and software info: System Profiler

For hardware maintenance, you may need to know details about your hardware—how much memory you have and in what configuration, what type of graphics card you have, what PCI cards you have installed, etc.. To access this information, select "About this Mac" in the Apple menu. The dialog that appears will identify your OS X version, your processor type and speed, and the amount of memory you have.
If you need more info, click on "More info" to launch System Profiler, or launch it directly from Applications/Utilities. It will provide comprehensive information about your hardware, as well as a list of installed applications, frameworks, fonts, and other logged system-level items, including version numbers. If you wish, you can save this information to a file, or print it.
You can also find the version number for an application using the Finder. Simply select the application. In column view, the version number will appear in the rightmost column (near the bottom). In other views, you can find the version number by opening the file's info window.

Disk formatting, mounting and repair: Disk Utility

To erase, format, mount and unmount partitions and devices, use Disk Utility (in Applications/Utilities). Removable devices such as CD-ROMs, flash drives, or hard drives connected via Firewire or USB, should mount automatically and can be unmounted and ejected via the Finder. But partitions on internal drives must be managed with Disk Utility.
Disk Utility should also be your first-choice tool for curing possible hard drive partition problems. It provides tools for verifying and repairing partitions (along the lines of fsck). Note that it cannot repair the partition currently running OS X; if you need to repair your system disk, boot your Mac from your installer CD, which has a copy of Disk Utility you can use for this purpose. If you have lots of free disk space, consider creating a partition where you'll keep a bare-bones OS X installation that you can boot into if you need to repair your main system partition, especially if you have a laptop and may not have your installation media always at hand.
For serious disk problems, several 3rd-party tools are available; popular ones include DiskWarrior and Tech Tool. These were must-have tools under Classic Mac OS. I have DiskWarrior and though it makes me feel safer, in six years of heavy OS X use I have yet to need it (though I have run it a few times as a maintenance measure).
The most important maintenance activity you will need Disk Utility for is to repair disk permissions. Proper operation of OS X requires that various directories and files have the proper Unix permissions. Sometimes applications inadvertently change them (or intentionally change them for installation purposes and neglect to restore them). Incorrect permissions can cause files or applications to not open, or to behave strangely. Disk Utility can access a table of correct permissions and repair the permissions on your system disk. Just launch it, select your system disk, and click on the "Repair disk permissions" button. It is a good idea to periodically repair your system disk permissions, especially after performing several software installations.

Backup tools

OS X includes standard Unix tools that Unix users commonly use for backups, e.g., rsync. However, the presence of non-Unix metadata in the OS X file system requires you to be cautious using such tools. For example, rsync will not copy extended attributes or resource forks by default. Apple's implementation adds a "-E" flag that enables syncing of such metadata. Apple also provides other command line tools specifically tailored for OS X file system backup, e.g. ditto. If you plan on using command line tools for backups, you must read Apple's document, "Command-line backup solutions on Mac OS X" (linked below, with other useful documents).
Consider using a 3rd-party tool for maintaining backups via a graphical interface. They typically involve maintaining an exact duplicate of a volume on external storage as a disk image (a file that can be mounted to appear as a disk in the Finder). Such tools typically rely on commands like rsync or ditto "under the covers." Two popular tools are SuperDuper! (shareware) and Carbon Copy Cloner (free). If you are used to rsync, there is also RsyncX providing a GUI front end to rsync, with metadata support.

Software installation

You'll be installing two different types of software: OS X applications (programs built specifically for OS X, usually using the OS X GUI environment), and Unix software (command-line and X11 programs and libraries). You'll install OS X applications using Apple's Installer application, which leads you through a painless installation dialog.
For Unix software, things are more complicated. If you are comfortable building software from source, you can do so, with a twist or two. But if you install a lot of software, relying on many libraries, you may want to use a package manager that keeps track of dependencies and can download and install software in a largely automated fashion. This information should get you started.

OS X's Installer

Most OS X applications are distributed as installer packages (files with an open box icon and a ".pkg" suffix), usually packaged as a binary disk image file (a compressed file format, identified by a ".dmg" suffix). You will double-click the .dmg file, which will mount a disk image on the desktop as if it were a removable disk drive. The contents will include the .pkg file (and possibly a ReadMe file or other material). Double-clicking the package will launch Apple's Installer application (which you'll find in Applications/Utilities). It will walk you through the installation dialog; you may be prompted for the admin password.

3rd party package managers

i-Installer

i-Installer is an open-source GUI-based package manager for Unix software on OS X that is relatively easy to use. Only a modest amount of Unix software has been packaged for i-Installer, but among this collection are some important tools for scientific users that aren't easily available in any other way. They include the TeTeX distribution of TeX, LaTeX, and other TeX-based tools and packages, GhostScript, GhostView, and XFig. See the "Setting up OS X" section for more on i-Installer and TeX on OS X. i-Installer has an uncertain future, which is unfortunate since it's the easiest way to get these tools on OS X if you are not using MacPorts or Fink.

MacPorts and Fink

MacPorts (previously DarwinPorts) and Fink are open source projects that bring the capabilities of popular Unix package managers (the FreeBSD and Debian package managers, respectively) to OS X. Each project hosts a slew of open source Unix software, with each installation process tailored (if necessary) to OS X. They can install binary packages (when available), or install software from source. Both projects provide both command-line and GUI-based package installation tools.
MacPorts recently migrated to Mac OS Forge, and open source software repository hosted by Apple. Unfortunately,
the transition has made its main web site confusingly uninformative. Your best entry point isn't MacPorts.org, but rather the MacPorts Wiki.
MacPorts maintains its packages under /opt/local. Fink maintains its packages under /sw. Niether directory normally exists in OS X, thus the packages each package manager installs are encapsulated. If you use either, you'll need to modify your command search PATH appropriately (recent installers may offer to adjust it automatically for you). The plus side of this encapsulation mechanism is that you can use either package with no worry of writing over Apple-installed software. The down side is that you are essentially maintaining "parallel" operating systems, creating the possibility of unintended name collisions.
Users are split in their opinions of these tools. If you use a lot of open source software (and thus must manage many dependencies), or if you are averse to the "configure - make - sudo make install" process for installing from source, you'll find one of these package managers essential. However, the fact that they install "parallel" environments can cause problems, e.g., if a dependency leads to installation of a MacPorts or Fink version of software that gets precedence over an OS X counterpart in your command or library search paths. For example, you may think you are executing one version of gcc, only to discover incompatibilities because Fink installed its own gcc. You may think you are linking against a version of libpng you installed, only to run into incompatibilities because Fink installed a different version that is earlier in your library search path. Or you may have installed g77, and find problems with your Fortran software because its Makefile first locates f77, which you didn't realize Fink installed. (I use Fink as an example only because that's the one I tried.) That said, many users swear by these package managers. Use them if they appeal to you—they are especially helpful for installing large packages like xemacs or GTK—but keep the potential for conflicts in the back of your mind.

Build from source: ./configure - make - sudo make install

To build Unix software from source, you can usually follow the standard install directions for the software, taking care to provide admin access with "sudo" as necessary. For example, much Unix software can be installed by unpacking the source distribution anywhere, and executing the common "./configure-make-make install" sequence, only substituting "sudo make install" for the last step, as noted above. This will succeed only if OS X includes the needed libraries, or if you have installed libraries not included with OS X yourself.
Sometimes you may need to alter the installation process to get a Unix package to install properly on OS X. Usually some other user will have figured this already; a Google search for "<package> 'OS X'" will turn up instructions.
Most Unix software installs by default into directories under /usr/local. OS X does not include this path in the default shell search PATH variable; you will have to add it in your shell startup files (see below).

Books

I'm not familiar with either of these books, but I've seen them often referred to regarding the topics covered here , so here are pointers.

Mac OS X Tiger for Unix Geeks

Learning Unix for Mac OS X Tiger

This is aimed at Mac OS X users who are new to Unix.

Terminal, X11/xterm, and Console

OS X comes with two applications in Applications/Utilities that launch terminal windows that provide shell access: Terminal and X11. Unless you are using X11 GUI software, Terminal will be what you use most (but see iTerm, below). It runs your default shell in a configurable window, with full integration with OS X (i.e., you can copy and paste text with the standard key commands, you can drag a file from the Finder to the terminal window to get the file's path, etc.).
Apple's X11 application launches an X11 server that runs in the background; by default it also launches an xterm running your default shell. It is not as fully integrated with OS X as a Terminal window.
Unix programs often send error and other messages to the system console. You can view these messages by launching Console (also in Applications/Utilities). Note that Console provides a read-only console, not a shell. Use its File menu to select among various console logs you can view.

.bashrc, .profile, and xterm

A quirk of Unix window managers or of OS X (depending on how you look at it) makes it wise to exercise more care with your shell startup files in OS X than you need to in a Unix X11 environment. I have yet to find a completely clear description of the situation; here I provide my current understanding. If you just want to know what to do without having to understand why, skip to the end of this section for sample .bashrc and .profile files, and instructions for making sure your xterms start login shells.
When you start a shell, it reads certain startup files for initialization, e.g., to define search paths, command aliases, and functions. Shells can serve different purposes; a shell launched in a terminal will be used interactively, but one launched for a script or by a Unix command will be non-interactive. Different uses require different initialization. For example, a non-interactive shell launched for a script or by a system command should typically inherit many settings from its parent shell. If it used the parent shell's startup file, it would waste time duplicating many inherited default environment settings; worse, it might override settings that were altered interactively in the parent shell.
For this reason, shell invocations look in different startup files for initialization information, depending on how they were launched. I'll discuss the situation for bash here, as that is the current OS X default shell.
For bash, interactive login shells, and non-interactive shells started with the "--login" option, read a ".profile" or ".bash_profile" initialization file (either in a system location, or in the user's home directory if present). The "login" property means these shells should be started "from scratch," defining everything the user expects in a brand new shell. Interactive shells that are not login shells, and standard non-interactive shells, instead initialize from a ".bashrc" file. These shells are usually launched from within another shell, and inherit that shell's environment settings. Thus the roles for the two startup files are as follows: .profile should define aspects of your shell environment that you expect to inherit from the login environment (e.g., PATH settings); .bashrc should define shell elements that do not get inherited, e.g., aliases and functions.
A quirk of the way most Unix window managers work lets Unix users be a bit lazy about startup files, so placing all initialization in .bashrc usually works. Unix window managers are based on X11. Logging in starts a root X11 server that handles all windowing, and a root xterm that opens a login shell, which reads .profile (or the system's /etc/profile). Every xterm you subsequently open runs via that root X11 server, and it starts an interactive non-login shell that inherits the login shell environment (this non-login startup is xterm's default behavior). These non-login xterms are all the xterms that you actually see. As a result, most Unix bash users put all their initialization material in a ".bashrc" file, and all their xterms end up reading this because they are started by another shell.
OS X does not run an X11 server by default. There is no login xterm running by default. The Terminal application opens an interactive login shell in each of its windows. Thus Terminal shells all start "from scratch" and read ".profile" and not ".bashrc" for initialization.
In contrast, when you launch X11 on OS X, it launches a rootless X11 server (since OS X is using Quartz to handle its windowing), which launches a default xterm. Recall that by default xterm launches a non-login interactive shell (presumably because it was designed to run in a root server environment). This shell reads ".bashrc" for its initialization, even though it has no parent shell from which to inherit login settings.
How can we get Terminal and xterm shells to share initializations? A quick-and-dirty approach is to maintain identical .bashrc and .profile files (or link one to the other). But a better approach is to (1) treat the .profile and .bashrc files properly, and (2) make sure that xterm launches a login shell. Here's how.
First, separate your initialization material properly between .profile and .bashrc. In .bashrc,
• Define shell elements that do not get inherited, most notably aliases and functions;
• Do not generate output to stdout (it can break commands like scp and rcp that start shells); if you want to generate startup messages, direct them to stderr.
In .profile,
• Start by reading system-wide defaults;
• Set environment variables, including PATH and variables determining shell behavior;
• End by reading .bashrc, to define aliases and functions.
Finally, to get the X11 default xterm to start a shell "from scratch" and read .profile, you have two options: you can customize X11 behavior so it starts a login xterm, or you can change your global X11 defaults so all xterms open login shells by default. To customize X11, launch it, and in its Applications menu choose the "Customize Menu..." item. Edit the Terminal command to be "xterm -ls" rather than just "xterm". That's it! If you'd rather change your X11 defaults, edit the .Xdefaults file in your home directory, and add the following line:
XTerm*.LoginShell: True
That will cause all xterms to launch a login shell by default.
Here are example startup files:
• Tom's .profile

• .Tom's .bashrc
Don't use them blindly; examine them and adjust them to your needs.

Shell/Finder interaction via" open"

At the command line you can use, not only standard Unix commands, but also numerous commands Apple provides to supplement Darwin's Unix core. Probably the most useful such command is "open" which opens a file, directory, or URL as if you opened it via the Finder. Apple's commands are documented with man pages, so you can learn about "open" via "man open". Briefly, if filepath is the path to a file (with respect to the current working directory), "open filepath" will open it with its default application, and "open -a AppName filepath" will open it with the specified application. If folderpath is the path to a folder, "open folderpath" will open that folder in the Finder; it works with "." and ".." as arguments as well, so "open ." opens a Finder window for the current directory, which can be handy. Finally, if URL is a URL, "open URL" will open the URL appropriately (e.g., by using your default web browser if it is an HTTP URL).

Printing

OS X applications provide simple print commands in their File menus. You can often do whatever printer management you need to do via the "Print..." or "Page Setup..." menu items there; most network and USB printers will automatically appear in the printer selection lists of these commands. If you need further control, use the "Print & Fax" preference pane in the Hardware section of System Preferences. If you need help with printer setup, click the "?" in that preference pane, which opens Help Viewer with a list of printer-related topics.
You may sometimes need to print files from the command line. OS X includes a CUPS implementation and includes standard Unix print commands such as "lpr," "lpq," and "enscript" that operate via CUPS.
A special case worth mentioning is printing to printers connected via AppleTalk, Apple's Mac-specific networking protocol, which can communicate to printers (and to other Macs) both via ethernet or via older Apple serial interfaces. Application printing treats AppleTalk printers no differently than other printers, but the command line distinguishes them. Use "atprint" to transfer data to an AppleTalk printer from the command line. It sends data from stdin, so it will typically be used in a pipe or with redirection. For example, to print a postscript file "file.ps" to a PostScript AppleTalk printer, use "atprint <file.ps". For more information, see the atprint man page. In particular, you may need to specify the default printer the first time you use atprint, via "sudo at_cho_prn"; see the man page for instructions.

coreutils for sh-utils

Unix scripting languages

OS X includes the three most popular Unix scripting languages, Tcl/Tk, Perl, and Python. You may need to install the Developer Tools (aka Xcode) to get them (see below). Older OS X versions required separate downloads for Tcl/Tk and Python. You can find Apple's Tcl/Tk distribution via a web search for "TclTkAqua", and OS X builds of Python are available from Python.org.
If you use Python, I strongly recommend installing a recent OS X build of Python from Python.org. Apple ships a basic command-line version of Python that lags a bit behind the current one; it is also not a framework build (as of OS 10.4). Recent OS X Python versions are framework builds of Python that integrate with OS X more fully than the version Apple ships.
Python offers integration with Apple's own AppleScript scripting language via the 3rd-party Appscript package. Search for and install it if you'd like to script OS X applications with Python. It isn't necessary if you are just doing standard Unix scripting.

AppleScript and opening Terminal windows

OS X includes a scripting language tailored to OS X applications called AppleScript. It was designed to be easy for non-programmers to use. As a consequence its syntax is closer to natural language than more familiar computer languages. Experienced programmers will likely find it frustratingly verbose (kind of like the bastard child of a union between the shell and COBOL!). Many modern OS X applications directly support AppleScript, i.e., they expose much of their functionality via AppleScript commands. Even those that do not can often be at least partially scripted via AppleScript access to their GUIs.
You won't need to learn any AppleScript to do normal Unix scripting. However, you may find a few AppleScripts handy to use to facilitate Unix command line use in the OS X environment (you don't need to know a thing about the language to use AppleScripts).
For example, you will probably often want to open a shell in a directory corresponding to a location you've navigated to in the Finder. Of course, you can open a Terminal window and navigate to the location from your home directory via "cd". But with AppleScript, you can tell the Finder to launch Terminal and automatically "cd" to the folder currently selected in the Finder.
Here is an archive OpenTermsScripts.zip with two terminal-launch AppleScripts (for Tiger) that accomplish this, one for Terminal, the other for iTerm (see below). To use them, unpack the archive (double-clicking should do this, creating a folder with the contents), and place the two scripts in your ~/Library/Scripts folder. There are two convenient ways you can invoke them. You can drag a script to the sidebar of a Finder window (the lower left area, where the icon for your home directory appears); it will then always appear in every Finder window, where clicking it will open a Terminal or iTerm window in the currently selected folder.
Alternately, the Finder can maintain a script menu in the menu bar, providing you access to any scripts you've placed in your Scripts folder. To activate the Script Menu, launch the AppleScript utility in the Applications/AppleScript folder; in the dialog box that appears, select the "Show Script Menu in menu bar" checkbox. By the way, the Script Editor application in this folder is what you use to write your own AppleScripts. You can use it to examine the Terminal and iTerm AppleScripts. To run a script, just click on the script icon in the menu bar, and select the script you want to run. You'll see that the menu provides access to dozens of scripts that Apple provides, besides whatever scripts you've placed in your Scripts folder.
If you come across a simple task that you suspect could be easily scripted with AppleScript, you may not have to learn AppleScript to accomplish it. Apple provides an application called Automator (in Applications) that lets you construct script-like actions by dragging and dropping basic steps in a workflow. A Google search will lead you to Automator tutorials. Also, a number of web sites collect useful AppleScripts that you can freely download.

Partition your hard drive

Your Mac comes with its hard drive formatted as a single partition. This is most likely fine for most users. But if you think you may want to use multiple partitions, now is the time to plan your hard drive organization. OS X's Disk Utility application (mentioned above, in Background: System maintenance) is the tool to use to partition your hard drive. But it does not support "live" altering of partitions; you'll have to reinstall everything on your hard drive if you use Disk Utility to repartition it. There are 3rd-party tools available that support live partition adjustments, but even those tools recommend backing up all your drive contents before altering a partition. To save yourself extra work, you might as well think hard about partitions now, before you start filling your hard drive with software and documents.
Just as examples, here are three ideas for additional partitions (besides your default OS X system partition) to consider. A Google search for "'OS X' partitions" will turn up other ideas for partitioning.
• Bare bones OS - Disk Utility is the "first call" disk repair tool, but it cannot repair the partition it is running from (neither can 3rd-party disk repair tools), so if your main system partition develops a problem, you will need to boot from a different volume to repair it. With a desktop machine, you're likely to have your system installation media handy; you can boot from the OS X install disk and run Disk Utility from it to do any needed repairs. With laptops, you may not have your installation disc handy. If you have lots of spare disk space, consider setting aside a few gigabytes for a "bare bones" OS X installation that you can boot from in the off chance you'll need to repair you main drive. Such a partition might also be handy if you need to test installations of software you are developing into a "clean" environment. Even on my desktop Mac, I maintain such a partition (on a second hard drive).
• Media - If you plan on using your Mac for audio or video authoring and editing, consider devoting a partition solely to the large media files you'll be working on, to avoid performance penalties from fragmentation. Ideally you would put such media in a separate drive from your system drive, so your authoring application isn't competing for disk access resources with the media itself. Even if you are not authoring media, but expect to compile a large media library (of music, photos, or video), consider devoting a partition to these files to simplify your backup routine. If you use Apple's software to access and organize your media (iTunes, iPhoto, etc.), you can use each application's Preferences menu item to specify where you'd like to maintain your media store.
• Projects - Since OS X stores important directories in a user's home directory, I like to keep all my projects and documents in a separate volume. This insures that I won't mess with the OS X directories in the course of my day-to-day work, and it also simplifies my backup routine: I just have to maintain a clone of the whole Projects volume (I back up my home directory and the OS X system directory less frequently).
If you do repartition your Mac, you'll have to re-install OS X on it. Your Mac should have come with instructions for this. Briefly: boot from your install disc (put the disk in your optical drive, turn on your Mac, and hold down the "C" key); the installer will lead you through the straightforward installation process.

Run Software Update

Apple may have released updates to OS X since the time it was installed on your Mac. Run Software Update (from the Apple menu) to check for any pending updates; install any you need (for example, you might ignore iPod-related updates if you don't use an iPod). See the System Maintenance section, above, for more info on Software Update.

Install additional Apple software

X11

Make sure Apple's X11 server is installed on your Mac. Look for it in Applications/Utilities. If an application named X11 is not there, use your system install media to install it (you will have to click the "Customize" button during the install process to get the menu allowing you to select X11). For very early versions of OS X, you may need to obtain the compatible Apple's X11 as a separate download if it was not included on your install media.

Xcode/Developer tools from ADC

Apple provides a free suite of developer tools for OS X, known originally as "Developer Tools," but more recently as "Xcode" (also the name of one of the tools in the suite). It includes standard Unix development tools like gcc and gdb, many libraries, as well as numerous sophisticated OS X-specific development tools. It lacks a Fortran compiler, however. To get gcc and other such tools, you must install Xcode.
Your Mac may have come with an Xcode install disc. You should probably ignore it. It is likely that Apple has updated the tools since your disc was pressed, and you'll want to download the latest version of the tools. To do so you'll have to create a free account at Apple's developer web site, Apple Developer Connection (ADC; click on the "Sign Up" link). Once you've registered, log in and go to the Downloads section. Download the most recent Xcode disk image (.dmg file). It will be about a gigabyte in size, so you must do this with a fast connection. Once downloaded, just double-click the downloaded disk image to mount it, double-click on the included package to start Installer, and follow the usual install dialog to install the tools.
Among the libraries installed by Xcode are Apple's versions of LAPACK and BLAS, optimized for Mac architectures, so there is no need for you to install these (or Atlas). The libraries are callable from C, C++, Objective-C, Objective-C++, and Fortran. On Intel Macs, recent versions of Tiger included multithreading support in LAPACK and BLAS (in the Accelerate framework), so they take advantage of multiple cores when available. For information on using these libraries, see Taking advantage of the Accelerate framework. A good source of community support for library usage is the Forums section of MacResearch.org.
The Unix tools will be installed in the usual paths (e.g., /usr/bin/gcc) so you'll be able to access them from the command line in the usual way. The OS X-specific developer applications will be on your system disk in the Developer folder (it has a hammer icon and is accessible from the command line at /Developer). If you are not developing OS X applications, you may safely ignore these applications. However, three of them are worth knowing about even if you are sticking to Unix-style command-line development.
If you anticipate you will be making use of Apple's Xcode applications for your Unix development, or especially if you anticipate doing OS X application development yourself, you should also download the latest version of the ADC Reference Library, which will provide a gigabyte of HTML developer documentation on your hard drive. You can also separately download a collection of the documentation as PDF files.

Xcode

Xcode is the heart of the Xcode tool suite. You'll find it in Developer/Applications. It is a GUI IDE. It has a syntax-aware editor that supports many languages, including C, C++, Objective-C, Java, Fortran, Perl, and Python. It has good project organization tools, and sophisticated language support for the main OS X development languages (C, C++, Objective-C, Java and Python; 3rd-party plug-ins are available for other languages). It is the default application for opening many source code files, including .c and .cpp files. You may want to use another text editor for your coding, especially if you will be moving between multiple platforms; but if you are coding predominantly on Macs, consider learning to use Xcode, if only as a source code editor.

FileMerge and opendiff

Xcode includes a very nice graphical version of the Unix "diff" file difference tool, called FileMerge. You'll find it in Developer/Applications/Utilities. If you launch it, it will provide a window where you can drag-and-drop files; comparing them presents them side by side, with highlighting showing the differences. At the command line, the "opendiff" command takes files or directories as arguments, and launches FileMerge to compare them. It has a man page detailing its use.

Property List Editor (in Utilities)

Also in Developer/Applications/Utilities is a handy basic XML editor called Property List Editor. Many parts of OS X store preferences and other data in XML property lists. You can edit such lists directly with Property List Editor, and you may find it handy for other XML documents that have a similar structure.

Unix-related Apple docs

While you're at the Apple web site downloading Xcode, grab the following three documents which are useful references for some of the Unix capabilities of OS X. If you've installed the developer documentation from ADC, you'll find HTML and/or PDF versions of these under Developer/ADC Reference Library:
Porting UNIX/Linux Applications to Mac OS X
Command-line Backup Solutions on Mac OS X - This document discusses the nuances of backing up your data via command-line tools, in a manner that preserves OS X metadata. Some of these issues are summarized briefly in the Metadata section, above.
Mac OS X Technology Overview- This document provides more in-depth coverage of the material in the Background section, above, and lots more besides. Of special attention is "Appendix C: Mac OS X Developer Tools." It provides descriptions of both Xcode applications and command-line developer tools. For example, it includes a list of command-line version control tools that ship with OS X (which includes only RCS, CVS, and file comparison tools like diff; more on version control tools below).

Bear Access

Cornell users should download the OS X Bear Access software from the Bear Access web site. Bear Access includes many tools, and you probably won't be interested in some of them. Some, however, are crucial for Cornell users. You can select which tools to install. Most of them install in a Bear Access folder in your Applications folder. The notable exception is Norton Antivirus, which installs in its own folder in Applications. These are the most important Bear Access applications:

Kerberos

Kerberos handles authentication for access to various Cornell online resources, most importantly library resources and benefits services. You won't have to pay any special attention to it; it will be launched automatically as required. You will need to know your Cornell login info to use it.

Norton Antivirus

Macs suffer fewer virus attacks than other computers, but Mac viruses do exist, so it is wise to install Norton Antivirus. Note that it installs with a number of default settings that you may wish to adjust. In particular, by default it will search removable media for viruses when the media is mounted. This can be time consuming and annoying. You can adjust this and other settings via Norton preference panes that get added to System Preferences; you can also access them from the Antivirus application itself.

Eudora mail client

Bear Access includes a popular OS X mail client called Eudora. Once a commercial application, it has just become open source. OS X includes a very capable and popular mail client called, imaginatively enough, Mail. It's in your Applications folder, but is also put in the Dock by default (it has a postage stamp icon). You needn't install Eudora if you are happy with Mail (or if you handle your email on another computer or via the web). Comparisons are subjective, but a common point of comparison between Mail and Eudora is that Eudora has exceptionally fast search capabilities, so some users with particularly voluminous email favor it. The Mozilla Project's Thunderbird email client is another popular email client for OS X, providing an option that runs under both OS X and Unix; get it from Mozilla.com's Thunderbird site.

Fetch & dataComet

Bear Access includes OS X applications providing GUI access to sftp and ssh, Fetch and dataComet, respectively. These were crucial back in pre-OS X days, and remain useful for users who prefer GUI interfaces. If you are happy using sftp and ssh from a shell prompt, you needn't bother with Fetch and dataComet.

Firefox

Bear Access includes an installer for the Gecko-based Firefox web browser. It may not be the most recent version, so you are probably better off getting the latest installer from Mozilla.com's Firefox web site. See the 3rd-party software section, below, for more information about OS X web browsers.

Essential 3rd-party software

Fortran compilers and scientific computing tools

As noted above, Xcode does not include a Fortran compiler. At least two free Fortran compilers are available for OS X (g77 and gfortran); commercial Fortran compilers are also available. You can find out about them (and download binary builds of the free ones) at the High Performance Computing for Mac OS X web siteHigh Performance Computing for Mac OS X.
Note that, as of OS 10.4, Xcode installs multiple versions of gcc, with gcc4 active by default. As in a unix environment, you can change the version used by the gcc command via the gcc_select command. It is important to be aware of the version you are using if you are using a free gnu-compatible Fortran compiler. g77 should be used with gcc3, and gfortran with gcc4. Intel-based Macs can only run code built with gcc4, so if you need a free compiler for an Intel Mac, use gfortran, not g77. In general, gcc3 is used for OS 10.3 development (Xcode for 10.3 does not include gcc4), and gcc4 is used for OS 10.4 development.
Intel provides highly regarded commercial optimizing compilers for Intel Macs. They offer both a "Standard" version a "Professional" version that adds an optimized math kernel.Intel® Fortran Compiler 9.1, Standard and Professional, for Mac OS* - Intel® Software Network

TeX/LaTeX/GhostScript on OS X

There are several web sites with comprehensive coverage of TeX, LaTeX, and related tools for TeX-based document preparation on OS X. Here I will just offer a quick set of pointers.
You will most likely want to install a command-line version of the teTeX package, the standard TeX package available in most Unix environments. If you are using MacPorts or Fink, you can install it via their package managers. Alternatively, you can use i-Installer to install TeX Live—a teTeX superset—in the usual locations you'd find it in a Unix environment. Here I'll briefly cover the i-Installer option; for thorough i-Installer instructions visit Gerben Wierda's TeX on OS X web site (scroll down to "The gwTeX (re)distribution" section; the earlier material is for TeX newbies). See Joseph Slater's Getting Started With TeX (on OS X) and the Mac OS X TeX/LaTeX Web Site for more comprehensive coverage of other options, and for discussion of various tools facilitating using TeX in OS X. MacDevCenter's LaTeX: It's not just for academia provides an additional useful but somewhat dated (2004) overview.

Installing TeX Live and related software via i-Installer

It appears that CTAN is now hosting an all-in-one package for installing TeX Live, Ghostscript, TeXShop (see below), and other useful tools, based on the i-Installer packages. This may well be the quickest way to get what you need to be productive with TeX on OS X. See TeXShop's Obtaining TeXShop web page for instructions (scroll down to "Obtaining TeXShop and TeX Live"). You may still want to use i-Installer directly to get a few tools and libraries, e.g., Ghostview.
TeX is big; to install it you'll need a fast internet connection. Download i-Installer and install it; the application will be put in your Applications/Utilities folder. Launch it and select the "i-Package>Known Packages i-Directory" menu item. You'll be presented with a window whose main pane will list many packages you may download and install. Select "gwTeX based on TeX Live" (double-click on it). An install window will open; click on "Install and configure" and then choose "Simple install." The installation will take a little while.
While you are in i-Installer, you very likely should install other tools you rely on for TeX use under Unix. Top contenders are Ghostscript 8, and Ghostview for X11R6 (the gv command, which you'll have to run from an xterm); ImageMagik and XFig can also be handy for generating and manipulating graphics for your TeX documents. Don't go crazy—some of the listed libraries are in fact already in OS 10.4 (they were missing in earlier versions).

TeXShop and Lyx

If you've relied on LyX in your Unix environment for (nearly) WYSIWYG LaTeX document processing, you'll find an official port for OS X at the LyX web site. Also very popular is TeXShop, an OS X application that uses pdftex and pdflatex to provide live previews of TeX and LaTeX documents. Other TeX-based authoring environments are described in the documents listed above.

iTerm iTerm

A Terminal application window, or an X11 xterm window, is a perfectly capable terminal emulation tool for Unix command line work. But they have a worthy competitor in iTerm, an open source terminal emulator for OS X. It has several features missing from Apple's Terminal. The most useful is that iTerm windows support tabs. This allows you to open several shells that share the same window area; you switch from one to the other by clicking a tab along the top of the window (like "tabbed browsing" in modern web browsers). This helps reduce workspace clutter.

Adobe Reader

OS X's Quartz rendering engine is based on PDF, so it will come as no surprise that OS X includes a built-in PDF viewer, Preview (in Applications). This is the default PDF application in OS X. It is fast to launch and offers some capabilities lacking in Adobe's AdobeReader, most notably the ability to notate PDF files. But it lacks many features of AdobeReader. You will probably want to download AdobeReader for OS X from Adobe's web site. If you want it to be your default PDF viewer, consult the instructions for changing default applications in the Metadata section, above.
The Adobe Reader installer that Adobe makes available on its web site is a small installer that uses your network connection to download the rest of the (large) installer. It isn't suitable for off-line installation. If you need to download a self-contained installer to move to a Mac for off-line installation, you'll have to hunt for one on Adobe's ftp site. A Google search will usually turn up the ftp URL for the latest installer, unearthed by an enterprising hacker and posted at VersionTracker or another similar web site. Here is the URL for a recent version, version 7.0.9: ftp.adobe.com.

Text and source code editors

OS X comes with a text editing application called TextEdit (in Applications). It's a basic text editor and word processor, capable of editing plain text files, or rich text files (which it can store in RTF, HTML, or Word format). You can switch back and forth between plain text and rich text via its Format menu. It is only suitable for basic editing, and for viewing plain text, rich text, and Word files. Your Mac may also have come with the iLife software suite, which includes a full-featured word processor. But you'll still be lacking a programmer's text editor.
As noted above, when you install Xcode, you get the Xcode IDE, which is a full-featured programmer's text editor, but much more. However, you'll probably want something more light weight, if not for all your programming, than perhaps for smaller tasks or projects. There are many options; here are some of the most popular.

emacs/xemacs and vim/gvim

OS X's Unix implementation includes the Unix command-line text editors emacs and vim, which you can access from a terminal window. If you are happy working exclusively within a terminal window, emacs or vim may suite you fine. But you may want something more integrated into OS X, e.g., something with more of a GUI interface, or something that can interact more completely with OS X (e.g., supporting drag-and-drop, standard Mac file dialogs, etc.).
The open source community has produced several alternative versions of emacs attempting to meet these needs. I am less familiar with vim options. A Google search for "emacs [vim] 'OS X'" should turn up what's available. The field is constantly changing and I haven't kept up-to-date with the latest developments, so I'll just highlight a few key resources here. For more comprehensive coverage of emacs, see EmacsForMacOS @ EmacsWiki.org. A MacVim Wiki is reportedly in development, but it was not online as of this writing.
XEmacs - This is the Unix emacs fork that has some GUI capability via X11; you'll need to run it via X11, launching it from an xterm. You can install a standard xemacs via MacPorts or Fink. If you don't mind building from source, the XEmacs site provides pointers to patches producing a Carbon port of XEmacs (which presumably doesn't need X11).
Carbon Emacs — Seiji Zenitani's Carbon port of the current Emacs
Aquamacs — An "Aqua-native" emacs
Emacs.app — GNU Emacs built with Cocoa
Vim.app — Vim as an OS X application
Be careful about key bindings with these "emaxen;" some of them alter GNU emacs so that standard Mac text edit key bindings replace the default Unix key bindings.
See these web sites to learn more about emacs options on OS X:
???

TextWrangler, BBEdit, TextMate, Smultron, SubEthaEdit

The most popular OS X-native programmer's editors are probably Bare Bones Software's BBEdit (commercial) and TextWranger (free), TextMate, Smultron, and SubEthaEdit.
BBEdit is a long-lived and much-loved Mac product that continues to evolve as the OS evolves. It especially targets HTML editing and offers powerful and conventient HTML editing tools and features. But it is an excellent text editor for any plain text task, and includes syntax coloring for all major languages (though not more sophisticated language features such as code completion). It can be launched from the command line.
TextWranger is essentially a "lite" edition of BBEdit that Bare Bones gives away for free. Despite its reduced feature set, it is still syntax-aware for all major programming languages. Being free, it really is a must-have for developers working on OS X.
TextMate is a relative newcomer to the Mac world, but has rapidly gained a dedicated clientelle; its developer came to OS X from Unix. Smultron is another new OS X text editor also rapidly gaining popularity among programmers. SubEthaEdit (winner of an Apple Design Award in 2003) is a unique offering in that it supports realtime collaborative editing, where users on different machines can edit a document simultaneously; it is thus particularly popular among extreme programming (Extreme Programming @ Wikipedia) advocates who rely heavily on pair programming. It also offers a command line utility.

Java-based editors: jEdit & Eclipse

OS X has very strong Java support, so the popular open source Java-based programmer's editors jEdit and Eclipse run just fine on OS X. If you are familiar with either, you know it isn't really fair to call either a programmer's editor. jEdit's plug-in architecture has led to the creation of dozens of plug-ins that enhance its basic editing capabilities, making it essentially an IDE for many languages (plug-ins provide various IDE capabilities, not just for Java, but also for C, Python, and other languages). Eclipse is not only more than an editor; it's more than an IDE. It was designed to be an extensible GUI application framework, and though its most popular use is as a Java IDE, its many plug-ins and "features" (sets of related extensions) make it a solid IDE for many other languages, as well as a GUI environment for many projects that aren't developer tools.
jEdit relies on standard Java GUI tools, and as a result its look-and-feel is not very Mac-like. The Eclipse project was unsatisfied with Java's GUI tools (for a variety of reasons), so Eclipse depends on platform-specific GUI libraries (included with the Eclipse installation). As a result, its look-and-feel is more Mac-like. But neither tool behaves like a true OS X application.
Both jEdit and Eclipse run fine under OS X, but Eclipse is very resource-hungry (both in terms of disk space and processor load), so you may find it frustratingly unresponsive if you have an older Mac (i.e., with a processor speed under 1 GHZ). Both will require some work to set up for your language of choice (you'll have to locate and install the necessary extensions; the same could be said of emacs). Eclipse also has a bit of a learning curve because of its high flexibility.
A particularly appealing feature of these options is their excellent support of multiple languages. Thus they are especially worth considering if your projects require you to work with multiple languages. I develop mainly in Python, but I write many Python extensions in C and Fortran. I find Eclipse with its Pydev, CDT, and Photran plugins to be a good environment for working on large multiple-language projects in OS X. But I find myself relying on more light-weight tools—BBEdit or xemacs being current favorites—for small projects, one-off scripts, or the occasional quick edit of part of a big project.

Version control tools

OS comes with command-line versions of the cvs and rcs version control tools, as well as file comparison commands such as diff. If you use other tools, such as svn or emerging distributed version control tools such as darcs, Bazaar-NG, or Mercurial, these tools (and others) are supported for OS X, but you'll have to install them yourself.
You can install SVN via MacPorts or Fink. A few generous OS X users host binary builds that can be easily installed without a package manager; two I know of are CodingMokeys' subversion and Metissian.com's subversion. SVNx is an open-source project providing a GUI front-end to the SVN client. wikiHow hosts an SVN How-To for OS X.
The darcs web site distributes a binary version (you can build it from source, but this involves building the entire Haskell language environment which is reportedly time-consuming).
Bazaar-NG (which operates via the bzr command) and Mercurial ??? (which operates via the hg command) are Python packages that install easily via the standard Python command-line package install sequence: "sudo python setup.py install".

Web browsers, wget

OS X includes Apple's own web browser, Safari (it is in the Dock by default, with a compass icon; you'll also find it in Applications). It uses Apple's open source browser engine, WebKit, and is a very good browser. It supports tabbed windows for browsing.
If you've used the Gecko-engine-based browsers Firefox or Mozilla under Unix, you'll be happy to know that there is a solid OS X version of Firefox available from Mozilla.com's Firefox web site. But if you prefer Gecko-based browsing to Safari, consider Camino as an alternative to Firefox. It is an open source companion to Firefox that relies on the same underlying Gecko technology, but uses Apple's Cocoa frameworks to provide a modern OS X interface. Both support tabbed window browsing.
You may find that some pages that fail to render correctly in a Gecko browser render fine in Safari, or vice versa. If you develop web sites, you should verify that they work both in Safari and in a Gecko-based browser. Microsoft stopped supporting their Internet Explorer browser for OS X a few years ago, so if you need to test your site on a recent version of IE, you'll need to use a PC.
As under Unix, there are many 3rd-party enhancements for OS X browsers. The most popular Safari enhancer is probably Saft(shareware). It provides countless new settings and capabilities. Most notably, it provides the ability to save the state of browser windows,
including all the tabs in a window. If you activate this feature, the state of all open windows is saved even if a troublesome web site causes your browser to crash; this is very handy. Another popular Safari enhancer is Sogudi. It provides various keyboard shortcuts to speed browsing. Most notably for developers, it lets you easily view Unix man pages in a browser window.
For Camino, CaminoSession provides the capability to save the browser state, including the same kind of crash protection that Saft provides to Safari.
OmniGroup, a highly respected OS X software development company, offers a commercial (but inexpensive) browser called OmniWeb that is quite popular. It uses WebKit, but offers several enhancements over the Safari implementation, most notably the ability to maintain web browsing workspaces. Rather than tabs, it lets you have many web pages share a window by providing tab-like buttons in a sidebar. If you open lots of tabs in your web surfing, you may find OmniWeb's sidebar and workspaces a nicer way to manage your browsing. It includes crash protection along the lines of what you get from Saft for Safari.
OS X's Unix implementation includes curl for fetching web page content from the command line, but it does not include the more capable wget command line web site grabber. If you miss it, you can install it from source easily via the usual "./configure - make - sudo make install" sequence. You'll also find a few binary versions available from generous OS X users, such as Merenbach.com's wget universal binary. If you have decided to use MacPorts or Fink for other purposes, you can easily install wget with either of these package managers as well.

Virtual workspaces and Exposé

As of Tiger, OS X does not support the virtual workspaces that are commonly supported in X11-based Unix window managers. A few 3rd-party tools implement virtual workspaces for OS X; see the OS X section ofWikipedia's Virtual Desktop entry for a list of options. Some of these implementations have been notoriously buggy; shop carefully (search for reviews and recent usage reports).
The absence of virtual workspaces was definitely a source of frustration before Panther. Panther introduced Exposé, an OS X capability that ameliorated some of the frustration. Exposé lets you hit function keys that give you quick thumbnail access to your open applications and windows. Learn how to use it. Now.
Note also that most OS X applications have a "Hide" command in their application menu (usually accessible via Cmd-H) that hides all of the application's open windows. You can get them back by clicking on the application's Dock icon, or by activating the application via the Cmd-Tab application picker.
Mac OS 10.5 (Leopard) will finally add a virtual workspace capability, Spaces.

Office applications

OpenOffice for Mac, NeoOffice, AbiWord (word processor only)

Less essential libraries and utilities

cocoaAspell

OS X includes its own spell-checker, and many applications rely on it. But it does not support command-line access. cocoaAspell provides Aspell for OS X, including a preference pane (accessed via System Preferences) for maintaining dictionaries and filters.

Web sites to bookmark

MacResearch.org

MacResearch.org hosts forums and other resources produced by the rapidly growing community of scientists and engineers relying on Macs running OS X for their scientific computing.

High Performance Computing for OS X

Rosetta Stone for Unix

This "Sysadmin's Universal Translator" offers a table of common sysadmin tasks, and the corresponding commands for accomplishing them under various Unix implementations, including OS X.

VersionTracker—Mac OS and MacUpdate

These web sites keep track of the latest versions of OS X software (commercial, shareware, and free and open-source software). They include reviews and ratings, and categorized lists for browsing.

Apple's OS X software index

O'Reilly's MacDevCenter

OS X as a Unix Workstation for Astronomy

Unix and OS X: The Absolute Essentials