As mentioned above, Kpathsea reads runtime configuration files
named `texmf.cnf' for search path and other definitions. The
search path used to look for these configuration files is named
TEXMFCNF
, and is constructed in the usual way, as described
above, except that configuration files cannot be used to define the
path, naturally; also, an `ls-R' database is not used to search for
them.
Kpathsea reads all `texmf.cnf' files in the search path, not just the first one found; definitions in earlier files override those in later files. Thus, with the search path of `.:$TEXMF', values from `./texmf.cnf' override those from `$TEXMF/texmf.cnf'.
While (or instead of) reading this description, you may find it helpful to look at the distributed `texmf.cnf', which uses or at least mentions most features. The format of `texmf.cnf' files follows:
variable [. progname] [=] valuewhere the `=' and surrounding whitespace is optional.
argv[0]
is) progname or
`progname.exe'. This allows different flavors of TeX to
have different search paths, for example.
CFLAGS
.)
Here is a configuration file fragment illustrating most of these points:
% TeX input files -- i.e., anything to be found by \input or \openin ... latex209_inputs = .:$TEXMF/tex/latex209//:$TEXMF/tex// latex2e_inputs = .:$TEXMF/tex/latex//:$TEXMF/tex// TEXINPUTS = .:$TEXMF/tex// TEXINPUTS.latex209 = $latex209_inputs TEXINPUTS.latex2e = $latex2e_inputs TEXINPUTS.latex = $latex2e_inputs
Although this format has obvious similarities to Bourne shell
scripts--change the comment character to #
, disallow spaces
around the =
, and get rid of the .name
convention,
and it could be run through the shell. But there seemed little
advantage to doing this, since all the information would have to passed
back to Kpathsea and parsed there anyway, since the sh
process
couldn't affect its parent's environment.
The implementation of all this is in `kpathsea/cnf.c'.
Go to the first, previous, next, last section, table of contents.