|
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:
These problems are addressed in the following sections.
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.
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.
The following notes explain the table.
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:
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. |