By Brian Jepson, Ernest E. Rothman

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: The Mac OS X Command Line

Content preview·Buy reprint rights for this chapter

The Terminal application (/Applications/Utilities) is Mac OS X's graphical terminal emulator. Inside the Terminal, Unix users will find a familiar command-line environment. The first section of this chapter describes Terminal's capabilities and compares them to the corresponding xterm functionality when appropriate. The chapter concludes with a listing of the Unix tools that developers can find on Mac OS X.

Mac OS X comes with the TENEX C shell (tcsh ) as the default user shell, the Bourne-again shell (bash ), and the Z shell (zsh ). Both bash and zsh are sh-compatible. When tcsh is invoked through the csh link, it behaves much like csh. Similarly, /bin/sh is a hard link to bash, which also reverts to traditional behavior when invoked through this link (see the bash manpage).

If you install additional shells, you should add them to /etc/shells . To change the Terminal's default shell, see Section 1.3.2, later in this chapter.

There are several important differences between Mac OS X's Terminal application and the xterm common to Unix systems running X Windows:

• You cannot customize the characteristics of the Terminal with command-line switches such as -fn, -fg, and -bg. Instead, you must use the Terminal's Show Info dialog.
• Unlike xterm, in which each window corresponds to a separate process, a single master process controls the Terminal. However, each shell session is run as a separate child process of the Terminal.
• The Terminal selection is not automatically put into the clipboard. Use -C to copy,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Mac OS X Shells

Content preview·Buy reprint rights for this chapter

Mac OS X comes with the TENEX C shell (tcsh ) as the default user shell, the Bourne-again shell (bash ), and the Z shell (zsh ). Both bash and zsh are sh-compatible. When tcsh is invoked through the csh link, it behaves much like csh. Similarly, /bin/sh is a hard link to bash, which also reverts to traditional behavior when invoked through this link (see the bash manpage).

If you install additional shells, you should add them to /etc/shells . To change the Terminal's default shell, see Section 1.3.2, later in this chapter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Terminal and xterm Compared

Content preview·Buy reprint rights for this chapter

There are several important differences between Mac OS X's Terminal application and the xterm common to Unix systems running X Windows:

• You cannot customize the characteristics of the Terminal with command-line switches such as -fn, -fg, and -bg. Instead, you must use the Terminal's Show Info dialog.
• Unlike xterm, in which each window corresponds to a separate process, a single master process controls the Terminal. However, each shell session is run as a separate child process of the Terminal.
• The Terminal selection is not automatically put into the clipboard. Use -C to copy, -V to paste. Even before you press -C, the current text selection is contained in a selection called the pasteboard. The operations described in Section 1.4, later in this chapter, use the pasteboard.
• The value of $TERM is vt100 when running under Terminal (it's set to xterm under xterm by default).
• Pressing PageUp or PageDown scrolls the Terminal window, rather than letting the running program handle it.
• On compatible systems (generally, a system with an ATI Radeon or NVidia GeForce AGP graphics adapter), the Mac OS X Terminal (and all of the Aqua user interface) will use Quartz Extreme acceleration to make everything faster and smoother.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using the Terminal

Content preview·Buy reprint rights for this chapter

The first order of business when exploring a new flavor of Unix is to find the command prompt. In Mac OS X, you won't find the command prompt in the Dock or on a Finder menu. The Terminal application is instead located in the /Applications/Utilities directory. Don't open it just yet, though. First, drag the Terminal's application icon to the Dock so you'll have quick access to it when you need to use the Terminal. To launch the Terminal, click its icon in the Dock once, or double-click on its icon in the Finder view.

The full path to the Terminal is /Applications/Utilities/Terminal.app, although the Finder hides the .app extension. Terminal.app is not a binary file. Instead, it's a Mac OS X package, which contains a collection of files, including the binary and support files. You can Control-click (or right-click) on the Terminal in the Finder and select Show Package Contents to see what's inside.

After the Terminal starts, you'll be greeted by the banner message from /etc/motd and a tcsh prompt, as shown in Figure 1-1.

Figure 1-1: The Terminal window

One difference xterm users will notice is that there is no obvious way to launch a new Terminal window from the command line. For example, Mac OS X has no equivalent to the following commands:

xterm &
xterm -e -fg green -bg black -e pine -name pine -title pine &

Instead, you can create a new Terminal window by typing -N or selecting File → New Shell from the menu bar.

To cycle between open Terminals, you can press

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Services Menu

Content preview·Buy reprint rights for this chapter

Mac OS X's Services menu (Terminal → Services) exposes a collection of services that can work with the currently running application. In the case of the Terminal, the services operate on text that you have selected (the pasteboard). To use a service, select a region of text in the Terminal, and choose an operation from the Services menu. Mac OS X comes with several services, but third-party applications may install services of their own. When you use a service that requires a filename, you should select a fully qualified pathname, not just the filename, because the service does not know the shell's current working directory. (As far as the service is concerned, you are invoking it upon a string of text).

Here is a list of the services available in the Mac OS X Services menu:

Finder

The Finder services menu allows you to open a file (Finder → Open), show its enclosing directory (Finder → Reveal), or show its information (Finder → Show Info).

Mail

The Mail → Send To service allows you to compose a new message to an email address, once you have selected that address in the Terminal. You can also select a region of text and choose Mail → Send Selection to send a message containing the selected text.

Make New Sticky Note

This service creates a new Sticky (/Applications/Stickies) containing the selected text.

Speech

The Speech service is used to start speaking the selected text. (Use Speech → Stop Speaking to interrupt.)

Summarize

This service condenses the selected text into a summary document. The summary service analyzes English text and makes it as small as possible while retaining the original meaning.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using the tcsh Shell

Content preview·Buy reprint rights for this chapter

The tcsh shell offers advanced command-line editing capabilities, filename completion, and a variety of customizations. Although tcsh is the default user shell, Mac OS X 10.2 (Jaguar) uses the Bourne shell (/bin/sh) for handling scripts (such as those found under the /etc directory), and we suggest you do the same. However, tcsh is a fine user shell, and this section explains how to customize it and take advantage of some of its features.

You can customize tcsh by changing certain environment variables, by creating aliases for frequently used commands, or by binding keys to commands (see "bindkey" in Section 1.5.4, later in this chapter).

If you want to make your customizations permanent (so you don't have to issue the commands each time you log in), put the appropriate commands in one of tcsh's startup files in your home directory. Here are some of the startup files into which you can put these commands:

.tcshrc

This script is executed each time you launch a shell. When you open a Terminal window, .tcshrc is executed. If you start a sub-shell (or run a csh shell script), .tcshrc will again be executed. If your .tcshrc contains recursive definitions, consider moving those commands to .login. For example, if you issue the command set path = ( $HOME/bin $path ) in your .tcshrc, then $HOME/bin will get prepended to your PATH environment variable each time you launch a sub-shell.

.login

This script is executed each time you launch a login shell, which includes opening a new Terminal window or logging in remotely. The .login script runs after .tcshrc. The .login

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Mac OS X's Unix Development Tools

Content preview·Buy reprint rights for this chapter

The version of Unix that you'll encounter in Mac OS X's Terminal is similar to other versions you have seen, but dissimilar in some fundamental and often surprising ways. Although most tools are in their usual place, some are not on the system, while others are not where you would typically expect to find them on other Unix systems.

The lists shown in this section contain a sampling of the Unix commands developers will find on Mac OS X. It is, by no means, a complete list of the Unix utilities found on your system. Because there are so many commands, they are organized into several categories. If you are an experienced Unix user, many of these commands will be familiar to you, but we've referenced them here so you can quickly determine whether or not a command you need is available. Unless otherwise specified, all of the tools in the following lists can be found in /usr/bin or /usr/libexec. Some tools are available with the standard distribution of Mac OS X, but others are available only after installing the Developer Tools. (See Chapter 4 for more information about the Developer Tools). Appendix B contains a listing of commands that don't have manpages on Mac OS X.

The following commands are development tools that are commonly found on Unix and Linux systems.

bison

A yacc-compatible parser generator.

cvs

A high-level revision control system that sits on top of RCS.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Startup

Content preview·Buy reprint rights for this chapter

The most striking difference between Mac OS X and other flavors of Unix is in how Mac OS X handles the boot process. Gone are /etc/inittab, /etc/init.d, and /etc/rc.local from traditional Unix systems. In their place is a BSD-like startup sequence sandwiched between a Mach foundation and the Aqua user interface.

This chapter describes the Mac OS X startup sequence, beginning with the BootX loader and progressing to full multiuser mode, at which time the system is ready to accept logins from normal users. The chapter also covers custom startup items, network interface configuration, and Mac OS X's default cron jobs.

When the computer is powered up, the firmware is in complete control. After the firmware initializes the hardware, it hands off control to the BootX loader, which bootstraps the kernel. After a trip into Mach, the control bubbles up into the BSD subsystem, and eventually into the Aqua user interface.

By default, Mac OS X boots graphically. If you'd like to see console messages as you boot, hold down -V as you start the computer. To boot in single-user mode, hold down -S as you start the computer.

BootX is located in /System/Library/CoreServices . It draws the Apple logo on the screen and proceeds to set up the kernel environment. BootX first looks for kernel extensions (drivers, also known as kexts) that are cached in the mkext cache. If this cache does not exist, BootX loads only those extensions in /System/Library/Extensions that have the OSBundleRequired key in their Info.plist file. Each extension lives in a folder (ExtensionName.kext), and the Info.plist file is an XML document that resides in its

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Booting Mac OS X

Content preview·Buy reprint rights for this chapter

When the computer is powered up, the firmware is in complete control. After the firmware initializes the hardware, it hands off control to the BootX loader, which bootstraps the kernel. After a trip into Mach, the control bubbles up into the BSD subsystem, and eventually into the Aqua user interface.

By default, Mac OS X boots graphically. If you'd like to see console messages as you boot, hold down -V as you start the computer. To boot in single-user mode, hold down -S as you start the computer.

BootX is located in /System/Library/CoreServices . It draws the Apple logo on the screen and proceeds to set up the kernel environment. BootX first looks for kernel extensions (drivers, also known as kexts) that are cached in the mkext cache. If this cache does not exist, BootX loads only those extensions in /System/Library/Extensions that have the OSBundleRequired key in their Info.plist file. Each extension lives in a folder (ExtensionName.kext), and the Info.plist file is an XML document that resides in its Contents subfolder. Example 2-1 is an excerpt from the /System/Library/Extensions/System.kext/Contents/Info.plist file.

Example 2-1. A portion of a kernel extension's Info.plist file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
          "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>CFBundleDevelopmentRegion</key>
    <string>English</string>
    <!-- multiple keys and strings omitted -->
  </dict>
</plist>

After the required drivers are loaded, BootX hands off control to the kernel (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Adding Startup Items

Content preview·Buy reprint rights for this chapter

To automatically start applications, you have two choices: start them when a user logs in, or start them when the system boots up. On most Unix systems, startup applications either reside in the /etc/rc.local script or the /etc/init.d directory. Under Mac OS 9, you could add a startup item by putting its alias in System Folder:Startup Items. Mac OS X has a different approach, described in the following sections.

To start an application each time you log in, use the Login Items panel of System Preferences. This is good for user applications, such as Stickies or an instant messenger program. For system daemons, you should set up a directory in /Library/StartupItems, as described in the next section.

If you compile and install a daemon, you'll probably want it to start at boot time. For example, MySQL will build out of the box on Mac OS X (you can download it from http://www.mysql.com).

A startup item is controlled by three things: a folder (such as /Library/StartupItems/MyItem), a shell script with the same name as the directory (such as MyItem), and a property list named StartupParameters.plist. The shell script and the property list must appear at the top level of the startup item's folder. You can also create a Resources directory to hold localized resources, but this is not mandatory.

To set up the MySQL startup item, create the directory /Library/StartupItems/MySQL. Then, create two files in that directory, the startup script MySQL and the property list StartupParameters.plist. The MySQL file should be an executable since it is a shell script. After you set up these two files as directed in the following sections, MySQL will be launched at each boot.

Section 2.2.2.1: The startup script

The startup script should be a shell script with StartService( ), StopService( ), and RestartService( )

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Scheduling Tasks

Content preview·Buy reprint rights for this chapter

Like other flavors of Unix, Mac OS X uses cron to schedule tasks for periodic execution. Each user's cron jobs are controlled by configuration files that you can edit with crontab -e (to list the contents of the file, use crontab -l).

The global crontab file is contained in /etc/crontab . It includes three cron jobs by default, which run the scripts contained in subdirectories of the /etc/periodic directory: /etc/periodic/daily, /etc/periodic/weekly, and /etc/periodic/monthly. Each of these directories contains one or more scripts:

/etc/periodic/daily/100.clean-logs
/etc/periodic/daily/500.daily
/etc/periodic/monthly/500.monthly
/etc/periodic/weekly/500.weekly

By default, /etc/crontab runs them in the wee hours of the night:

15 3 * * *       root    periodic daily
30 4 * * 6       root    periodic weekly
30 5 1 * *       root    periodic monthly

So, if your Mac is not usually turned on at those times, you could either edit the crontab file or remember to run them periodically using the following syntax:

sudo periodic daily weekly monthly

As you'll see in Chapter 3, it is vitally important that you run these jobs to ensure that your local NetInfo database is backed up.

You should not modify these files, because they may be replaced by future system updates. Instead, create a /etc/daily.local, /etc/weekly.local, or /etc/monthly.local file to hold your site-specific cron jobs. The cron jobs are simply shell scripts that contain commands to be run as root. The local cron jobs are invoked at the end of the 500.daily, 500.weekly, and 500.monthly scripts found in the /etc/periodic subdirectory.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: Directory Services

Content preview·Buy reprint rights for this chapter

A directory service manages information about users and resources, such as printers and servers. It can manage this information for anything from a single machine to an entire corporate network. The Directory Service architecture in Mac OS X is called Open Directory. Open Directory encompasses flat files (such as /etc/hosts), NetInfo (the legacy directory service brought over from earlier versions of Mac OS X and NeXTSTEP), LDAPv3, and other services through third-party plug-ins.

This chapter describes how to perform common configuration tasks, such as adding a user or host on Mac OS X with the default configuration. If your system administrator has configured your Macintosh to consult an external directory server, some of these instructions may not work. If that's the case, you should ask your system administrator to make these kinds of changes anyhow!

In Mac OS X 10.1.x and earlier, the system was configured to consult the NetInfo database for all directory information. If you needed to do something simple, such as adding a host, you couldn't just add it to /etc/hosts and be done with it. Instead, you had to use the NetInfo Manager (or NetInfo's command-line utilities) to add the host.

However, in Mac OS X 10.2 (Jaguar), NetInfo functions more as a legacy protocol. Instead of being a major player in the directory services world, NetInfo's role has been reduced to that of the local directory database for machines that are not participating in a network-wide directory, such as Active Directory or OpenLDAP. NetInfo is still present on Mac OS X systems, but you can perform most configuration tasks by editing the standard Unix flat files. By default, Mac OS X 10.2 is configured to consult the local directory (also known as the NetInfo database) for authentication, which corresponds to /etc/passwd and /etc/group on other Unix systems. You can override this setting with the Directory Access application. For more information, see Section 3.3, later in this chapter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Understanding Directory Services

Content preview·Buy reprint rights for this chapter

In Mac OS X 10.1.x and earlier, the system was configured to consult the NetInfo database for all directory information. If you needed to do something simple, such as adding a host, you couldn't just add it to /etc/hosts and be done with it. Instead, you had to use the NetInfo Manager (or NetInfo's command-line utilities) to add the host.

However, in Mac OS X 10.2 (Jaguar), NetInfo functions more as a legacy protocol. Instead of being a major player in the directory services world, NetInfo's role has been reduced to that of the local directory database for machines that are not participating in a network-wide directory, such as Active Directory or OpenLDAP. NetInfo is still present on Mac OS X systems, but you can perform most configuration tasks by editing the standard Unix flat files. By default, Mac OS X 10.2 is configured to consult the local directory (also known as the NetInfo database) for authentication, which corresponds to /etc/passwd and /etc/group on other Unix systems. You can override this setting with the Directory Access application. For more information, see Section 3.3, later in this chapter.

For users whose network configuration consists of an IP address, a default gateway, and some DNS addresses, this default configuration should be fine. You'll need to tap into Open Directory's features for more advanced configurations, such as determining how a user can log into a workstation and find their home directory, even when that directory is hosted on a shared server.

In order to work with Mac OS X's Directory Services, you must first understand the overall architecture, which is known as Open Directory. Directory Services is the part of Mac OS X (and the open source Darwin operating system) that implements this architecture. Figure 3-1 shows the relationship of Directory Services to the rest of the operating system. On the top, server processes, as well as the user's desktop and applications, act as clients to Directory Services, which delegates requests to a directory service plug-in (see Section 3.3, later in this chapter, for a description of each plug-in).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Programming with Directory Services

Content preview·Buy reprint rights for this chapter

As a programmer, you frequently need to deal with directory information, whether you realize it or not. Your application uses Directory Services each time it looks up a host entry, authenticates a password, or uses a printer. The Open Directory architecture unifies what used to be a random collection of flat files in /etc. The good news is that the flat files still work. The other good news is that there is a brave new world just beyond those flat files. So, while all your old Unix code should work with the Open Directory architecture, you should look for new ways to accomplish old tasks, especially if you can continue writing portable code.

To get at directory information, Unix applications typically go through the C library using such functions as gethostent( ). Higher-level APIs, such as Pluggable Authentication Modules (PAM) and Common Data Security Architecture (CDSA), also use the C library. Figure 3-2 shows how this works. The C library connects to lookupd, a thin shim that is the doorway to the DirectoryService daemon. The DirectoryService daemon consults the available plug-ins until it finds the one that can answer the directory query.

Figure 3-2: Accessing Directory Services

One possible route to user and password information is through the getpw* family of functions. However, those functions are not ideal for working with systems like Mac OS X that support multiple directories (flat files, NetInfo, LDAP, etc.). In particular, getpwnam( ) is not guaranteed to return a crypted password if the system has been configured to use another scheme, such as MD5 passwords. You should use the PAM API instead. PAM is included with, or available for, many flavors of Unix, so you can use it to write portable code. For more information on PAM, see the pam(8) manpage.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring Directory Services

Content preview·Buy reprint rights for this chapter

In order to configure Directory Services, use the Directory Access application (/Application/Utilities ), shown in Figure 3-3. You can enable or disable various directory service plug-ins, or change their configuration.

Figure 3-3: The Directory Access application shows the available plug-ins

Directory Access supports the following plug-ins:

AppleTalk

This is the ultimate Mac OS legacy protocol. AppleTalk was the original networking protocol supported by Mac OS versions prior to Mac OS X. Linux and the server editions of Windows also support AppleTalk.

BSD configuration files

These are flat files located in the /etc directory, such as hosts, exports, and services.

By default, the checkboxes for NetInfo and BSD Configuration Files are off. For the BSD Configuration Files, the checkbox controls whether the files are consulted for Directory Service lookups. NetInfo is a little more complicated. If the checkbox is off, NetInfo uses the local domain but does not consult network-based NetInfo domains. If the checkbox is on, NetInfo will also look for and potentially use any network-based domains that it finds.

LDAPv2

This is a version of LDAP that Mac OS X can access (read-only).

LDAPv3

This is a newer version of LDAP, which Mac OS X fully supports (read-write). This is the same version of LDAP used by Microsoft's Active Directory and Novell's NDS. Mac OS X Server includes both the client and server components of OpenLDAP (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

NetInfo

Content preview·Buy reprint rights for this chapter

The NetInfo directory is organized hierarchically, starting from the root, which, like a filesystem's root, is called /. However, this is not meant to suggest that there is a corresponding directory or file for each NetInfo entry. Instead, the NetInfo data is stored in a collection of files under /var/db/netinfo .

You can browse or modify the NetInfo database using NetInfo Manager, which is located in /Applications/Utilities . Figure 3-5 shows NetInfo Manager displaying the properties of the mysql user.

Figure 3-5: Browsing NetInfo

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

NetInfo Utilities

Content preview·Buy reprint rights for this chapter

This chapter demonstrates four NetInfo utilities: nicl, nireport, nidump, and niload. Table 3-1 describes these and other NetInfo utilities.

Table 3-1: NetInfo tools

Tool	Description
nicl	Provides a command-line interface to NetInfo.
nidump	Extracts flat file format data (such as /etc/passwd) from NetInfo.
nifind	Finds a NetInfo directory.
nigrep	Performs a regular expression search on NetInfo.
niload	Loads flat file format data (such as /etc/passwd) into NetInfo.
nireport	Prints tables from NetInfo.

The nidump and nireport utilities display the contents of the NetInfo database. niload loads the contents of flat files—such as

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

NetInfo Command Reference

Content preview·Buy reprint rights for this chapter

This section provides an overview of the NetInfo command-line utilities used in this chapter. The following sections, Section 3.7 and Section 3.8, demonstrate how to use nicl, nireport, nidump, and niload. For more details on these or other NetInfo utilities, see their respective manpages.

nidump

Syntax

nidump [-T timeout] (-r directory|format) [-t] domain
                  

Description

You can dump NetInfo information in a flat file format (such as the /etc/hosts format) or in a raw format that uses a C-like syntax:

{
  "name" = ( "localhost" );
  "ip_address" = ( "127.0.0.1" );
  "serves" = ( "./local" );
}

Options

-T timeout

Specifies a timeout in seconds.

-t

Treats the domain as a tagged domain, which includes a machine name and a tagged NetInfo database. For example, abbot/local refers to the local NetInfo domain of the machine named abbot.

-r directory

Dumps the directory in raw format. Directory should be a path to a NetInfo directory, such as /users/root or /machines.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Managing Groups

Content preview·Buy reprint rights for this chapter

NetInfo stores information about groups in its /groups directory. This is different from the /etc/group file, which is consulted only in single-user mode.

To list all of the group IDs (GIDs) and group names for the local domain, invoke nireport with the NetInfo domain (., the local domain), the directory (/groups), and the properties you want to inspect—in this case, gid and name:

% nireport . /groups gid name
-2      nobody
-1      nogroup
0       wheel
1       daemon
2       kmem
3       sys
4       tty
5       operator
6       mail
7       bin
20      staff
25      smmsp
31      guest
45      utmp
66      uucp
68      dialer
69      network
70      www
74      mysql
75      sshd
80      admin
99      unknown

Although the flat file format is called group (after the /etc/group file), the NetInfo group directory is /groups. If you forget that last s, NetInfo will look for the wrong directory.

The niload utility can be used to read the flat file format used by /etc/group (name:password:gid:members). To add a new group, you can create a file that adheres to that format, and load it with niload. For ad hoc work, you can use a here document rather than a separate file:

# niload group . <<EOF
? writers:*:1001:
? EOF
               

A here document is a shell quoting syntax that allows you to send data to standard input as though it had come in from a file. You can use this syntax interactively from the command line or in a shell script. The EOF tag, shown in the previous example, can be any text string. The here document starts with <<STRING and ends when STRING appears on a line by itself. For example, you can sort a bunch of words with here documents. (The ? character is supplied by the shell to let you know it is expecting input.)

% sort <<WORDS
? gamma
? beta
? alpha
? omega
? WORDS
alpha
beta
gamma
omega

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Managing Users and Passwords

Content preview·Buy reprint rights for this chapter

The NetInfo equivalent of the passwd file resides under the /users portion of the NetInfo directory. Mac OS X uses /etc/master.passwd for storing encrypted passwords. That master.passwd file is called the shadow password file because it shadows the other, nonsensitive information contained in the /etc/passwd file. Only the root user can read the shadow password file. Nonprivileged users can use the regular passwd file to discover other information, such as a user's full name or home directory.

The /etc/passwd and /etc/master.passwd files are consulted only while the system is in single-user mode, or if the system has been reconfigured to use BSD Configuration Files (see Section 3.3, earlier in this chapter). To add a normal user to your system, you should use System Preferences → Accounts. However, if you want to bulk-load NetInfo with many users or create a user while logged in over ssh, you can use nicl or niload.

You can list all users with the nireport utility. Supply the NetInfo domain (., the local domain), the directory (/users), and the properties you want to inspect (uid, name, home, realname, and shell):

% nireport . /users uid name home realname shell
-2      nobody  /dev/null           Unprivileged User       /dev/null
0       root    /var/root           System Administrator    /bin/tcsh
1       daemon  /var/root           System Services         /dev/null
99      unknown /dev/null           Unknown User            /dev/null
70      www     /Library/WebServer  World Wide Web Server   /dev/null

The niload utility understands the flat file format used by /etc/passwd (name:password:uid:gid:class:change:expire:gecos:home_dir:shell). See the passwd(5) manpage for a description of each field. To add a new user, create a file that adheres to that format and load it with niload. You can use a here document rather than a separate file. This example creates a user for Ernest Rothman with a UID of 701 and membership in the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Managing Hostnames and IP Addresses

Content preview·Buy reprint rights for this chapter

Mac OS X 10.1 (and earlier versions of Mac OS X) only consulted /etc/hosts in single-user mode and stored hostname/IP address mappings in the /machines portion of the NetInfo database. As of Mac OS X 10.2, you can use the /etc/hosts file to map hostnames to IP addresses. For example, the following entry would map the hostname xyzzy to 192.168.0.1:

192.168.0.1   xyzzy

If you are using Mac OS X 10.1.5 (or an earlier version of Mac OS X), you'll need to use NetInfo to maintain the hosts database. The niload utility understands the flat file format used by /etc/hosts (ip_address:name). See the hosts(5) manpage for a description of each field. To add a new host, create a file using that format and load it with niload. This example uses a here document instead of a separate file to add the host xyzzy:

# niload hosts . <<EOF
? 192.168.0.1 xyzzy
? EOF
               

If you add an entry that already exists, it will not be changed or overwritten. Instead, niload will silently ignore your command. (To override this behavior, see the -m option under "niload" in Section 3.6, earlier in this chapter.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Exporting Directories with NFS

Content preview·Buy reprint rights for this chapter

Mac OS X 10.1 (and earlier versions of Mac OS X) stored NFS exports in the /exports portion of the NetInfo directory. As of Mac OS X 10.2, however, you can use the /etc/exports file. For example, the following line exports the /Users directory to two hosts (192.168.0.134 and 192.168.0.106):

/Users  -ro -mapall=nobody 192.168.0.134 192.168.0.106

The NFS server will start automatically at boot time if there are any exports in the NetInfo database. After you've set up your exports, you can reboot, and NFS should start automatically. NFS options supported by Mac OS X include the following:

-maproot = user

Specifies that the remote root user should be mapped to the specified user. You may specify either a username or numeric user ID.

-maproot = user :[ group [: group ...]]

Specifies that the remote root user should be mapped to the specified user with the specified group credentials. If you include the colon with no groups, as in -maproot =username:, it means the remote user should have no group credentials. You may specify a username or numeric user ID for user and a group name or numeric group ID for group.

-mapall = user

Specifies that all remote users should be mapped to the specified user.

-mapall =

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Flat Files and Their NetInfo Counterparts

Content preview·Buy reprint rights for this chapter

As was mentioned earlier, NetInfo managed information for several flat files in earlier releases of Mac OS X, including /etc/printcap, /etc/mail/aliases, /etc/protocols, and /etc/services. For a complete list of known flat file formats, see the nidump and niload manpages.

Although you can edit these flat files directly as you would on any other Unix system, you can also use NetInfo to manage this information. You can use niload with a supported flat file format to add entries to NetInfo, or you can use nicl or NetInfo Manager to directly manipulate the entries. Table 3-2 lists each flat file, the corresponding portion of the NetInfo directory, and important properties associated with each entry. See the netinfo(5) manpage for complete details. Properties marked with (list) can take multiple values. (For an example, see Section 3.7.3, earlier in this chapter).

The "Wired into Directory Services?" column in Table 3-2 indicates whether Directory Services will consult the flat file when the BSD configuration files plug-in is enabled. In some cases, an operating system daemon may bypass Directory Services and consult a flat file, and Directory Services then has no knowledge of the flat file. For example, nfsd can consult either Directory Services or /etc/exports, but if it uses the flat file, it is consulting it directly and is not going through Directory Services.

Table 3-2: Flat files and their NetInfo counterparts

Flat file	NetInfo directory	Important properties	Wired into Directory Services?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Restoring the NetInfo Database

Content preview·Buy reprint rights for this chapter

If the NetInfo database is damaged, boot into single-user mode by holding down -S as the system starts up. Next, check to see if you have a backup of the NetInfo database. The /etc/daily cron job backs up the NetInfo database each time it is run. You can find the backup in /var/backups/local.nidump. If you don't have a backup, you won't be able to restore the NetInfo settings. The local.nidump file is overwritten each time the cron job runs, so make sure you back it up regularly (preferably to some form of removable media).

If your computer is generally not turned on at 3:15 a.m. (the default time for the daily cron job), you'll never get a backup of your NetInfo database. You can solve this problem by editing /etc/crontab to run this job at a different time, or to run the job periodically with the command sudo periodic daily. See Section 2.3.1 in Chapter 2 for more details.

After the system boots in single-user mode, you should:

1. Log in as the root user.
2. Fix any filesystem errors:

   # /sbin/fsck -y
                     

3. Mount the root filesystem as read/write:

   # /sbin/mount -uw /
                     

4. Change directories and go to the NetInfo database directory:

   # cd /var/db/netinfo/
                     

5. Move the database out of the way and give it a different name:

   # mv local.nidb/ local.nidb.broken
                     

6. Switch directories and go to the StartupItems directory:

   # cd /System/Library/StartupItems
                     

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 4: Compiling Source Code

Content preview·Buy reprint rights for this chapter

The Mac OS X Developer Tools are available from Apple and provide a development environment that will be familiar to any Unix developer whoworks with command-line compilers. For details about obtaining these tools, see the "Developer Tools" section in the Preface. The Developer Tools include all sorts of other goodies, including an advanced Integrated Development Environment (IDE), but coverage of those tools is beyond the scope and intent of this book. To learn more about the Developer Tools, you can see /Developer/Documentation/DeveloperTools/devtools.html. You can also learn how to use Project Builder and Interface Builder and how to program Cocoa applications with Objective-C in Learning Cocoa with Objective-C (O'Reilly) and Building Cocoa Applications: A Step-by-Step Guide (O'Reilly).

The C compiler that comes with the Developer Tools is based on the Free Software Foundation's GNU Compiler Collection, or GCC. Apple's modifications to GCC include the addition of Objective-C to the compiler suite, as well as various modifications to deal with the Darwin operating system. The development environment in Mac OS X includes:

AppleScript

This is an English-like language used to script applications and the operating system. AppleScript is installed as part of the Mac OS X operating system and does not require the Developer Tools package.

AppleScript Studio

This is a high-level development environment based on AppleScript that allows you to build GUI applications by hooking AppleScript into the Cocoa frameworks. AppleScript Studio is installed along with the Developer Tools package.

Compilers

These compilers are based on GCC and provide support for C, C++, Objective-C, Objective-C++, and assembly.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Compiler Differences

Content preview·Buy reprint rights for this chapter

GCC is supported on a wide range of platforms and is familiar to most Unix developers. A natural consequence of this is that most Unix developers will find a familiar development environment in Mac OS X. There are, however, some important differences.

One difference that experienced GCC users may notice, particularly if they have dealt with a lot of mathematical and scientific programming, is that Mac OS X's Developer Tools do not include FORTRAN. However, the Fink distribution (http://fink.sourceforge.net) includes g77 , the GNU FORTRAN '77 compiler. Also, the Darwin archive includes the source code for g77, which you can use to compile FORTRAN code. For more information on the Darwin CVS archive, see Chapter 7.

Mac OS X's C compiler contains a number of Mac OS X-specific features that have not been folded into the main GCC distribution. (It is up to the Free Software Foundation (FSF) to accept and merge Apple's patches.) For information on how Apple's compiler differs from the GNU version, see the README.Apple file in the Darwin CVS archive's gcc3 subdirectory.

As of this writing, Apple's cc compiler is based on GCC 3.1. However, GCC 2.95 is also available as /usr/bin/gcc2. By default, invoking cc or gcc will invoke GCC 3.1. You can change this to GCC 2.95 by running the command gcc_select 2, and you can change it back with gcc_select 3. You can see the current settings by running gcc_select with no arguments:

% gcc_select 
Apple Computer, Inc. GCC version 1161, based on gcc version 3.1
20020420 (prerelease)

You can find the Mac OS X Compiler Release Notes on your system at /Developer/Documentation/ReleaseNotes/Compiler.html. You should consult these release notes for details on the most current kn