Locating and Editing the OS X Configuration Files

http://www.samspublishing.com/library/content.asp?b=Mac_OS_X_Unleashed&seqNum=164&rl=1

Locating OS X configuration files and figuring out what can be put in them can sometimes be a bit of an adventure. It's difficult to determine the correct information to provide for some items in this chapter. Many configuration options and files that exist in OS X are not actually intended for you to use in the OS X client version. These parts of the configuration system are actually managed by tools provided only (for the moment, at least) by OS X Server. It's possible to diddle around with them, and to do some interesting things, but OS X doesn't provide the tools or the information to do a complete job of documentation or configuration. We'll do our best to provide you with up-to-the-minute information on what's been discovered to be tweakable in the system as of when the book hits the shelves. Please do check online information sources such as http://www.osxunleashed.com/ and http://www.macosxhints.com/ , and understand that it seems clear that Apple doesn't intend for the user to ever understand or modify some of these things.

Preference Locations

Unlike previous versions of Mac OS, which kept almost all its preferences in the Preferences folder of the System folder, OS X keeps its preferences in several different locations. Primarily these are the /etc/ folder, the NetInfo database, and the ~/Library/ Prefe r ences/ folders. Many preferences that affect the running of the system, such as what network services are started, the machine name, and such global information that does not change from login to login, are kept in the /etc/ folder or its subfolders. Other preferences of this nature are kept in the NetInfo database. Preferences that affect individual user configuration are primarily kept in files stored in ~/Library/Preferences/.

Preference Format

Preferences stored in files in the /etc/ directory generally follow longstanding Unix tradition, and are formatted according to their own individual file formats. For example, the file /etc/inetd.conf configures a number of the network services that your machine will provide to the outside world. The default inetd.conf file as it comes from Apple is shown in Listing 20.1. The # symbol in front of each item indicates that the line is commented out and will not be run. Apple very wisely leaves all these network services off by default. Many of them can be security holes, and it's best if you enable them only as you need and understand them.

Example 20.1. A Typical `/etc/inetd.conf` File

1  #
2  # Internet server configuration database
3  #
4  #        @(#)inetd.conf    5.4 (Berkeley) 6/30/90
5  #
6  # Items with double hashes in front (##) are not yet implemented in the OS.
7  #
 8  #finger   stream   tcp    nowait   nobody  /usr/libexec/tcpd  fingerd -s
9  #ftp      stream   tcp    nowait   root    /usr/libexec/tcpd  ftpd -l
10 #login    stream   tcp    nowait   root    /usr/libexec/tcpd  rlogind 
11 #nntp     stream   tcp    nowait   usenet  /usr/libexec/tcpd  nntpd
12 #ntalk    dgram    udp    wait     root    /usr/libexec/tcpd  ntalkd
13 #shell    stream   tcp    nowait   root    /usr/libexec/tcpd  rshd 
14 #telnet   stream   tcp    nowait   root    /usr/libexec/tcpd  telnetd
15 #uucpd    stream   tcp    nowait   root    /usr/libexec/tcpd  uucpd
16 #comsat   dgram    udp    wait     root    /usr/libexec/tcpd  comsat 
17 #tftp     dgram    udp    wait     nobody  /usr/libexec/tcpd tftpd /private/tftpboot
18 #bootp    dgram    udp    wait     root    /usr/libexec/tcpd  bootpd
19 ##pop3    stream   tcp    nowait   root    /usr/libexec/tcpd /usr/local/libexec/popper 
20 ##imap4   stream   tcp    nowait   root    /usr/libexec/tcpd /usr/local/libexec/imapd
21 #
22 # "Small servers" — used to be standard on, but we're more conservative
23 # about things due to Internet security concerns.  Only turn on what you 
24 # need.
25 #
26 #chargen  stream   tcp    nowait  root    internal
27 #chargen  dgram    udp    wait    root    internal
28 #daytime  stream   tcp    nowait  root    internal
29 #daytime  dgram    udp    wait    root    internal 
30 #discard  stream   tcp    nowait  root    internal
31 #discard  dgram    udp    wait    root    internal
32 #echo     stream   tcp    nowait  root    internal
33 #echo     dgram    udp    wait    root    internal 
34 #time     stream   tcp    nowait  root    internal
35 #time     dgram    udp    wait    root    internal
36 #
37 # Kerberos (version 5) authenticated services
38 #
39 ##eklogin  stream tcp   nowait root    /usr/libexec/tcpd   klogind -k -c -e 
40 ##klogin   stream tcp   nowait root    /usr/libexec/tcpd   klogind -k -c
41 ##kshd     stream tcp   nowait root    /usr/libexec/tcpd   kshd -k -c -A
42 #krb5_prop stream tcp   nowait root    /usr/libexec/tcpd   kpropd 
43 #
44 # RPC based services (you MUST have portmapper running to use these)
45 #
46 ##rstatd/1-3    dgram rpc/udp wait root    /usr/libexec/tcpd    rpc.rstatd
47 ##rusersd/1-2    dgram rpc/udp wait root    /usr/libexec/tcpd     rpc.rusersd
48 ##walld/1    dgram rpc/udp wait root    /usr/libexec/tcpd    rpc.rwalld
49 ##pcnfsd/1-2    dgram rpc/udp wait root    /usr/libexec/tcpd    rpc.pcnfsd
50 ##rquotad/1    dgram rpc/udp wait root    /usr/libexec/tcpd     rpc.rquotad
51 ##sprayd/1    dgram rpc/udp wait root    /usr/libexec/tcpd    rpc.sprayd
52 #
53 # The following are not known to be useful, and should not be enabled unless
54 # you have a specific need for it and are aware of the possible implications 
55 #
56 #exec    stream    tcp    nowait  root  /usr/libexec/tcpd   rexecd
57 #ident   stream    tcp    wait    root  /usr/libexec/tcpd   identd -w -t120

