What You Can Do with Mac OS X and Unix

What You Can Do with Mac OS X and Unix

What do you want to do? Do you want to create movies with iMovie and make them available over the Internet? With the Unix-based Mac OS X, that task is easy: You simply drag the movies into the Sites folder in your home directory, then enable Web sharing. Are you a programmer who works on Unix systems? With Mac OS X you can install the same software on your desktop (or laptop) Mac that you use on your Unix servers you develop for, enabling you to have a complete development and test environment on your own machine. Would you like to run your own radio station? You can easily use your Mac OS X machine to run the Darwin Streaming Server, which provides powerful streaming-audio capabilities. Do you want your schedule to be constantly available to friends and family, your r sum always accessible to potential employers ? You can provide all those things with greater reliability on a Unix platform.

Beyond the foundation of increased stability, flexibility, and openness, Unix brings a number of more specific features to Mac OS X that are fundamental to the way you will use it. Key among these is the way it supports multiple users and multiple processes.

Accommodating multiple users

As we've said earlier, Unix is a multiuser environment and intentionally keeps each user 's actions separate to create a more stable environment.

On a Unix system you are never alone (unless you started the machine in single-user mode, which we'll discuss in Chapter 11, "Introduction to System Administration"; if you already know what that means, keep quiet until the others have a chance to catch up). Unix assumes there are going to be many users running programs on the system.

When you log in to a Unix system, you identify yourself with a user name and password that have already been entered into the system by an administrator (if you are working on your own Mac OS X system, you will have created at least one account for yourself when you installed the operating system). This enables the operating system to keep your files and actions separate from everyone else's and is a major factor in Unix stability and security.

Tip

  • You can see a list of who is logged in to your system using the command-line w and who commands. See Chapter 11 for more information on using the w and who commands.


All the files you create in the normal course of using the system are "owned" by you. Every file and every running program (known as a process ) on a Unix system is owned by a user. All the important system filesthat is, the ones that make up the actual operating systemare owned by a special super user called root . The root account is all-powerful, and you must exercise great care when using it (see Chapter 11 for more on root).

Not every user account on the system is intended for use by a human. Unix systems, including Mac OS X, come with a number of special user accounts with names like "nobody" and "daemon." The system uses these accounts to own processes that should not have the power of the root account.

Each regular user account on a Unix system has its own area in the file system called its home directory . This is where all the files a given user creates and owns are normally stored. Unix keeps track of who owns each file and allows (or disallows) various operations based on the ownership of files.

Preemptive multitasking

On Unix systems, you might have not only multiple programs running, but also multiple copies of the same program running. Even with just a single person logged in, running a few applications, several dozen processes will be running at any given moment, each with its own separate memory allocation. In fact, the operating system keeps a number of different processes running even if you are not doing anything.

When the machine starts up, the initial process (called init ), which is owned by the super-user root, begins. The init process then starts many other processes, which are also owned by root.

Tip

  • You can see a list of all the processes on your system using the ps and top commands. See Chapter 11 for more information on monitoring system usage.


Parents and children

Every process in Unix is the child of some other process, except for that first process, init, which is the mother of all processes. This concept of processes' having parents and children comes up frequently in Unix.

When you log in to a Unix system, you start a process that you alone own. The exact process depends on which Unix system you are using, and how you log in to it. This process will be the parent (or grandparent, or great-grandparent) of every process you start on the system after logging in.

When you log in using the Mac OS X graphical user interface, you start a process called WindowServer, which you own.

Every program you run will have the WindowServer process as an ancestor . In other words, if you start up an application such as BBEdit, a popular text editor, then BBEdit's parent process will be WindowServer. If you start up the command-line interface (the Terminal application), you might then start more programs using the Terminal application. Those programs will have Terminal as their parent, and WindowServer as their grandparent, and so on.

So, even if you are the only person using your Mac, you might have several dozen processes running. In addition to a process for the programs you are running, there will always be dozens of other processessome owned by the root account and some owned by other system accounts.

Applications vs. Programs vs. Commands

All applications are programsthe terms are synonymous. In this book we use the term application to refer to complex programs used for a variety of related tasksfor example, Adobe Photoshop is an application for graphics manipulation. In Unix you often see the term command , which can refer either to an application that handles some specific task (such as copying files) or to a built-in feature of a larger program or application. For example, the command for copying files is the cp command, which is in fact a small program. The command to move from one folder into another folder ( directory , in Unix terms) is the cd command, which is actually part of a larger program called the shell . See Chapter 5, "Using Files and Directories," for more on the cp and cd commands.


Files and the filesystem

Unix brought a number of changes to the Mac OS with regard to files and the filesystem (see the sidebar "What Is a Filesystem?" for its definition).

From the user's point of view, the most prominent changes (as compared with Mac OS 9) involve the handling of file security, the storage of files, and the use of a different syntax for describing a file's location.

Files and security

On an old Mac OS system, you could alter or delete any file. You could put files from the System Folder in the Trash and cause all kinds of trouble, even accidentally . On a Unix system, every file is owned by some user. The operating system restricts the ability to create, change, or delete files based on ownership of the file/folder and the permissions applied to it. So, one user cannot alter or delete files created by another user, and you are unlikely to cause any serious damage to the operating system (the exception: the root user can do anything).

Folders are called directories

What Mac users call a folder Unix users call a directory . A directory that is inside another is called a subdirectory. It is important to know which directory you are "in," because when you're working from a command line, there is no visual cue, such as an active window. Know the concept of the "current directory" in Unixthat's where you're currently working.

File paths use / instead of :

In Mac OS 9 and earlier, file- path designations use colons. (By file-path designations we mean how you would spell outin writingthe location of a file showing all the enclosing folders.) In Mac OS X, Unix uses the / (slash) instead of the : ( colon ) to separate the parts of a file path. In Mac OS 9, then, the path of the FileMaker Pro application would look like that in Figure 1.2 .

Figure 1.2. This is how the path of the FileMaker Pro application would look on the Mac OS 9 file system.
 MyBig Disk:Applications (Mac OS 9):FileMaker Pro 5 Folder:FileMaker Pro 

In Mac OS X, the same path would appear as shown in Figure 1.3 .

Figure 1.3. This is how the path of the FileMaker Pro application looks on the Mac OS X filesystem.
 /Applications (Mac OS 9)/FileMaker Pro 5 Folder/FileMaker Pro 

Notice that the name of the hard drive doesn't show up anymore. In Unix, drives don't have names. The Mac OS X Aqua interface does have names for drives, and they do appear in the Finder, thanks to some tricks of the Mac OS X Finder. But at the underlying Unix/Darwin level, even in Mac OS X, drives don't have names. (They do have device names , which look like /dev/disk0s3 . For more on the Unix way of looking at the your disk[s], check out "Seeing the Whole File System" and especially Figure 5.1 in Chapter 5.)

Unix presents all the available hard disks as a single hierarchy of directories and files. There are ways to see which disks contain which files, but usually, when dealing with files in Unix, you pay attention to only the full pathname of the file. See Chapter 5 for more about using pathnames.

Even with the differences cited above, the Unix filesystem is organized similarly to what you are used to on a Mac.

If you use / instead of : in your pathnames, and think of as your startup disk as being named / in Unix, you're getting closer to understanding the way Unix thinks of files, directories, and subdirectories.

What Is a Filesystem?

In Unix, the terms filesystems and file sysem are often used interchangeably. Furthermore, the term filesystem is used in two different ways. The first way is more informal and refers to the complete hierarchy of directories. The second way refers to a single storage area that has been formatted for use by the operating system. The "single storage area" is often, but not always, a single disk partition. Filesystems contain directories and files but never other filesystems.

Example of the first form: "/ is the root directory of the filesystem."

Example of the second form: "It is common to have two or more filesystems on the same physical disk."


Get used to filename extensions

Another difference between Mac OS 9 and Mac OS X is in Mac OS X's use of filename extensionsyou know, those things at the end of all the filenames on the Web and on PCs, such as .html, .txt, and .jpg.

From the very start, the Mac OS has cleverly kept track of a file's characteristics: what type of file it is; what application opens it; if the file is being used by another application; if the file is locked. Unix doesn't store as much information about each file along with each file. In particular, Unix has no fundamental concept of a file's "type" or "creator" (Mac OS X does, but only for files that were created with Mac file information).

Unix's filename extensions indicate a file's type. This is not as powerful as the Macintosh approach, but it is the standard in the Unix world. (This is no surprise, given which operating system the original Web servers used and the one most Web servers still use today.) Mac OS X tries to have it both ways and, in the Mac spirit, uses the old Mac approach in some cases and the standard Unix approach in other cases. But in order to play well with others, Mac OS X incorporates filename extensions. You can decide whether to display them in the graphical interface, but when you use the command line they will always be there.

Files created by Macintosh applications will have the Macintosh creator and type attributes, but files created by non-Mac applications, including all non-Mac Unix applications, will have only the filename extension (if any) to indicate what kind of file they are.



Unix for Mac OS X 10. 4 Tiger. Visual QuickPro Guide
Unix for Mac OS X 10.4 Tiger: Visual QuickPro Guide (2nd Edition)
ISBN: 0321246683
EAN: 2147483647
Year: 2004
Pages: 161
Authors: Matisse Enzer

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net