Reference Tutorial Developer 1 Compile 2 Design 3 Implement 4 Modify 5 Misc 6 Licence SEARCH

2.8 File Name Management

File names present a host of problems for a program like FunnelWeb. First, FunnelWeb can generate so many different kinds of files that conventions must be adopted to prevent their names from colliding. Second, the constraints on file names, and even the structure of file names themselves varies considerably from machine to machine. These two problems have combined to result in the sophisticated and rather complicated way in which FunnelWeb handles filenames.

To summarize, the three problems are:

1. What filename extensions should be chosen for various kinds of file?
2. What filename inheritance should take place?
3. How should FunnelWeb cope with the variations in filename structure between platforms?

These problems are addressed in the following sections.

Filename Extensions

FunnelWeb is capable of reading and writing a variety of different kinds of files. In particular, FunnelWeb must often operate in an environment where the same information is stored in many forms (e.g. prog.fw, prog.c, proc.exe). File extensions are an essential tool in managing this situation. The default filename extensions chosen for FunnelWeb are:

    FunnelWeb     : .fw
    Product       : None
    Documentation : .tex or .html
    Listing       : .lis
    Journal       : .jrn

Lowercase will be used in systems that are case sensitive.

Filename Inheritance

Inheritance in filenames refers to how input and output files inherit parts of their name from other filenames and their environment. For example if the command

       fw sloth +J +L +T

were issued, you would expect to see output files `sloth.jrn`, `sloth.lis`, and `sloth.tex`. The output file names have inherited the "`sloth`" part of the argument. In fact, FunnelWeb implements a comprehensive filename inheritance scheme, which is shown in the following table. Each filename is built up by starting at the top of its column in the table and working down the column, inheriting filename fields (directory, name, extension) that are absent at that point.

| Script | Input | Include | Journal | List | Document | Product
1 |  |  | `@i` |  |  |  | `@o`
2 | `+x` | `+f` | `+i` | `+j` | `+l` | `+t` | `+o`
3 | "`.fws`" | "`.fw`" | "`.fwi`" | "`.jrn`" | "`.lis`" | "`.tex`" |
4 |  |  | `+f` | `+f` | `+f` | `+f` |
5 | DefDir | Defdir | Defdir | Defdir | Defdir | Defdir | Defdir

The following notes explain the table.

1. Level 1 has the highest priority because it is a direct specification by the user.
2. Level 2 comes next because this is also a direct specification from the user on the command line.
3. Level 3 provides the default file extensions. Product files do not inherit an extension.
4. Level 5 is built into most operating systems' file specification systems. If you specify file "`x.y`", it is taken to mean on the default disk in the default directory.
5. Level 4 looks straightforward, but secretly conceals a difficult design decision. By the time we get down to this level of inheritance, we know for sure that the filename has already picked up a file extension. So all that is left to inherit is the path and the filename proper. Obviously we have to inherit the filename proper (e.g. `sloth` in `sloth.tex`), but should we inherit the input file path? If we do inherit the input file path, files will be placed in the same directory as the input file. If we don't inherit the input file path, files will be placed in the current directory. The choice made is to send all the logging type files into the same directory as the input file. This means, for example, that `sloth.lis` and `sloth.tex` will generally land in the same directory as `sloth.fw`. However, product files are sent to the default directory (if not earlier specified), as this is where the action is. In normal use, the main output of FunnelWeb will be product files, and so the user will expect them to appear in the current directory by default.

Portable Structure of File Names

Another problem with file names is the variation of their structure between environments. Here are examples of some of the formats that prevail:

       UNIX   /device/dir1/dir2/name
       VMS    node::device:[dir1.dir2]name.ext;vn
       MSDOS  device:\dir1\dir2\name.ext
       MAC    device:dir1:dir2:name

The solution to dealing with these different formats is to classify them as non-portable and hide the functions that manipulate them in the machine-specific module of FunnelWeb. Luckily there are not many such functions.

The main problem is coping with file systems that do not explicitly support file extensions. With so many possible input and output files, FunnelWeb all but needs such extensions. Machines that do not support them pose difficult design decisions. If the user specifies "`sloth`" as an input file on such a non-extension-supporting system, should FunnelWeb look for `sloth` or `sloth.fw`? If the user specifies `walrus` as a listing file, should it generate `walrus` or `walrus.lis`?

Some possible solutions are:

1. Regard the filename `sloth` as having an empty extension. It will then default to `sloth.fw`.
2. Regard the filename `sloth` as having a blank but full extension. That is, it cannot be overwritten by inheritance, but it remains blank.
3. Provide an extra syntactic mechanism to allow the user to specify one or other of the two options above.

The solution adopted in FunnelWeb is the first option. Use of FunnelWeb results in lots of files lying around (e.g. `sloth.lis`) and it is hard to see how the user will cope with them all without some kind of naming discipline. If a naming discipline has to be used, it might as well be the FunnelWeb one.

Thus the names of all files read and written by FunnelWeb will have a file extension of from zero to three letters separated from the rest of the filename by a "`.`".

The only exception is product files, whose extension is left undefined. Product files need not contain a "`.`" and a file extension.

Webmaster Copyright © Ross N. Williams 1992,1999. All rights reserved.