This is probably the most important /etc/ preference file to be familiar with. Its lines tell the system what programs to start in response to certain network events. Briefly, the intent of the services on each line is as follows:

Line 8—The fingerd daemon allows external users to finger a user ID and find out whether the ID exists; if it does, how recently, and on what terminals the ID has been logged in.
Line 9—The ftpd daemon provides an FTP (file transfer protocol) server.
Line 10—The login service provides service for the rlogin remote login terminal program. Don't turn this on.
Line 11—The nntp service is a Usenet newsgroups server. If your machine is configured to receive news from other servers, you can point your newsreader to your local machine to read news.
Line 12—The ntalk (new protocol talk) daemon provides for real-time chat services. If you're familiar with ICQ or IRC, this service is somewhat similar.
Line 13—Provides remote shell service—another way to remotely access machines. This service is required to use certain remote services, such as remote tape archive storage. Because Apple hasn't provided all the software necessary to make full use of these services, we suggest that this be left off as well; it's almost as large a security risk as rlogin and telnet.
Line 14—Provides the telnet daemon to allow remote telnet terminal connections. Don't turn this on.
Line 15—The uucpd service implements the Unix-to-Unix Copy Protocol. This is an antiquated method for networking Unix machines that can't always be connected to the network. Essentially, it allows network traffic between two sites to be queued until both sites are available on the network, and then exchanges the data. This service is of very limited utility today, and presents a significant security risk because it hasn't really been maintained since the days of 1200 baud modems.
Line 16—The comsat daemon provides notification of incoming mail to mail-reader clients.
Line 17—tftp is trivial file transfer protocol, and is one of the methods of providing file service to completely diskless network clients. You won't need to enable this service unless you're providing network boot services for diskless Unix clients.
Line 18—bootp is a way of transmitting network configuration information to clients. Chances are you'll use DHCP for this, if you have a need to do so, although it's possible that OS X server could use bootp for netboot clients.
Line 19—pop3 is a POPmail (Post Office Protocol Mail) server. In the file, Apple indicates that this service is not yet available.
Line 20—imap4 is an IMAP mail server. Again, this service is not available as of the 10.0.2 release.
Lines 26–33—Provide a number of network and network-software diagnostic servers. Unless you are performing network diagnosis and specifically need these, leave them off. They do not cause any known security problems, but if you're not using them, they occupy resources needlessly.
Lines 34 and 35—Provide the time service (some servers require both stream and datagram connectivity, and these must be defined on separate lines). If you want your machine to be a time server, these can be turned on.
Lines 39–42—Start a number of kerberos (security authentication) related servers, but most are unavailable from Apple as of the 10.0.2 release. The krb5_prop service (starting krpropd) is the server that propagates a master kerberos server's database to slave servers.
Line 46—The rstatd daemon allows systems to connect through the network and get machine status information.
Line 47—The rusersd daemon allows systems to connect through the network and to find information about this system's users. This is generally considered to be a bad idea.
Line 48—The walld daemon allows users to write to the screens of all users on the system. This facility is nice, if you're root and need to tell your users that the machine is going to go down for maintenance. It's annoying if one of your users starts using it to incessantly ask anyone connected to the machine for help with trivial Unix problems.
Line 49—The pcnfsd daemon provides service for a PC network file system product named pcnfs. Almost everybody uses samba instead nowadays.
Line 50—The rquotad daemon provides disk quota information to remote machines, so that they can enforce quotas that your machine specifies on disks that it is serving to them.
Line 51—sprayd is another network diagnostic server. Simply put, it responds, as rapidly as it can, to packets placed on the network by some other machine's spray process, which places packets on the network as fast as it can. This one would be nice if Apple provided it in a later release because it can be very useful for finding problem hardware in your network.
Line 56—The rexecd daemon allows for the remote execution of parts of programs. Apple claims that it isn't known to be useful, but a programmer can make very good use of this service to perform distributed processing tasks by sending parts of programs to many different machines. Of course, it is also a security risk.
Line 57—Another service that Apple considers to be of no practical use. The identd daemon provides a method for a remote machine to verify the identity of a user causing a connection, in as much as any identity can be verified over the network. The service was created because it is very easy for a user accessing, for example, a remote FTP site, to pretend to be a different user on your system, and potentially cause trouble for the person he is pretending to be.

