 |  |
| |
We've talked about hard links (Section 10.1) and symbolic links in a number of places, but we've not discussed why you'd want a file with several names. It was easy to understand what a link would do, but why would you want one?
There are many situations that links (and only links) are able to handle. Once you've seen a few of the problems that a link can solve, you'll start seeing even more situations in which they are appropriate.
Consider a company phone list on a system that is shared by several users. Every user might want a copy of the phone list in his home directory. However, you wouldn't want to give each user a different phone list. In addition to wasting disk space, it would be a pain to modify all of the individual lists whenever you made a change. Giving each user a "link" to a master phone list is one way to solve the problem.
Similarly, assume that you use several different systems that share files via NFS. Eventually, you get tired of editing five or six different .login and .cshrc files whenever you decide to add a new alias or change some element in your startup file; you'd like to have the exact same file appear in each of your home directories. You might also want to give several systems access to the same master database files.
How about this: you have a program or script that performs several related functions. Why not perform them all with the same executable? The script or program just needs to check the name by which it's called and act accordingly.
As another example, assume that you have two versions of a file: a current version, which changes from time to time, and one or more older versions. One good convention would be to name the files data.date, where date shows when the file was created. For example, you might have the files data.jul1, data.jul2, data.jul5, and so on. However, when you access these files, you don't necessarily want to figure out the date -- not unless you have a better chronological sense than I do. To make it easier on yourself, create a link (either symbolic or hard) named data.cur that always refers to your most recent file. The following script runs the program output, puts the data into a dated file, and resets data.cur:
#!/bin/sh curfile=data.`date +%h%d` linkname=data.cur output > $curfile rm -f $linkname ln -s $curfile $linkname
Here's an analogous situation. When writing technical manuals at one company, I had two classes of readers: some insisted on referring to the manuals by name, and the others by part number. Rather than looking up part numbers all the time, I created a set of links so that I could look up a manual online via either its name or its part number. For example, if the manual was named "Programming" and had the part number 046-56-3343, I would create the file /manuals/byname/programming. I would then create the link /manuals/bynumber/046-56-3343:
.. Section 1.16
% cd /manuals/bynumber % ln -s ../byname/programming 046-56-3343
Sometimes you simply want to collect an assortment of files in one directory. These files may really belong in other places, but you want to collect them for some temporary purpose: for example, to make a tape. Let's say that you want to make a tape that includes manual pages from /development/doc/man/man1, a manual from /development/doc/product, source files from /src/ccode, and a set of executables from /release/68000/execs. The following shell script creates links for all of these directories within the /tmp/tape directory and then creates a tar tape that can be sent to a customer or friend. Note that the tar h option tells tar to follow symbolic links and archive whatever is at the end of the link; otherwise, tar makes a copy of just the symbolic link:
#!/bin/sh dir=/tmp/tape.mike test -d $dir || mkdir $dir cd $dir rm -f man1 product ccode execs ln -s /development/doc/man/man1 ln -s /development/doc/product ln -s /src/ccode ln -s /release/68000/execs tar ch ./man1 ./product ./ccode ./execs
These examples only begin to demonstrate the use of linking in solving day-to-day tasks. Links provide neat solutions to many problems, including source control, filesystem layout, and so forth.
-- ML
|  | |
| 10.2. What's Really in a Directory? |  | 10.4. More About Links |
Copyright © 2003 O'Reilly & Associates. All rights reserved.