WGML File and Directory Names

This page was written during the implementation of the search procedure for binary device files for wgml. It has not been confirmed that the results reported apply universally to wgml and gendev.

File Names

As noted in Common Attributes, gendev will encode the attribute member_name exactly as entered, although the resulting file name will conform with the 8.3 format typical of FAT. Of course, this is with the DOS version, so it is hard to say whether gendev itself is imposing these limits or if the OS is doing so.

The behavior implemented should be to encode the member name as entered and to use it (with extension ".COP" if no extension is given) as-is as the filename. All existing instances of the member name have no more than 8 characters and no extension, so this will pose no problem for the Open Watcom document build system. Even if gendev and wgml are released more generally, a user running gendev and wgml on a non-FAT filesystem should be able to use longer file names if desired.

Directory Names

These notes use ";" for the directory separator and deal with space characters in directory names. Most file systems do not actually allow spaces in file or directory names, and Linux uses ":" as the directory separator. However, the code itself actually uses a macro set to ';' or ':', as appropriate, so the code should work on any environment supported (even experimentally) by Open Watcom.

Non-exhaustive testing suggests that these directories will not work for wgml 4.0 when placed into a directory list:

1. ..\testlib;
2. "..\testlib;"
3. ..\testlib 0
4. "..\testlib 0"

Part of this may be a result of the limits on DOS programs and/or the FAT file system.

None of these appears to occur in the Open Watcom document build system -- certainly there are no embedded spaces, and I don't believe there are any embedded semicolons (or colons, for that matter) either.

Now, Windows XP, at least, allows ";" as a character in a directory name, so, in theory, one could appear. This could be accomodated using the second example:

"..\testlib;";..\testlib1

provided, of course, that the search for ";" is turned off within quoted directory names.

A brief test shows that Windows XP, in a 32-bit command window, will use a path of

"..\testlib;"

to find an executable, but not

..\testlib;

so it appears that this is supposed to work.

When I factored out the code parsing the strings containing the list of paths, I found that it was just as easy to check for quotes and even to add the "\" (or "/", this is, again, specified by a macro in the code and so should be correct for any target supported by Open Watcom) to the end if not present as not to do so. The end result is an array of strings, each containing a single directory path. It even turned out to make sense to trap over-long paths in this function and omit them from the list. As discussed in here, at some point, the resulting struct, variables, and function should be integrated into the existing file search functions in wgml.