Buy GNU books!
./configure; make dvi; dvips zlibc.dvi
./configure; make htmlA premade html can be found at: http://www.tux.org/pub/knaff/zlibc/zlibc.html
./configure; make info
The texinfo doc looks most pretty when printed or as html. Indeed, in the info version certain examples are difficult to read due to the quoting conventions used in info.
To get its configuration, zlibc first looks into the file described by the environment variable LD_ZLIB_CONFFILE (if any), then in ~/.zlibrc and finally in /usr/local/etc/zlibc.conf (/etc/zlibc.conf on Linux ). If the desired information is found in neither of these files, the compiled-in defaults are used. It is possible to supply only part of the needed information in the configuration files. In that case, the missing information is retrieved from the compiled-in defaults. This allows you to have really small runtime configuration files, which only list the differences between the desired configuration and the compiled-in configuration.
If an error occurs while parsing one of the configuration files, the offending file is skipped, and the search continues with the next file. However, no error message is printed unless the environmental variable LD_ZLIB_VERBOSE is turned on (i.e. set to 1 or to on ).
If two files contain contradictory information, the information in the file which is scanned first is retained (usually ~/.zlibrc). If any flags have been set or unset using environmental variables, these settings override the flags specified in the configuration files.
The configuration files are read by each process. For each process, they are read at most once, at the time when zlibc is first used (attempt to access a compressed file). Afterwards they are cached in the process's virtual memory. Thus, changing zlibc configuration files doesn't generally have any effect on already running processes.
The zlibrc files consist of two sections: A commands section (Commands line flags) and a class definition section (Class section).
The commands section describes how zlibc should behave depending on the executable that it was called from. Several commands are grouped together into command classe.
The class definition section describes how zlibc should behave depending on the class of the command and the datafile opened.
The configuration file may contain comments in both sections: a comment starts with a hash (#) and stops at the end of the line.
Dashes (-) and underbars (_) may be used indifferently in all keywords.
The format for a line in the "commands" section is as follows:
commands "cmd1" [ ... "cmdn" ] use flags "class"
In this line, the cmd1 ... cmdn are the basenames of the programs (commands) for which this line should apply. The basename is the name without the path, i.e. ls instead of /usr/bin/ls. The command names should be enclosed in quotes. You may also use the keyword default (without quotes) to match all commands.
The flags describe those aspects of zlibc's behaviour that are independant from the datafile which is being accessed. These flags come in pairs. The flags need not to be listed on a single commands line, they may occur in several places, even in several different configuration files (for instance one in /etc/zlibc.conf and another one in ~/.zlibrc.
If two contradictory flags are found in the configuration files, the one which is seen first is taken.
If on the other hand a certain flag is not found at all in the configuration files, the compiled-in default for this flag is used. This is usually the second flag of each pair, described below (see section Commands line flags).
These flags can all be overridden by environmental variables. When the corresponding environmental variable is set to 1 or to on, the first flag is used, when it is set to 0 or to off. If the environmental variables is set to neither of these 4 values, it is ignored).
The class names the commands class that these commands belong to. If, for a given command, two commands lines give different classes, the one which is seen first is taken. No union of classes is made, the classes are always treated as a whole. Thus, if you want to make a change to a command class, you need to describe it in its entirety.
The following example says that the tar, cpio, pax, cp and mv show compressed files in a directory listing (readdir_compr flag), and are of class generic_safe.
commands "tar" "cpio" "pax" "cp" "mv" use readdir_compr "generic_safe"
The class generic_safe would then need to be described further in the class section.
This section describes the flags which can be used on a commands line. All these flags come in pairs.
The table below describes each of these pairs. The first word in the header of each item is the non-default flag, the second word is the default flag, and the third word is the environmental variable by which you can override the settings from the configuration files. If this environmental variable is turned on (set to 1), the non-default (first) flag is taken, if it is turned off (set to 0), the default (second) flag is taken.
A command class definition describes those aspects of zlibc's behavior that depend on the name of the datafile which is being accessed. Command classes are identified by a name which is matched against the class parameter from the commands. The class name should be enclosed between quotes both in the commands line and in the class definition.
The class section contains descriptions of different command classes (i.e descriptions how datafiles should be uncompressed). Each class definition begins with a line of the following format:
The class id is the same string as the one used in the commands line. The remaining lines of a class definition are as follows: [ [ criterion ] [ "name" ]] mode
The following example shows the definition of the class used for X-servers.
# X uses tmp files in its own directories.
subdir "/usr/X11R6" usetmpfile
subdir "/usr/X386" usetmpfile
subdir "/usr/lib/X11" usetmpfile
This says that all compressed files who are in a subdirectory below /usr/X11R6, /usr/X386 or /usr/lib/X11 are decompressed using temporary files (usetmpfile), and that files from other directories are decompressed using pipes (showpipe)
The following examples illustrates a command class, named nopipe, which always uses temporary files for decompression # generic class which uses temp files for all files. class "nopipe" usetmpfile
The criterion describes what parts of the filename should match:
The lines of each class definition are scanned in sequence, and, for each aspect, the first matching line is adopted. The class may be defined in another initialisation file, if this file is scanned later. The criterion parameter may be omitted if it can be deduced from the name. In that case, the following heuristics are used:
|webmaster||delorie software privacy|
|Copyright © 2003 by The Free Software Foundation||Updated Jun 2003|