The service this file controls, inetd, (the Internet services daemon) is a bit of a special case because it is a service that is configured by the inetd.conf file. Its function is to start other services. The configuration of inetd, and how it configures other services, will be covered in greater detail later in this chapter.

The /etc/ preference file with the next most significance to you will be the /etc/hostconfig file. This file contains a number of variable assignments that provide information to assorted programs that run on your behalf. The values in the /etc/hostconfig come partly from settings in the System Preferences panels and partly from manual modification (even though the file says that it should be touched only by the controls). The /etc/hostconfig on your machine should look similar to Listing 20.2.

Example 20.2. A Typical `/etc/hostconfig` File

1 ##
2 # /etc/hostconfig
3 ##
4 # This file is maintained by the system control panels
5 ##
6
7 # Network configuration
8 HOSTNAME=Racer-X
9 ROUTER=-AUTOMATIC-
10
11 # Services
12 AFPSERVER=-NO- 
13 APPLETALK=en1
14 AUTHSERVER=-NO-
15 AUTOCONFIG=-YES-
16 AUTODISKMOUNT=-REMOVABLE-
17 AUTOMOUNT=-YES-
18 CONFIGSERVER=-NO-
19 IPFORWARDING=-NO-
20 MAILSERVER=-NO-
21 MANAGEMENTSERVER=-NO-
 22 NETBOOTSERVER=-NO-
23 NISDOMAIN=-NO-
24 TIMESYNC=-YES-
25 QTSSERVER=-NO-
26 SSHSERVER=-NO-
27 WEBSERVER=-NO-
28 APPLETALK_HOSTNAME=Racer-X

Briefly, the lines of this listing specify the following information:

Line 8 sets the HOSTNAME variable to Racer-X. This is used in the system startup scripts to tell the machine what name it has been given in the DNS (Domain Name Service). If you will be using your machine on a network, you can't just pick this value arbitrarily; it must be assigned by your network manager. The default value is AUTOMATIC, which currently seems to automatically do nothing particularly useful. If you're not going to be using your machine on a network, feel free to place any name here that you'd like to see replace loca l host in your prompt.
Line 9 configures a variable that specifies that network routing is handled automatically. That means it is going to use the gateway or DHCP information that you've provided via the GUI Locations manager.
Line 12 indicates that the machine isn't providing AppleShare Filing Protocol services, which are necessary for serving files via AppleShare.
Line 13 indicates that the ethernet interface is en1; in this case, the AirPort card. The twisted-pair interface would usually be en0.
Line 14 specifies that the machine isn't providing authentication services.
Line 15 affects whether the undocumented server configd starts, and whether AppleTalk services should obey values coming from it.
Line 16 controls what types of media should automatically mount. Automatically mounting drives (floppies, Zip disks, CDs, and so on) is actually a big security problem for Unix-based operating systems. Allowing this makes the user's life easier, but also allows a malicious user to compromise the root account much more easily.
Line 17 controls whether the NFS Automounter will run. If you're not using NFS, it seems to make no difference. We aren't fans of NFS automounting for normal Unix installations, and aren't quite certain what to think of it on OS X. You'll learn more about NFS in Chapter 23, "File and Resource Sharing."
Line 18 controls whether this machine serves as a configuration server for other machines. This appears to be an OS X Server–specific function.
Line 19 controls IP forwarding. This is a technique by which one machine with a real network connection can make that connection available to other machines connected to it, as though they were also connected to the Internet. Configuration of this, and other network security–related options, will be covered in Chapter 31, "Server Security and Advanced Network Configuration."
Line 20 configures whether the machine functions as its own mail server. Configuration using this option will be covered in Chapter 29, "Creating a Mail Server."
Line 21 determines whether the machine functions as a management server for other machines. This is another OS X Server–specific function.
Line 22 configures whether the machine functions as a netboot server for other machines. Again, this is best left to OS X Server, which contains GUI tools for configuring this option.
Line 23 specifies which, if any, NIS domain the machine belongs to. NIS is the normal Unix way of distributing user ID and password information to multiple machines in a cluster. If you have an existing Unix installation, you can subscribe your OS X machine to the Unix machine's account information. This will be covered in Chapter 23.
Line 24 determines whether the machine should use a remote time server to synchronize its clock.
Line 25 specifies whether the machine functions as a QuickTime streaming server. This technology will be detailed in Chapter 27, "Web Serving."
Line 26 controls whether the machine provides sshd (Secure Shell daemon) services. This is a high-security network connection suite that will be covered in Chapter 26, "Remote Administration."
Line 27 controls whether the machine functions as a Web (HTTPD) server. How to enable and configure your machine as a high-power Web server will be covered in Chapter 27.
Line 28 sets the name with which the machine registers itself on the AppleTalk network. In this case, I've registered this Mac with the same name that it has on the Internet.

Other /etc/ directory preference and configuration files that you will want to be familiar with are

