Provided by:
zlibc_0.9j-7_i386 
Name
zlibc.conf - zlibc’s configuration file
Warning
This manpage has been automatically generated from zlibc’s texinfo
documentation. However, this process is only approximative, and some
items, such as crossreferences, footnotes and indices are lost in this
translation process. Indeed, this items have no appropriate
representation in the manpage format. Thus I strongly advise you to
use the original texinfo doc.
* To generate a printable copy from the texinfo doc, run the
following commands:
./configure; make dvi; dvips zlibc.dvi
* To generate a html copy, run:
./configure; make html
A premade html can be found at:
‘http://www.tux.org/pub/knaff/zlibc/zlibc.html’
* To generate an info copy (browsable using emacs’ info mode),
run:
./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.
Description
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.
Overall structure
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.
Commands section
General syntax of the commands section
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.
Available commands line flags
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.
disable / enable / LD_ZLIB_DISAB
The disable flag disables zlibc for the programs on this
commands line. This is useful for compression and uncompression
utilities. Without this flag, gunzip would not work anymore,
because it would think that the uncompressed file exists
already, and it would refuse to overwrite this file.
disable_child / enable_child / LD_ZLIB_DISAB_CHILD
The disable_child flag disables zlibc for the programs started
by programs on this commands line. This is implemented by
removeing all occurrences of uncompress.o from the LD_PRELOAD
environment variable. This function is useful for programs such
as xemacs, in order to make sure that all launched subprograms
return results consistent with emacs itself (directory listings,
etc)
readdir_compr / readdir_uncompr / LD_ZLIB_READDIR
The readdir function shows the uncompressed files (i.e. with
their trailing .gz extension) when the readdir_compr flag is
set, and the compressed files otherwise.
verbose / silent / LD_ZLIB_VERBOSE
When verbose is set, zlibc prints informational messages.
unlink / no_unlink / LD_ZLIB_UNLINK
If the unlink flag is set, and if the user program tries to
unlink a virtual (uncompressed) file, the package translates
this call into unlinking the real file. If the no_unlink flag is
set, requests to unlink virtual (uncompressed) files are
silently ignored.
Class section
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:
class "id"
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.
class "X"
subdir "/usr/X11R6" usetmpfile
subdir "/usr/X386" usetmpfile
subdir "/usr/lib/X11" usetmpfile
showpipe
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
File selection Criteria
The criterion describes what parts of the filename should match:
filename
The entire filename of the target data file must match name.
basename
The basename (filename without directory) of the target data
file must match name.
directory
The data file must live in the directory name. If the user
program opens the file with an absolute pathname, that filename
is used as is. If on the other hand the user program uses a
relative pathname, zlibc uses the most direct path to the file
(i.e. without symlinks).
subdirectory
The data file must live in the directory name or in one of its
subdirectories. If the user program opens the file with an
absolute pathname, that filename is used as is. If on the other
hand the user program uses a relative pathname, zlibc uses the
most direct path to the file (i.e. without symlinks).
suffix
The data file’s name must end in name. This is useful for
selecting files according to their extension.
filesystem
The data file must live on the same filesystem as name. This
criterion can for example be used for example to disable zlibc
on a doublespaced filesystem (where zlibc would be redundant),
or to switch off uncompressed size reporting on an ftpfs
filesystems .
default
All data files match. All class definitions must have a default
line, and this default line must be the last line of the
definition. The default criterion needs no ’name’ parameter.
all All data files match. Unlike default, this line needs not to be
the last line of the class definitions. Thus it is possible to
specify several all lines for different aspects of zlibc
behaviour.
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:
* Names beginning with a dot are considered as suffix.
* Names beginning with a slash, but not ending with a slash are
considered as filename.
* Names beginning and ending with a slash are considered as
subdirectory.
* A missing name is considered as default.
* All the other names are considered as basename.