Mac OS X Unleashed

By John Ray and William C. Ray

• Table of Contents
  • Copyright
  • About the Author
  • Acknowledgments
  • Tell Us What You Think!
  • Introduction
  • Part I: Introduction to Mac OS X
  • Chapter 1. Mac OS X Component Architecture
  • Chapter 2. Installing Mac OS X
  • Chapter 3. Mac OS X Basics
  • Chapter 4. The Finder: Working with Files and Applications
  • Chapter 5. Running Classic Mac OS Applications
  • Part II: Inside Mac OS X
  • Chapter 6. Native Utilities and Applications
  • Chapter 7. Internet Communications
  • Chapter 8. Installing Third-Party Applications
  • Part III: User-Level OS X Configuration
  • Chapter 9. Network Setup
  • Chapter 10. Printer and Font Management
  • Chapter 11. Additional System Components
  • Part IV: Introduction to BSD Applications
  • Chapter 12. Introducing the BSD Subsystem
  • Chapter 13. Common Unix Shell Commands: File Operations
    • Rearranging Files
    • Examining File Contents
    • Deleting Files
    • Searching for Files, Directories, and More
    • File Compression and Archiving
    • Summary
  • Part V: Advanced Command-Line Concepts
  • Chapter 14. Advanced Shell Concepts and Commands
  • Chapter 15. Command-Line Applications and Application Suites
  • Chapter 16. Command-Line Software Installation
  • Chapter 17. Troubleshooting Software Installs, and Compiling and Debugging Manually
  • Chapter 18. Advanced Unix Shell Use: Configuration and Programming (Shell Scripting)
  • Part VI: Server/Network Administration
  • Chapter 19. X Window System Applications
  • Chapter 20. Command-Line Configuration and Administration
  • Chapter 21. AppleScript
  • Chapter 22. Perl Scripting and SQL Connectivity
  • Chapter 23. File and Resource Sharing with NetInfo
  • Chapter 24. User Management and Machine Clustering
  • Chapter 25. FTP Serving
  • Chapter 26. Remote Access and Administration
  • Chapter 27. Web Serving
  • Part VII: Server Health
  • Chapter 28. Web Programming
  • Chapter 29. Creating a Mail Server
  • Chapter 30. Accessing and Serving a Windows Network
  • Chapter 31. Server Security and Advanced Network Configuration
  • Chapter 32. System Maintenance
  • Appendix A. Command-Line Reference
  • Appendix B. Administration Reference

Rearranging Files

If you're a long-time Macintosh user, you are probably familiar with the notion of moving files about by way of the Macintosh's drag-and-drop formalism. Unix and its command line might not seem like a particularly appealing way to deal with moving files—having to type the names and paths to directories can't possibly be much fun! There's no way to deny that there are certain tasks for which the drag-and-drop way works much better than the command line. But, although you might not have thought about it, there are also situations in which drag-and-drop makes your life much more difficult. Interestingly, these are frequently situations in which the command line works particularly well; for example, when a folder contains a great number of files of the same type and you're interested in using a number of them that are related by name rather than by icon position. In a situation like this, rearranging things in the Finder, or Shift- clicking your way through the list of files to pick the ones you want, is usually less efficient than choosing them from the command line by using a shell filename wildcard. Similarly, it's frequently faster to type a filename, if you know it, than to scroll around in a Finder window looking for the file. For these reasons, as well as conveniences that really become apparent only from experience rather than explanation, the command line makes for a useful complement to the Finder for certain operations.

Renaming Files: mv

Renaming files in Unix is accomplished with the mv (move) command. It might seem odd at first that renaming a file is accomplished by moving it, but it makes sense in the Unix sense of accomplishing things in simple, abstract ways. Why create two commands that do essentially the same thing, when one command can do both with the same syntax, the same way. To rename a file from one name to another, simply use mv <oldfilename> <newfilename> . For example, if you're in a directory with a file named mynewfile, and you'd like to rename it as myoldfile, you might do something like this:

[localhost:~/Documents] nermal% ls

     lynx       lynx.cfg   mynewfile  test

[localhost:~/Documents] nermal% mv mynewfile myoldfile

[localhost:~/Documents] nermal% ls

     lynx       lynx.cfg   myoldfile  test

Remember that most commands can take absolute paths or relative paths to files? Well, being in the same directory and using just the filenames is using the relative paths. On the other hand, you can accomplish the same thing using the absolute paths to the files like this:

[localhost:~/Documents] nermal% ls

     lynx       lynx.cfg   mynewfile  test

[localhost:~/Documents] nermal% pwd

     /Users/nermal/Documents
[localhost:~/Documents] nermal% mv /Users/nermal/Documents/mynewfile /Users/nermal

      
   /Documents/myoldfile
[localhost:~/Documents] nermal% ls

     lynx       lynx.cfg   myoldfile  test

Because you can do that, why should you need to be in the same directory as the files at all? As a matter of fact, because you can specify the full paths to the files, what is to stop you from changing something other than the filename when you use the mv command? What if you decide to change one of the directories in the full path while you're at it? For example, let's look at what happens if you move a file from the Documents directory at the same time that you change its name:

[localhost:~/Documents] nermal% cd ~
[localhost:~] nermal% ls

     Desktop                   Network Trash Folder      chown-output
     Documents                 Pictures                  myfile
     Library                   Public                    output-sample6
     Movies                    Sites                     su-output
     Music                     TheVolumeSettingsFolder   typescripts

[localhost:~] nermal% ls Documents

     lynx       lynx.cfg   mynewfile  test
[localhost:~] nermal% mv /Users/nermal/Documents/mynewfile /Users/nermal/Public/myoldfile
[localhost:~] nermal% ls Documents/

     lynx     lynx.cfg test

[localhost:~] nermal% ls Public/

     Drop Box   myoldfile

The end result is that Unix's abstraction of file access and naming causes the full path to the file to be, essentially, the full proper name of the file. "Renaming" it using the mv command can result in a change to any part of that name, including the parts that indicate the directory in which the file exists. See? Nothing odd about using the same syntax to rename files as used to move them about at all.

The command documentation table for mv is shown in Table 13.1.

Table 13.1. The Command Documentation Table for mv

mv [-fi] <source> <target>

mv [-fi] <source1> <source2> <source3> ... <directory>

            

Creating Directories: mkdir

The mkdir command is used to create directories. The usual syntax is very simple, being most commonly used as

mkdir <new directory name>

This will create a new directory named <new directory name> in the current directory. Full and relative paths are allowed to the new directory being specified. If the path to the directory that you are attempting to create does not completely exist, mkdir will not create the entire directory structure. For example, if you want to create /usr/local/tmp/testing/morefiles/, and the directory /usr/local/tmp/testing/ does not exist, you will have to create it before you can create /usr/local/tmp/ testing/morefiles/. This holds for all levels in the directory hierarchy. The command reference is shown in Table 13.2.

Table 13.2. The Command Documentation Table for mkdir

mkdir [-p] [-m <mode>] <dir1><dir2> ...

Copying Files: cp

The cp (copy) command functions in a similar fashion to the mv command, but instead of renaming a file between two locations, the cp command creates a duplicate of the file. The syntax is also similar, copying a file from one location to another or copying a number of files into a directory.

If our user nermal would like to copy some images to the /Users/shared directory so that all users can conveniently find the images without having to remember which user has the images, she can copy them with the cp command to the desired location.

Because nermal is new to Unix, she first decides to double-check that the images are located where she thinks they ought to be with the following:

[localhost:~] nermal% ls -l Public/Drop\ Box/shar*tiff

     -rw-r--r--  1 nermal  staff  872714 Apr 16 16:17 Public/Drop Box/sharing -1.tiff
     -rw-r--r--  1 nermal  staff  873174 Apr 16 16:17 Public/Drop Box/sharing -2.tiff

Then she actually copies them and verifies that they copied:

[localhost:~] nermal% cp Public/Drop\ Box/shar*tiff /Users/shared/

[localhost:~] nermal% ls -l /Users/shared

     total 3424
     -rw-r--r--  1 nermal  wheel  872714 Apr 23 11:08 sharing-1.tiff
     -rw-r--r--  1 nermal  wheel  873174 Apr 23 11:08 sharing-2.tiff

She could have copied each file individually, but cp can fortunately take multiple files in its arguments, so she can use shar*tiff to refer to both files. Note that the copies in the /Users/shared directory show the date that they were copied, rather than the original date. If everyone knows that the images from April 16 are the ones they need to use, they might be confused by the April 23 date. nermal could remove this confusion by specifying the -p option, which preserves as much as possible of the original modification time, user information, and so on:

[localhost:~] nermal% cp -p Public/Drop\ Box/shar*tiff /Users/shared/

[localhost:~] nermal% ls -l /Users/shared

     total 3424
     -rw-r--r--  1 nermal  staff  872714 Apr 16 16:17 sharing-1.tiff
     -rw-r--r--  1 nermal  staff  873174 Apr 16 16:17 sharing-2.tiff

Note the use of the \ character to escape the space in the folder named Drop Box so that the shell doesn't interpret Public/Drop as one argument and Box/shar*.tiff as another.

If user joray has promised nermal some test data in a subdirectory named tests-for-nermal in joray's home directory, nermal can recursively copy the test directory to her own home directory as follows:

[localhost:~] nermal% cp -R ~joray/tests-for-nermal ./

A check shows that a directory was indeed copied:

[localhost:~] nermal% ls -ld tests-for-nermal

     drwxr-xr-x  9 nermal  staff  262 Apr 23 11:29 tests-for-nermal

Not only that, but there was a directory under that directory, and cp copied it:

[localhost:~] nermal% ls -l tests-for-nermal

     total 48
     -rw-r--r--  1 nermal  staff   15 Apr 23 11:29 broken
     -rw-r--r--  1 nermal  staff   20 Apr 23 11:29 broken-again
     -rw-r--r--  1 nermal  staff   23 Apr 23 11:29 fix
     -rw-r--r--  1 nermal  staff   17 Apr 23 11:29 fix2
     -rw-r--r--  1 nermal  staff  848 Apr 23 11:29 test
     drwxr-xr-x  4 nermal  staff   92 Apr 23 11:29 test-data
     -rw-r--r--  1 nermal  staff  848 Apr 23 11:29 test2

You have seen just some of what you can do with cp. The complete syntax and options for cp are in Table 13.3, the command documentation table.

Table 13.3. The Command Documentation Table for cp

cp [-R (-H | -L | -P)] [-f | -i] [-p] <source>

                     
                   <target>

cp [-R (-H | -L | -P)] [-f | -i] [-p] <source1>

                     
                   <source2> ...

<directory>

            

Creating Symbolic Links: ln

Sometimes it is useful to be able to link a name with a particular file or directory. This can be done with the ln command. It is especially useful for administrative purposes, but even a regular user might have the need to link a filename or directory name to some other particular name. The best way to do this is to use a symbolic link. The simplest syntax for making a symbolic link is

ln -s <source> 
   <target>

Because the syntax is similar to the basic cp syntax, you won't have much trouble remembering it.

You might be wondering just what sort of use you might have for symbolic links. An instance in which you might use a symbolic link is for your Web site. Suppose that you are using a Web editing suite that uses home.html for the default name for the main page of your Web site. Suppose, however, that your Web server is set to read only files named index.html as the default page for a directory. If you use home.html, you might have to give out something like http://ryoohki.biosci.ohio-state.edu/~nermal/home.html as your URL. If, on the other hand, your home.html file were really called index.html, you could give out a slightly shorter URL instead: http://ryoohki.biosci.ohio-state.edu/~nermal/.

What could you do to get an index.html file in your directory if your Web editing suite won't create one? And how could you keep it conveniently updated to match home.html? Well, as you just saw, you could copy home.html to index.html. But the next time you edited home.html, you would then have to remember to copy home.html to index.html when you were done. Although you might be very good about remembering to do that, you undoubtedly will eventually forget, probably when it matters most. If you simply link index.html to home.html, every time you update home.html, you don't have to remember to do anything else! To create the symbolic link, do the following:

[localhost:~/public_html] nermal% ln -s home.html index.html

A quick check shows us that index.html is now a link to home.html.

[localhost:~/public_html] nermal% ls -l

     total 16
     -rw-r--r--  1 nermal  staff  52 Apr 23 11:56 home.html
     lrwxr-xr-x  1 nermal  staff   9 Apr 23 11:56 index.html -> home.html

A common administrative use for symbolic links is to move a directory from one partition to another, while leaving the path that a user would use to get to the directory the same. This makes the change that the administrator has made transparent to the user for most purposes. An example of this follows. On this machine, /usr partition was getting full, so the local directory of /usr/local was moved to the /home partition. After the directory was moved, the /usr/local directory was replaced with a symbolic link that points to /home/local.

Rosalyn joray 201 > ls -l /usr/local

     lrwxrwxrwx   1 root     other    11 Mar 20  1997 /usr/local -> /home/local

If a user changes to the /usr/local directory and then checks her location with pwd, she finds the following:

Rosalyn joray 202 > cd /usr/local

Rosalyn local 203 > pwd

     /home/local

So, as the user might have grown to expect, she can still cd to /usr/local, but without having to know any of the "administrivia" behind its actual location.

The complete syntax and options for ln are in Table 13.4, the command documentation table.

Table 13.4. The Command Documentation Table for ln

ln [-fhns] <source> <target>

ln [-fhns] <source1> <source2> <source3> ...
<directory>

            

Changing Modification Times, Creating Empty Files: touch

The touch command is used to update the last-modified time for a file. This command also has the side effect of creating a new, empty file, if the file that you attempt to touch does not exist.

Neither of these functionalities probably sounds particularly interesting at the outset, but, in fact, they both have good uses. For example, most archiving and backup software is frequently configured to back up only files that have changed since the last backup. Using touch on a file makes it appear to have been changed, which results in it being flagged for backup. Because the touch command can be quickly applied from the command line to a large number of files, it allows you to conveniently force some files to be backed up without having to open and resave each in its parent applications.

Creating empty files doesn't have much use at the command line, but turns out to be a very useful thing to be able to do when you start writing programs in the shell scripting language (Chapter 18 "Programming with the Shell: Shell Scripting"). In this case, multiple simultaneously running scripts can be made to talk to each other by the creation of empty files known as flag files—essentially the electronic ability for a script to raise a flag to tell another script that something has happened.

To create a new (empty) file with touch, or to update the modification date of the file to the current time, the syntax for the touch command is simply

touch <filename to modify>

The touch command can actually update files to have any modification time that you'd like, although the preceding is by far the most common usage. Table 13.5 shows the command documentation table for touch.

Table 13.5. The Command Documentation Table for touch

touch [-acfhm] [-r <file>] [-t [[CC]YY]MMDDhhmm[.SS]] <file> ...

            

Share This