/etc/services— Configures the service name to port number mapping required for inetd, and some other network-based services.
/etc/printcap— Configures printing for the lpr/lpd BSD-based printing subsystem. (Setting up this printing subsystem will be given as a NetInfo example in Chapter 23, "File and Resource Sharing.")
/etc/hosts— Configures the set of other machines that this machine knows about, without having to go to the DNS server to get a hostname or IP address.
/etc/passwd— Configures user IDs, and associated home directories, passwords, and shells.
/etc/group— Configures groups and group memberships.

These files all use specific internal preferences formats that are rooted in Unix tradition and are documented in the man pages (man printcap, for example, to read about the printcap file format). In OS X, these files are directly used only in single-user mode because Apple has replaced their use with databases from NetInfo. Learning about them isn't completely irrelevant, though. It's often much easier to load the NetInfo database from these files with well-defined formats than it is to enter the data directly into NetInfo. In Chapter 23, we show how to use the traditional /etc/ configuration file formats to load data into NetInfo.

You might also want to be familiar with the formats for /etc/fstab and /etc/exports. These files traditionally control the mounting of disks and the serving of disks, respectively. Apple, however, doesn't seem to use them even in single-user mode. But the NetInfo server can load data from these file formats, so it might be useful to learn them if you will be interacting with other types of Unix machines.

Defaults Database

Preferences stored in the ~/Library/Preferences/ files are stored in XML (Extensible Markup Language), an emerging data storage standard. Readers familiar with HTML (Hypertext Markup Language) will find many similarities in the structure of HTML documents and of documents written in XML. The primary differences are that HTML is intended to be (but has wandered away from being) a structurally tagged language in a specified tag set, whereas XML is a language in which structural tagging may be arbitrarily defined.

For those unfamiliar with either language, both are essentially languages in which the content of a document is indicated by surrounding content items with tags. The beginning tag is usually of the form < TAGNAME >, where the < and > are required parts of the tag. The ending tag is of the form </ TAGNAME > where the TAGNAME part of the begin/end pair must match. Tags in both languages may be nested, but neither supports tag pairs that overlap. (That is, < TAG1 > some data < TAG2 > more data </ TAG1 > a nd more data </ TAG2 > is not acceptable.) HTML has a defined set of tags that are part of the language, but XML is actually a language in which arbitrary tags can be defined. HTML tags also imply to a browser that the data enclosed by the tags has certain intended display characteristics. XML tags, however, imply only document structure and require an additional style definition to provide display properties. Finally, through design and through degeneration by lack of standards, HTML has come to include a number of tags with purposes and syntaxes outside the logic described earlier. For example, HTML allows "half tags" for certain types of tags, as it uses some tags exclusively for display control, rather than for structural tagging. HTML's <P> (paragraph) tag, for instance, can be used alone with no closing </P> tag because it specifies only that the browser should move down and start a new line with the next text. It does not delimit the boundaries of a paragraph.

For comparison, Listing 20.3 shows a syntactically correct HTML file, and Listing 20.4 shows similar data encoded in XML.

Example 20.3. A File with Typical HTML Tagging

<HTML>
<HEAD>
    <META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=iso-8859-1">
    <TITLE>Animate! Ohio State - Not Quite All About Animate!</TITLE> 
<LINK REL="stylesheet" HREF="../animate.css" type="text/css">
</HEAD>
<BODY MARGINWIDTH="0" MARGINHEIGHT="0" LEFTMARGIN="0" TOPMARGIN="0" 
      BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#C00F00" VLINK="#C00F00"
      ALINK="#808080">
<TABLE BACKGROUND="../scarlet.gif" BORDER=0 CELLSPACING=0 CELLPADDING=0 
       WIDTH="100%">
  <TR>
    <TD ALIGN=LEFT VALIGN="TOP">&nbsp;
      <IMG SRC="../images/TopMenu/all-animate.gif" WIDTH=146 HEIGHT=30
           BORDER=0 ALT="[ All About Animate! ]" ALIGN="MIDDLE"> 
    </TD>
    <TD ALIGN=CENTER><IMG SRC="space_scarlet.gif" WIDTH=1 HEIGHT=1></TD>
    <TD ALIGN=RIGHT><A HREF="../animate.html">
      <IMG SRC="../images/TopMenu/association.gif" WIDTH=284 HEIGHT=40 
           BORDER=0 ALT="[ The Ohio State University Japanese
           Animation Association ]"></A>
    </TD>
  </TR>
</TABLE>

<TABLE WIDTH="100%" BORDER="0" CELLSPACING="0" CELLPADDING="0" 
       BACKGROUND="../grey.gif">
  <TR>
    <TD HEIGHT="25" ALIGN="LEFT" VALIGN="TOP" CLASS="date">
    <IMG SRC="../space_grey.gif" WIDTH=1 HEIGHT=1 BORDER=0> 
    <A HREF="find.html" CLASS="date">Find Animate!</A>
    |
    <A HREF="joining.html" CLASS="date">Join Animate!</A>
    |
    <A HREF=" officers.html" CLASS="date">The Officers</A>
    |
    <A HREF="helpers.html" CLASS="date">Helpers</A>
    |
    <a href="bylaws.html" CLASS="date">The Bylaws</A> 
    |
    <a href="constitution.html" CLASS="date">The Constitution</A>
    </TD>
    <TD ALIGN=CENTER><IMG SRC="space_scarlet.gif" WIDTH=1 HEIGHT=1></TD> 
    <TD VALIGN="top" ALIGN="right"><IMG SRC="../space_grey.gif" WIDTH=1
        HEIGHT=1 BORDER=0>
    </TD>
  </TR>
