/usr/binto corresponding man pages and build directories. Assuming that disk space and batch compute time are free, this seems like a good "brute force" solution. In some cases, however, this strategy fails. For example, it is impossible (or at least, unreasonable) to generate static information for each possible file in
/var/spool/mqueue. On the other hand, a given file name (e.g.,
dfVAB20435) can easily be recognized and parsed by a regular expression. In short, some rules must be left as rules, rather than being instantiated as explicit links. In the production Meta system, these rules might be implemented as objects within the database. In the current prototype, they can be coded into the CGI script and/or encoded within the file tree.
The source code for commands includes the code to generate error messages. By extracting and annotating error information, Meta can help to clarify ambiguous diagnostics.
Command Directory Section Source Directory ----------------- ------- ---------------- /bin 1 /usr/src/bin /sbin 8 /usr/src/sbin /usr/bin 1 /usr/src/usr.bin /usr/games 6 /usr/src/games /usr/sbin 8 /usr/src/usr.sbin
sendmail(8)) is stored in a separate "contrib" directory (e.g.,
Makefilein the command's source directory contains the necessary linkage information.
/usr/objtree contains relocatable object files, "built" executables, and manual pages for the source code subtree(s). Thus,
/usr/obj/usr/src/bin/catcontains assorted files that are related to
Some commands "know about" given parts of the file system. For instance,
sendmail(8) knows about
/var/spool/mqueue. A Meta system should be able to explain which files are used by which commands, how, and why. In general, the needed linkage information can be elicited from the command's source code, but the process requires the participation of a competent programmer.
Source code files for commands may contain references to data structures, functions, include files, and macros. A rather large number of realationships may arise out of a single external reference. When a C function, for instance, references a function or macro that is defined elsewhere, several links mmay be generated:
function_a calls function_b function_a is_in file_a function_b is_in file_b function_b is_in library_c function_b has_man_page b(3) function_b calls syscall_d syscall_d has_man_page d(3)
System control files (e.g., in the
/etc subtree) often have manual pages in section 5, but the correspondence is rather loose. A hand-edited list (in progress) performs this mapping.
Many control files contain linkage information. For example, the
/etc/group files relate uids and gids, respectively, to user and group names.
The device nodes in
/dev generally have manual pages, but the correspondence between device names and manual pages can be rather loose (e.g.,
nrwt0 is documented by
wt(4). There are also conventions which map node names to minor numbers, etc. A hand-edited list (in progress) performs this mapping.
EclecticSystems have notions of file system navigation (e.g., parent and child relationships, hard and soft links) which allow programs to traverse file trees. Access rules, based on ownership and permision data, restrict the things that programs are able to do. Linkage information about the file system can let Meta predict system behavior and (perhaps) explain it after the fact.
/dev, several other directories and sub-trees have semi-regular to very regular name formation schemes, as:
/proc name is PID of process /usr/share/groff_font names signify font families, etc. /usr/share/calendar names signify calendar types /usr/share/info names signify relevant commands /usr/share/man names signify man sections and pages /usr/share/me names signify groff_me(7) macro families /usr/share/tmac names signify troff(1) macro families /usr/share/zoneinfo names signify time zones /var/spool/mqueue [dqx]f[AAA]nnnnn
As hinted above, a manual page
foo(#) will have corresponding files in
cat#/foo.#.gz formatted (nroff output) version man#/foo.#.gz raw ([nt]roff input) version