18.3 Files with Two or More Names

We talk about hard links and symbolic links in a number of places (18.4, 18.5, 24.4). However, we've never really said why you'd want a file with several names. When I was learning UNIX, this was a big stumbling block. It was easy to understand what a link would do, but why would you want one?

With time, I acquired wisdom. 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 or her 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 (1.33). Eventually, you get tired of editing five or six different .login and .cshrc (2.2) 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? All the script or program needs to do is check the name it's called by, and act accordingly. Article 45.13 explains how this works; articles 8.8, 16.7, and 22.10 show scripts that act differently depending on their (current) name.

Yet 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:

+%h%d	#!/bin/sh curfile=data.`date +%h%d` linkname=data.cur output > $curfile rm -f $linkname ln -s $curfile $linkname

Here's an analogous problem. 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 (believe it or not) 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 either via its name or via 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:

..	% 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 shell script below creates links for all of these directories within the /tmp/tape directory, and then creates a tar (20.1) 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:

/tmp	#!/bin/sh mkdir /tmp/tape cd /tmp/tape 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

This really only scrapes the surface. Links provide neat solutions to many problems, including source control, filesystem layout, etc.