</TABLE>

<TABLE WIDTH="660" BORDER="0" CELLSPACING="0" ALIGN="CENTER"> 
  <TR>
    <TD ALIGN="left" VALIGN="top" COLSPAN="2"><img src="../space.gif"
        height="20" width="1"></TD>
  </TR> 
  <TR>
    <TD WIDTH="360">
    <P CLASS="header">All About Animate!
    <P CLASS="text">As this is a new year, we're busy readying the
    newest club information, so this section is still a little thin. 
    Make sure to visit the <A HREF="officers.html">Club Officers</A>
    index and meet the people who keep you in the anime pink, as it
    were,and <A HREF="find.html">how to get to them</A>. 
    <P CLASS="text">In the meantime, you can go over the
    <A HREF="constitution.html">constitution</A>
    and <A HREF="bylaws.html">club bylaws</A> to learn just how things 
    are run at Animate! Ohio State. Also check out the <A HREF="helpers.html">
    helpers</A> page and see just who else lends a hand at Animate!
    <P CLASS="text">This section will be updated as we receive and revise 
    the neccessary information. Stay tuned!
    </TD>
    <TD WIDTH="340" ALIGN="RIGHT" VALIGN="TOP">
    <P CLASS="caption">
      <IMG SRC="../images/anime/seraphim.jpg" BORDER=1 WIDTH=325 HEIGHT=249 
         ALT="[ The 266,613,336 wings of Seraphim. ]">
       The 266,613,336 wings of Seraphim.
    </TD>
  </TR>
    </TD>
  </TR>
  <TR>
    <TD COLSPAN=3> 
      <IMG SRC="../space.gif" WIDTH=1 HEIGHT=1 VSPACE=400 BORDER=0>
    </TD>
  </TR>
</TABLE>

</BODY>
</HTML>

Example 20.4. A File with Typical XML Tagging

<PAGE>
<SUMMARY>
    <ITEM>charset</ITEM>
      <VALUE>iso-8859-1</VALUE>
    <ITEM>Title</ITEM>
      <VALUE>Animate! Ohio State - Not Quite All About Animate!</VALUE> 
</SUMMARY>

<CONTENTS>
<TABLE_FORMAT_1>
  <TABLE_ROW>
    <DATA_1>
      <!ENTITY all-animate SYSTEM "../images/TopMenu/all-animate.gif"
               NDATA GIF87A> 
    </DATA_1>
    <DATA_2>
      <!ENTITY spacer SYSTEM "space_scarlet.gif" NDATA GIF87A>
    </DATA_2>
    <DATA_3>
      <LINK XML-LINK="SIMPLE" HREF=" animate.html">
        <!ENTITY "The Ohio State University Japanese Animation Association"
                 SYSTEM "../images/TopMenu/association.gif" NDATA GIF87A>
      </LINK> 
    </DATA_3>
  </TABLE_ROW>
</TABLE_FORMAT_1>

<TABLE_FORMAT_2>
  <TABLE_ROW>
    <DATA_4>
      <!ENTITY spacer2 SYSTEM "../space_grey.gif" NDATA GIF87A> 
      <LINK XML-LINK="SIMPLE" HREF="find.html">Find Animate!</LINK>
      |
      <LINK XML-LINK="SIMPLE" HREF="joining.html">Join Animate!</LINK>
       |
      <LINK XML-LINK="SIMPLE" HREF="officers.html">The Officers</LINK>
      |
      <LINK XML-LINK="SIMPLE" HREF="helpers.html">Helpers</LINK> 
      |
      <LINK XML-LINK="SIMPLE" HREF="bylaws.html">The Bylaws</LINK>
      |
      <LINK XML-LINK="SIMPLE" HREF="constitution.html">The Constitution</LINK> 
    </DATA_4>
    <DATA_5><!ENTITY spacer SYSTEM "space_scarlet.gif" NDATA GIF87A></DATA_5>
    <DATA_6><!ENTITY spacer2 SYSTEM "../space_grey.gif" NDATA GIF87A></DATA_6> 
  </TR>
</TABLE_FORMAT_2>

