Heirloom Project

☞ Home
☞ Toolchest
☞ Bourne Shell
☞ Documentation Tools
☞ Development Tools
☛ mailx
 ⌊ History
 ⌊ aux.c
☞ Packaging Tools
☞ vi

The tale of “aux.c”

In March 1978, Kurt Shoens, then a student at Berkeley, created a mail program. As it soon consisted of several thousand lines of source code, he chose to distribute it over several files. One of them was to contain “auxiliary functions”. Sticking with the good tradition to keep file names as short as possible while remaining distinctive, he chose “aux.c” for it. He was free to do so due to the clever design of the Unix file system name space: Since this was his own directory, it simply did not matter if anybody else wanted to choose the same name outside.

When Gary Kildall developed CP/M, starting in 1974, he seems to have been aware of Ritchie's and Thompson's 1974 Unix paper since he implemented device files. Unlike Unix, CP/M did not have a true hierarchical file system, though; each disk contained a single directory. The equivalent of a fully-qualified path name consisted of a drive letter followed by a colon, then the file name. Thus e.g. “A:SOURCE.BAS” would refer to the BASIC source code file “SOURCE.BAS” on drive “A”. To copy this file from drive “A” to drive “B”, a CP/M user typed “PIP B:SOURCE.BAS=A:SOURCE.BAS”. Although there was of course no /dev directory as on Unix because of the lack of a hierarchical file system, special files had their sane place in this environment: They were used in the same position as drive letters and could thus not conflict with actual data files. So “PIP LPT:=A:SOURCE.BAS” would have printed our file on the “LPT” device. (Cf. An Introduction to CP/M Features and Facilities, Digital Research, January 1978, pp. 18-25.)

Now, what has this to do with Berkeley Mail or mailx? When Microsoft introduced its CP/M clone, DOS, in 1981, it also had no hierarchical file system. It also kept the concept of device files. However, instead of putting them in the drive letter name space, Microsoft chose to have them directly within the directory on every disk. Moreover, it decided that it was a good idea to introduce some magic that stripped off the extension part, so that a program that always appended one, say, “.TXT”, would be able to use the device files as well. So when a DOS user saved the file “PRN.TXT”, the output appeared on the printer.

With DOS 2.0, Microsoft introduced a hierarchical file system. But guess what—it now put the device files into every directory on every disk. This may be hard to believe, but it is true: Each directory on DOS implicitly contains the files “NUL”, “PRN”, “CON”, etc., and as explained, also “NUL.TXT”, “PRN.BAS”, “CON.DOC”, etc.

Unfortunately, one of these DOS special files is called “AUX”, referring to a serial port, and this is where Berkeley Mail and its “aux.c” file really get into this story. Of course, the conflict went unnoticed for many years, since nobody would have tried to run an advanced Unix mail program on a microcomputer system that lacks any sane form of multitasking or networking.

But nowadays, people confuse Microsoft Windows, the successor to DOS, with a Unix operating system, and want to run mailx on it. I have no idea if one can still do anything useful with the “AUX” special file—since I have heard that current Windows versions actually manage devices in style of a multitasking, multi-user operating system, I would be surprised if one would be allowed to access a serial port this way without special privilege. Nevertheless, when people unpack the mailx source code distribution on a Windows system, something weird happens when it gets to extracting “aux.c”.

This has led to numerous Windows users whining to me since I have started this project.

But my answer is: No, I will not deface the mailx source code in order to make life easier for customers of a vendor of non-Unix systems who chose to clutter his directory name space with useless entries. I will especially not do so as this vendor has threatened free software on several occasions.

The Heirloom Project is oriented at the Unix tradition, and it is free. If you want to use mailx, there is the technically and morally sane option of using a free Unix implementation. You are on your own if you choose against it.