<TABLE_FORMAT_3>
  <TABLE_ROW>
    <DATA_7>
    <!ENTITY spacer3 SYSTEM "../space.gif" NDATA GIF87A>
    </DATA_7>
   </TABLE_ROW>

  <TABLE_ROW>
    <DATA_8>
    <HEADER_PARAGRAPH>All About Animate!</HEADER_PARAGRAPH>
    <NORMAL_PARAGRAPH>As this is a new year, we're busy readying the newest 
    club information, so this section is still a little thin. Make sure
    to visit the <LINK XML-LINK="SIMPLE" HREF="officers.html">Club Officers
    </LINK>index and meet the people who keep you in the anime pink, as it 
    were, and <LINK XML-LINK="SIMPLE" HREF="find.html">how to get to them
    </LINK>.</NORMAL_PARAGRAPH>
    <NORMAL_PARAGRAPH>In the meantime, you can go over the
     <LINK XML-LINK="SIMPLE" HREF="constitution.html">constitution</LINK>
    and <LINK XML-LINK="SIMPLE" HREF="bylaws.html">club bylaws</LINK>
    to learn just how things are run at Animate! Ohio State. Also check 
    out the <LINK XML-LINK="SIMPLE" HREF="helpers.html">helpers</LINK>
    page and see just who else lends a hand at Animate!</NORMAL_PARAGRAPH>
    <NORMAL_PARAGRAPH>This section will be updated as we receive and revise 
    the neccessary information. Stay tuned!</NORMAL_PARAGRAPH>
    </DATA_8>
    <DATA_9>
    <CAPTION_PARAGRAPH>
      <!ENTITY "The 266,613,336 wings of Seraphim" SYSTEM 
               "../images/anime/seraphim.jpg" NDATA GIF87A>
      The 266,613,336 wings of Seraphim.
    </CAPTION_PARAGRAPH>
    </DATA_9>
  </TABLE_ROW>

  <TABLE_ROW> 
    <WIDE_DATA>
      <!ENTITY spacer3 "../space.gif" NDATA GIF87A>
    </WIDE_DATA>
  </TABLE_ROW>
</TABLE_FORMAT_3>

</CONTENTS>
</PAGE>

The HTML file will render in a Web browser similar to what is shown in Figure 20.1. The XML file actually has no visual representation because XML is a structural definition, and requires an auxiliary style definition to indicate the appropriate visual representation. The auxiliary style definition provides all the style mappings so that tags that have explicit styles in the HTML file (such as <TD> elements) with assigned widths, and so on, can be given display style directions. This is why the XML representation has many different <DATA_*> tags, instead of a single <TD> type tag with parameters. The appropriate display options characteristics for each <DATA_*> type are defined in the external style file. We won't provide the style file here because learning its syntax won't help you with Apple's preferences. Still, for this example, you can probably imagine reasonable visual intentions from the tag names and a comparison with the HTML file.

Figure 20.1 A Web browser renders the HTML shown in Listing 20.3 like this. The XML shown in Listing 20.4 could render like this as well, but it also could render in any number of other manners as well.

The observant reader will note that the similarities are significant, but that where HTML allows implicitly closed tags for items such as <P> (paragraph), XML requires explicitly closed tags. For completely nonenclosing tags, such as HTML's <HR> tag (horizontal line), XML substitutes a tag type that is understood to open and close itself in the statement. The XML equivalent would look like <HR/>, which is read by the parser as <HR></HR>. Apple uses this type of tagging frequently in its XML preferences files. Listing 20.5 shows the Terminal.app preference file (located in ~/Library/Preferences/com.apple.terminal.plist) from an installed, but little-used user account.

Example 20.5. An Almost Bare Preference File for `Terminal.app`

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd ">
<plist version="0.9">
<dict>
        <key>WinLocULY</key>
        <integer>-53</integer>
        <key>WinLocX</key>
        <integer>23</integer> 
        <key>WinLocY</key>
        <integer>827</integer>
</dict>
</plist>

The terminal preferences currently contain little of interest other than some variables that control the location of the window. If the file were to be opened in a text editor and the values changed, the location on the screen where the Terminal opens would be changed.

Listing 20.6 shows the Terminal.app preferences from a considerably more used account. As you can see, the plist files are not required to contain all the preferences for an application, and can grow as the user specifies more preferences that aren't just the defaults. One annoyance that this causes is that sometimes hidden preferences aren't accessible through any of the application's preferences panes. These preferences can find their way into the XML plist files only if somebody discovers their existence and adds the preference line to the plist file manually. The terminal opacity setting that will be discussed shortly is exactly this sort of discovered preference.

Tip

If you'd like to search for this type of hidden preference for yourself, you might want to check out the strings command. If you run the strings command on /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal ( strings Applic a tions/Utilities/Terminal.app/Contents/MacOS | more might be a reasonable attempt), you'll see a list of all textual strings in the program. It's reasonable to expect that for the program to read strings out of a .plist file, it must contain the string, so the strings found in the program make for potentially interesting things to try as preferences.

Example 20.6. A Preferences File for `Terminal.app` That Has Accumulated Some Settings over Time

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd ">
<plist version="0.9">
<dict>
    <key>AlwaysPromptOnQuit</key>
    <integer>1</integer>
    <key>AppleSavePanelExpanded</key>
    <string>YES</string> 
    <key>AutoFocus</key>
    <true/>
    <key>Autowrap</key>
    <true/>
    <key>BlinkCursor</key>
    <true/>
    <key>CleanCommands</key> 
    <string>rlogin;telnet;ssh;slogin</string>
    <key>Columns</key>
    <integer>132</integer>
    <key>CursorShape</key>
    <integer>0</integer> 
    <key>CustomTitle</key>
    <string>Wowzers! </string>
    <key>DisableAnsiColors</key>
    <false/>
    <key>DockLaunchHide</key>
    <false/> 
    <key>DoubleBold</key>
    <true/>
    <key>Keypad</key>
    <true/>
    <key>LastCommand</key>
    <string>emacs</string>
    <key>Meta</key> 
    <integer>-1</integer>
    <key>MonitorProcs</key>
    <true/>
    <key>NSColorPanelMode</key>
    <string>6</string>
    <key>NSDefaultOpenDirectory</key> 
    <string>~/Documents</string>
    <key>NSFixedPitchFont</key>
    <string>Monaco</string>
    <key>NSFixedPitchFontSize</key>
    <integer>10</integer> 
    <key>NSPreferencesContentSize</key>
    <string>{ 460, 470} </string>
    <key>NSPreferencesSelectedIndex</key>
    <integer>3</integer>
    <key>NSWindow Frame NSColorPanel</key> 
    <string>3 379 205 367 0 55 1024 691 </string>
    <key>NSWindow Frame TermInspector</key>
    <string>454 200 268 387 0 4 1024 742 </string>
    <key>Rows</key> 
    <integer>35</integer>
    <key>RunningBackgroundClean</key>
    <false/>
    <key>SaveLines</key>
    <integer>10000</integer>
    <key>Scrollback</key> 
    <true/>
    <key>Shell</key>
    <string>/bin/tcsh</string>
    <key>ShellExitAction</key>
    <integer>2</integer>
    <key>SourceDotLogin</key> 
    <true/>
    <key>StartupAction</key>
    <integer>1</integer>
    <key>StartupFile</key>
    <string></string>
    <key>StrictEmulation</key> 
    <true/>
    <key>TextColors</key>
    <string>0.000 0.000 0.000 1.000 1.000 1.000 0.000 0.000 0.000 0.333 0.333
              0.333 1.000 1.000 1.000 0.333 0.333 0.333 1.000 0.988  0.033 0.333
              0.333 0.333 </string>
    <key>TitleBits</key>
    <integer>1</integer>
    <key>Translate</key>
    <true/>
    <key>WinLocULY</key> 
    <integer>19</integer>
    <key>WinLocX</key>
    <integer>42</integer>
    <key>WinLocY</key>
    <integer>723</integer>
</dict>
 </plist>

Instead of requiring you to edit XML files directly, Apple has provided a convenient command-line program for editing the preferences stored in these files. The defaults command allows you to specify a preference to be modified and a value with which to modify it. As an example of the defaults command in use, the following command modifies the transparency of the Te r minal.app windows to produce those wonderful semi-opaque terminals you undoubtedly have seen in OS X screenshots on the Web:

defaults write com.apple.terminal TerminalOpaqueness 0.5

Specifically, this command modifies the value of the preference TerminalOpaqueness in the file ~/Library/Preferences/com.apple.terminal.plist, and sets the value to 0.5 (or 50% opacity). If you were to run this command on the account with the Te r minal.app preferences shown in Listing 20.5, the ~/Library/Preferences/com.apple.terminal.plist would change to that shown in Listing 20.7.

Example 20.7. A `Terminal.app` Preferences File After Forcing a New Value into It (`TerminalOpaqueness`) with the `defaults` Command

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd ">
<plist version="0.9">
<dict>
        <key>TerminalOpaqueness</key>
        <string>0.5</string>
        <key>WinLocULY</key>
        <integer>-53</integer> 
        <key>WinLocX</key>
        <integer>23</integer>
        <key>WinLocY</key>
        <integer>827</integer>
</dict>
</plist>

As you can see in Listings 20.6 and 20.8, the items stored in the ~/Library/Preferences/ files are many and varied. You also can see that some preferences are not intuitively parseable.

Example 20.8. The `plist` File for `GraphicConverter`

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd ">
<plist version="0.9">
<dict>
    <key>AppleNavServices:GetFile:0:Path</key>
    <string>file://localhost/Users/ray/Documents/ </string>
    <key>AppleNavServices:GetFile:0:Position</key>
    <data>
    ALwA+A==
    </data>
    <key>AppleNavServices:GetFile:0:Size</key>
    <data> 
    AAAAAAG0AhA=
    </data>
    <key>AppleNavServices:PutFile:0:Disclosure</key>
    <data>
    AQ==
    </data>
    <key>AppleNavServices:PutFile:0:Path</key> 
    <string>file://localhost/Users/ray/Documents/</string>
    <key>AppleNavServices:PutFile:0:Position</key>
    <data>
    AQcA+A== 
    </data>
    <key>AppleNavServices:PutFile:0:Size</key>
    <data>
    AAAAAAEdAhA=
    </data>
</dict>
</plist>

Unfortunately, Apple hasn't provided a definitive list of preference options for each application. Even a listing of the options that each file contains would not be complete because some applications accept preferences that are not yet stored in the XML files. There are preference options that some programs take as defaults, but that can be overridden by the insertion of specific preferences into the XML files. Because no current preference is stored, we can only make intelligent guesses as to what preference names and values might be accepted. The command for controlling the Terminal.app opacity is the result of such a serendipitous preference discovery. As a matter of fact, making intelligent guesses is exactly what the online community is doing regarding these preferences, and a number of interesting options have been discovered. Table 20.1 lists a number of preferences options that have been reported to be interesting, when configured using the defaults command. Not all these have known or well-documented functions.

Table 20.1. A Number of the Interesting `defaults` Preferences Options That Have Been Reported as Having Interesting Effects on the Interface

Issuing `defaults` `write` this domain	and this key	and one these values	affects this feature of the of interface
`com.apple.finder`	Desktop.HasLocal Volumes	1 0	Display drives on the desktop
	`Desktop.HasTrash`	1 0	Put the trash back on the desktop (where some say it belongs)
	`ZoomRects -bool`	yes no	Zoom or don't zoom Finder windows
	DesktopViewOptions -dict ArrangeBy	dnam size kind	Arrange icons by name, size, or kind
	`Desktop.HasDarkDesktop`	`0`	`1`
	Desktop.HasRemovable Media	1 0	Removable media does or does not appear on the desktop
	OpenWindowForNew RemovableDisk	1 0	Mounting removable media does or does not open a new window
	`CreateDesktop`	`0`	Don't show a desktop picture
	`AppleShowAllFiles`	`True`	Show even files that are normally hidden
com.apple. terminal	`TerminalOpaqueness`	`0.0 to 1.0`	Change the opacity of the Terminal window
`NSGlobalDomain`	`NSInterfaceStyle`	nextstepdefaults macintoshdefaults windowsdefaults
	Desktop.HasDark Background	1 0
	`NSFixedPitchFontSize`	`<` `fontsize` `>`
	`NSFontSize`	`<` `fontsize` `>`
	`NSSystemFontSize`	`<` `fontsize` `>`
`com.apple.dock`	`showhidden -boolean`	Yes no
	`showforeground -boolean`	`yes`
		`no`
	`showforeground`	`1`	Colors the triangle indicating a running application in the Dock blue
	`showhidden`	`1`	Dims the Dock icons for hidden applications
	`mineffect`	genie scale suck	Known values for different minimize into Dock effects
	`showshadow`	1 0	Dock shadows back ground
<any application domain>	`NSUserKeyEquivalents`	'{ "<menuitem>" ="<keystring>";}'	`<menuitem>` is any named menu item in a Cocoa application
			`<keystring>` is built from @ = Command $ = Shift ~ = Option ^ = Control and any character
			Modifies the key equivalent for a menu item

Table 20.2 shows the command documentation table for the defaults command.

Table 20.2. Command Documentation Table for the `defaults` Command

`defaults`	Accesses the Mac OS X user defaults system
defaults read [ <domain name> [ <key> ] ] defaults write <domain name> [ { '<domain rep>' \| <domain name> <key> '<value rep>'} defaults delete [ <domain name> [ <key> ] ] defaults {domains \| find <word> \| help }
`defaults` allows users to read, write, and delete Mac OS X user defaults from the command line. Applications use the defaults system to record user preferences and other information that must be maintained when applications aren't running, such as the default font for new documents. Because applications do access the defaults system while they are running, you should not modify the defaults of a running application.
User defaults belong to domains, which typically correspond to individual applications. Each domain has a dictionary of keys and values to represent its defaults. Keys are always strings, but values can be complex data structures comprised of arrays, dictionaries, strings, and binary data.
Although all applications, system services, and other programs have their own domains, they also share a domain called `NSGlobalDomain`. If a default is not specified in the application's domain, it uses the default listed in the `NSGlobalDomain` instead.
`read`	Prints all of the user's defaults for every domain to standard output.
`read` `<domain name>`	Prints all of the user's defaults for the specified `<domain name>` to standard output.
read <domain name> <key>.	Prints the value for the default of the `<domain name>` identified by `<key>`
write <domain name> <key> '<value rep>'	Writes `<value rep>` as the value for `<key>` in `<domain name>` . `<value rep>` must be a property list, and must be enclosed in single quotes. For example: defaults write MyApplication "Default Color" '(255, 0, 0)' sets the default color in `MyApplication` to the array containing 255, 0, 0 (red, green, blue components). Note that the key is in quotes because of the space in its name.
write <domain name> '<domain rep>'	Overwrites the defaults information in `<domain name>` with that specified in `<domain rep>` `.` `<domain rep>` must be a property list representation of a dictionary, and must be enclosed in single quotes. For example, defaults write MyApplication '[ "Default Color" = (255, 0, 0); "Default Font" = Helvetica; } ' overwrites any previous defaults for `MyApplication` and replaces them with the ones specified.
`delete` `<domain name>`	Deletes all default information for `<domain name>` .
delete <domain name> <key>	Deletes the default named `<key>` in `<domain name>` `.`
`domains`	Prints the names of all domains in the user's defaults system.
`find` `<word>`	Searches for `<word>` in the domain names, keys, and values of the user's defaults, and prints out a list of matches.
`help`	Prints a list of possible command formats.

System Services | Next Section Previous Section

Mac管理员学习小组

Sunday, May 6, 2007