Archive for March, 2010

git-describe

Wednesday, March 31st, 2010



SYNOPSIS
git-describe [--all] [--tags] [--contains] [--abbrev=<n>]
<committish>…

DESCRIPTION
The command finds the most recent tag that is reachable from a commit.
If the tag points to the commit, then only the tag is shown. Otherwise,
it suffixes the tag name with the number of additional commits on top
of the tagged object and the abbreviated object name of the most recent
commit.

OPTIONS
<committish>
The object name of the committish.

–all
Instead of using only the annotated tags, use any ref found in
.git/refs/.

–tags
Instead of using only the annotated tags, use any tag found in
.git/refs/tags.

–contains
Instead of finding the tag that predates the commit, find the tag
that comes after the commit, and thus contains it. Automatically
implies –tags.

–abbrev=<n>
Instead of using the default 8 hexadecimal digits as the
abbreviated object name, use <n> digits.

–candidates=<n>
Instead of considering only the 10 most recent tags as candidates
to describe the input committish consider up to <n> candidates.
Increasing <n> above 10 will take slightly longer but may produce a
more accurate result. An <n> of 0 will cause only exact matches to
be output.

–exact-match
Only output exact matches (a tag directly references the supplied
commit). This is a synonym for –candidates=0.

–debug
Verbosely display information about the searching strategy being
employed to standard error. The tag name will still be printed to
standard out.

–long
Always output the long format (the tag, the number of commits and

EXAMPLES
With something like git.git current tree, I get:

[torvalds@g5 git]$ git-describe parent
v1.0.4-14-g2414721
i.e. the current head of my “parent” branch is based on v1.0.4, but
since it has a handful commits on top of that, describe has added the
number of additional commits (”14″) and an abbreviated object name for
the commit itself (”2414721″) at the end.

The number of additional commits is the number of commits which would
be displayed by “git log v1.0.4..parent”. The hash suffix is “-g” +
7-char abbreviation for the tip commit of parent (which was
2414721b194453f058079d897d13c4e377f92dc6).

Doing a “git-describe” on a tag-name will just show the tag name:

[torvalds@g5 git]$ git-describe v1.0.4
v1.0.4
With –all, the command can use branch heads as references, so the
output shows the reference path as well:

[torvalds@g5 git]$ git describe –all –abbrev=4 v1.0.5^2
tags/v1.0.0-21-g975b

[torvalds@g5 git]$ git describe –all HEAD^
heads/lt/describe-7-g975b
With –abbrev set to 0, the command can be used to find the closest
tagname without any suffix:

[torvalds@g5 git]$ git describe –abbrev=0 v1.0.5^2
tags/v1.0.0

SEARCH STRATEGY
For each committish supplied “git describe” will first look for a tag
which tags exactly that commit. Annotated tags will always be preferred
over lightweight tags, and tags with newer dates will always be
preferred over tags with older dates. If an exact match is found, its
name will be output and searching will stop.

If an exact match was not found “git describe” will walk back through
the commit history to locate an ancestor commit which has been tagged.
The ancestor’s tag will be output along with an abbreviation of the
input committish’s SHA1.

If multiple tags were found during the walk then the tag which has the
fewest commits different from the input committish will be selected and
output. Here fewest commits different is defined as the number of

GIT
Part of the git(1) suite

NOTES
1. torvalds@osdl.org
mailto:torvalds@osdl.org

2. gitster@pobox.com
mailto:gitster@pobox.com

3. spearce@spearce.org
mailto:spearce@spearce.org

4. git@vger.kernel.org
mailto:git@vger.kernel.org

Git 1.5.6.5 01/26/2010 GIT-DESCRIBE(1)

groffer

Tuesday, March 30th, 2010



SYNOPSIS
groffer [option...] [--] [filespec...]
groffer –apropos|–apropos-data|–apropos-devel|–apropos-progs name
groffer -h|–help
groffer -v|–version

DESCRIPTION
The groffer program is the easiest way to use groff(1). It can display
arbitrary documents written in the groff(7) language or other roff(7)
languages that are compatible to the original troff language. The
groffer program also includes many of the features for finding and dis-
playing the UNIX manual pages (man pages), such that it can be used as
a replacement for a man(1) program. Moreover, compressed files that
can be handled by gzip(1) or bzip2(1) are decompressed on-the-fly.

The normal usage is quite simple by supplying a file name or name of a
man page without further options. But the option handling has many
possibilities for creating special behaviors. This can be done in con-
figuration files, with the shell environment variable $GROFFER_OPT, or
on the command line.

The output can be generated and viewed in several different ways avail-
able for groff. This includes the groff native X viewer gxditview(1),
each Postcript or dvi display program, a web browser by generating html
in www-mode, or several text modes in text terminals.

Most of the options that must be named when running groff directly are
determined automatically for groffer, due to the internal usage of the
grog(1) program. But all parts can also be controlled manually by ar-
guments.

Several file names can be specified on the command line arguments.
They are transformed into a single document in the normal way of groff.

OPTION OVERVIEW
breaking options

[--apropos name] [--apropos-data name] [--apropos-devel name]
[--apropos-progs name] [-h|--help] [-v|--version]

groffer mode options

[--auto] [--default] [--default-modes mode1,mode2,...] [--dvi]
[--dvi-viewer prog] [--groff] [--html] [--html-viewer prog]
[--man] [--mode display_mode] [--no-man] [--pdf] [--pdf-viewer
prog] [--ps] [--ps-viewer prog] [--text] [--tty] [--tty-viewer
prog] [--www] [--www-viewer prog] [--x|--X] [--x-viewer|--X-
viewer prog]

development options

[--debug] [--shell]

options from man

[--all] [--ascii] [--ditroff] [--extension suffix] [--locale
language] [--local-file] [--manpath dir1:dir2:...] [--pager
program] [--sections sec1:sec2:...] [--systems sys1,sys2,...]
[--troff-device device] [--whatis]

Further long options of GNU man are accepted as well.

filespec argument

No filespec parameters means standard input.

- stands for standard input (can occur several times).

filename the path name of an existing file.

man:name(section)
name(section)
search the man page name in man section section.

man:name.s
name.s if s is a character in [1-9on], search for a man page
name in man section s.

man:name man page in the lowest man section that has name.

s name if s is a character in [1-9on], search for a man page
name in man section s.

name if name is not an existing file search for the
man page name in the lowest man section.

OPTION DETAILS
The groffer program can usually be run with very few options. But for
special purposes, it supports many options. These can be classified in
5 option classes.

All short options of groffer are compatible with the short options of
groff(1). All long options of groffer are compatible with the long op-
tions of man(1).

groffer breaking Options
As soon as one of these options is found on the command line it is exe-
cuted, printed to standard output, and the running groffer is terminat-
ed thereafter. All other arguments are ignored.

–apropos name
Start the apropos(1) command for searching within man page de-
scriptions. That slightly differs from the strange behavior of
the –apropos program of man(1), which has no argument of its

-h | –help
Print a helping information with a short explanation of option
sto standard output.

-v | –version
Print version information to standard output.

groffer Mode Options
The display mode and the viewer programs are determined by these op-
tions. If none of these mode and viewer options is specified groffer
tries to find a suitable display mode automatically.

–auto Equivalent to –mode=auto.

–default
Reset all configuration from previously processed command line
options to the default values. This is useful to wipe out all
former options of the configuration, in $GROFFER_OPT, and
restart option processing using only the rest of the command
line.

–default-modes mode1,mode2,…
Set the sequence of modes for auto mode to the comma separated
list given in the argument. See –mode for details on modes.
Display in the default manner; actually, this means to try the
modes x, ps, and tty in this sequence.

–dvi Equivalent to –mode=dvi.

–dvi-viewer prog
Set the viewer program for dvi mode. This can be a file name or
a program to be searched in $PATH. Known dvi viewers inlude xd-
vi(1) and dvilx(1) In each case, arguments can be provided addi-
tionally.

–groff
Equivalent to –mode=groff.

–html Equivalent to –mode=html.

–html-viewer
Equivalent to –www-viewer.

–mode value
Set the display mode. The following mode values are recognized:

auto Select the automatic determination of the display mode.
The sequence of modes that are tried can be set with the
–default-modes option. Useful for restoring the default
mode when a different mode was specified before.

pdf Display formatted input in a PDF (Portable Document For-
mat) viewer program. By default, the input is formatted
by groff using the Postscript device, then it is trans-
formed into the PDF file format using gs(1), and finally
displayed either with the xpdf(1) or the acroread(1) pro-
gram. PDF has a big advantage because the text is dis-
played graphically and is searchable as well. But as the
transformation takes a considerable amount of time, this
mode is not suitable as a default device for the auto
mode.

ps Display formatted input in a Postscript viewer program.
By default, the formatted input is displayed with the
ghostview(1) program.

text Format in a groff text mode and write the result to stan-
dard output without a pager or viewer program. The text
device, latin1 by default, can be chosen with option -T.

tty Format in a groff text mode and write the result to stan-
dard output using a text pager program, even when in X
Window.

www Equivalent to –www.

X Display formatted input in a native roff viewer. By de-
fault, the formatted input is displayed with the
gxditview(1) program, being distributed together with
groff, or with xditview(1), which is distributed as a
standard X tool.

x Equivalent to –mode=X.

The following modes do not use the groffer viewing features.
They are only interesting for advanced applications.

groff Generate device output with plain groff without using the
special viewing features of groffer. If no device was
specified by option -T the groff default ps is assumed.

source Display the source code of the input without formatting;
equivalent to -Q.

–pdf Equivalent to –mode=pdf.

–pdf-viewer prog
Set the viewer program for pdf mode. This can be a file name or
a program to be searched in $PATH. In each case, arguments can
be provided additionally.

–ps Equivalent to –mode=ps.

–www Equivalent to –mode=www.

–www-viewer prog
Set the web browser program for viewing in www mode. Each pro-
gram that accepts html input and allows the file://local-
host/dir/file syntax on the command line is suitable as viewer
program; it can be the path name of an executable file or a pro-
gram in $PATH. In each case, arguments can be provided addi-
tionally.

-X | –X | –x
Equivalent to –mode=X.

–X-viewer | –x-viewer prog
Set the viewer program for x mode. Suitable viewer programs are
gxditview(1) and xditview(1). But the argument can be any exe-
cutable file or a program in $PATH. In each case, arguments can
be provided additionally.

— Signals the end of option processing; all remaining arguments
are interpreted as filespec parameters.

Besides these, groffer accepts all arguments that are valid for the
groff(1) program. All non-groffer options are sent unmodified via grog
to groff. Postprocessors, macro packages, compatibility with classical
troff, and much more can be manually specified.

Options for Development
–debug
Print debugging information for development only. Actually, a
function call stack is printed if an error occurs.

–shell shell_program
Specify the shell under which the groffer script should be run.
The script first tests whether this option is set (either by
configuration, within $GROFF_OPT or as a command line option);
if so, the script is rerun under the shell program specified
with the option argument.

-Q | –source
Output the roff source code of the input files without further
processing. This is the equivalent –mode=source.

Other useful debugging options are the groff options -V and -Z and op-
tion –mode=groff.

Options related to groff
All short options of groffer are compatible with the short options of
groff(1). The following of groff options have either an additional
special meaning within groffer or make sense for normal usage.

Because of the special outputting behavior of the groff options -V and
the actual groff postprocessor.

-T | –device devname
This option determines groff’s output device. The most impor-
tant devices are the text output devices for referring to the
different character sets, such as ascii, utf8, latin1, and oth-
ers. Each of these arguments switches groffer into a text mode
using this device, to mode tty if the actual mode is not a text
mode. The following devname arguments are mapped to the corre-
sponding groffer –mode=devname option: dvi, html, and ps. All
X* arguments are mapped to mode X. Each other devname argument
switches to mode groff using this device.

-V Switch into groff mode and show only the groff calling pipe
without formatting the input. This an advanced option from
groff(1), only useful for debugging.

-X was made equivalent to –mode=x; this slightly enhances the fa-
cility of groff’s option.

-Z | –intermediate-output | –ditroff
Switch into groff mode and format the input with groff interme-
diate output without postprocessing; see groff_out(1). This is
equivalent to option –ditroff of man, which can be used as
well.

All other groff options are supported by groffer, but they are just
transparently transferred to groff without any intervention. The op-
tions that are not explicitly handled by groffer are transparently
passed to groff. Therefore these transparent options are not document-
ed here, but in groff(1). Due to the automatism in groffer, none of
these groff options should be needed, except for advanced usage.

X Window toolkit Options
The following long options were adapted from the corresponding X Toolk-
it options. groffer will pass them to the actual viewer program if it
is an X Window program. Otherwise these options are ignored.

Unfortunately these options use the old style of a single minus for
long options. For groffer that was changed to the standard with using
a double minus for long options, for example, groffer uses the option
–font for the X option -font.

See X(1), X(7), and the documentation on the X toolkit options for more
details on these options and their arguments.

–background color
Set the background color of the viewer window.

–bd pixels
Specifies the color of the border surrounding the viewer window.

–fg color
This is equivalent to -foreground.

–font font_name
Set the font used by the viewer window. The argument is an X
font name.

–ft font_name
This is equivalent to –ft.

–geometry size_pos
Set the geometry of the display window, that means its size and
its starting position. See X(7) for the syntax of the argument.

–resolution value
Set X resolution in dpi (dots per inch) in some viewer programs.
The only supported dpi values are 75 and 100. Actually, the de-
fault resolution for groffer is set to 75.

–rv Reverse foreground and background color of the viewer window.

–title ’some text’
Set the title for the viewer window.

–xrm ‘resource’
Set X resource.

Options from man
The long options of groffer were synchronized with the long options of
GNUman. All long options of GNU man are recognized, but not all of
these options are important to groffer, so most of them are just ig-
nored.

The following two options were added by groffer for choosing whether
the file name arguments are interpreted as names for local files or as
a search pattern for man pages. The default is looking up for local
files.

–man Check the non-option command line arguments (filespecs) first on
being man pages, then whether they represent an existing file.
By default, a filespec is first tested whether it is an existing
file.

–no-man | –local-file
Do not check for man pages. –local-file is the corresponding
man option.

In the following, the man options that have a special meaning for grof-
fer are documented.

The full set of long and short options of the GNU man program can be
passed via the environment variable $MANOPT; see man(1) if your system
/usr/share/man/man3/terminfo.3ncurses.gz the man page extension
is ncurses.

–locale language
Set the language for man pages. This has the same effect, but
overwrites $LANG

–location
Print the location of the retrieved files to standard error.

–no-location
Do not display the location of retrieved files; this resets a
former call to –location. This was added by groffer.

–manpath ‘dir1:dir2:…’
Use the specified search path for retrieving man pages instead
of the program defaults. If the argument is set to the empty
string “” the search for man page is disabled.

–pager
Set the pager program in tty mode; default is less. This is
equivalent to –tty-viewer.

–sections ’sec1:sec2:…’
Restrict searching for man pages to the given sections, a colon-
separated list.

–systems ’sys1,sys2,…’
Search for man pages for the given operating systems; the argu-
ment systems is a comma-separated list.

–whatis
Instead of displaying the content, get the one-liner description
from the retrieved man page files — or say that it is not a
man page.

–where
Eqivalent to –location.

Additionally, the following short option of man is supported as well.

Filespec Arguments
A filespec parameter is an argument meaning an input source, such as a
file name or template for searching man pages. These input sources are
collected and composed into a single output file such as groff does.

The strange POSIX behavior that maps all arguments behind the first
non-option argument into filespec arguments is ignored. The GNU behav-
ior to recognize options even when mixed with filespec arguments is
used througout. But, as usual, the double minus argument — still
takes all following arguments as filespecs.

name within several sections goes according to the classical single-
character sequence. On some systems, this single character can be ex-
tended by a following string. But the special groffer man page facili-
ty is based on the classical single character sections.

man:name(section) and name(section) search the man page name in
man section section, where section can be any string, but it must exist
in the man system.

Next some patterns based on the classical man sections were construct-
ed. man:name.s and name.s search for a man page name in man section s
if s is a classical man section mentioned above. Otherwise search for
a man page named name.s in the lowest man section.

Now man:name searches for a man page in the lowest man section that has
a document called name.

The pattern s name originates from a strange argument parsing of the
man program. If s is a classical man section interpret it as a search
for a man page called name in man section s, otherwise interpret s as a
file argument and name as another filespec argument.

We are left with the argument name which is not an existing file. So
this searches for the man page called name in the lowest man section
that has a document for this name.

Several file name arguments can be supplied. They are mixed by groff
into a single document. Note that the set of option arguments must fit
to all of these file arguments. So they should have at least the same
style of the groff language.

OUTPUT MODES
By default, the groffer program collects all input into a single file,
formats it with the groff program for a certain device, and then choos-
es a suitable viewer program. The device and viewer process in groffer
is called a mode. The mode and viewer of a running groffer program is
selected automatically, but the user can also choose it with options.
The modes are selected by option the arguments of –mode=anymode. Ad-
ditionally, each of this argument can be specified as an option of its
own, such as –anymode. Most of these modes have a viewer program,
which can be chosen by an option that is constructed like –anymode-
viewer.

Several different modes are offered, graphical X modes, text modes, and
some direct groff modes for debugging and development.

By default, groffer first tries whether x mode is possible, then ps
mode, and finally tty mode. This mode testing sequence for auto mode
can be changed by specifying a comma separated list of modes with the
option –default-modes.

The searching for man pages and the decompression of the input are ac-
mode),

o in a Postscript viewer (ps mode),

o in a dvi viewer program (dvi mode),

o in a PDF viewer (pdf mode),

o in a web browser (html or www mode),

The pdf mode has a major advantage — it is the only graphical diplay
mode that allows to search for text within the viewer; this can be a
really important feature. Unfortunately, it takes some time to trans-
form the input into the PDF format, so it was not chosen as the major
mode.

These graphical viewers can be customized by options of the X Window
Toolkit. But the groffer options use a leading double minus instead of
the single minus used by the X Window Toolkit.

Text mode
There are to modes for text output, mode text for plain output without
a pager and mode tty for a text output on a text terminal using some
pager program.

If the variable $DISPLAY is not set or empty, groffer assumes that it
should use tty mode.

In the actual implementation, the groff output device latin1 is chosen
for text modes. This can be changed by specifying option -T or
–device.

The pager to be used can be specified by one of the options –pager and
–tty-viewer, or by the environment variable $PAGER. If all of this is
not used the less(1) program with the option -r for correctly display-
ing control sequences is used as the default pager.

Special Modes for Debugging and Development
These modes use the groffer file determination and decompression. This
is combined into a single input file that is fed directly into groff
with different strategy without the groffer viewing facilities. These
modes are regarded as advanced, they are useful for debugging and de-
velopment purposes.

The source mode with just displays the generated input. The groff mode
passes the input to groff using only some suitable options provided to
groffer. This enables the user to save the generated output into a
file or pipe it into another program.

In groff mode, the option -Z disables post-processing, thus producing
the groff intermediate output. In this mode, the input is formatted,
but not postprocessed; see groff_out(5) for details.
disable the man searching; so only local files are displayed.

If neither a local file nor a man page was retrieved for some file pa-
rameter a warning is issued on standard error, but processing is con-
tinued.

The groffer program provides a search facility for man pages. All long
options, all environment variables, and most of the functionality of
the GNU man(1) program were implemented. This inludes the extended
file names of man pages, for example, the man page of groff in man sec-
tion 7 may be stored under /usr/share/man/man7/groff.7.gz, where
/usr/share/man/ is part of the man path, the subdirectory man7 and the
file extension .7 refer to the man section 7; .gz shows the compression
of the file.

The cat pages (preformatted man pages) are intentionally excluded from
the search because groffer is a roff program that wants to format by
its own. With the excellent performance of the actual computers, the
preformatted man pages aren’t necessary any longer.

The algorithm for retrieving man pages uses five search methods. They
are successively tried until a method works.

o The search path can be manually specified by using the option
–manpath. An empty argument disables the man page searching. This
overwrites the other methods.

o If this is not available the environment variable $MANPATH is
searched.

o If this is empty, the program tries to read it from the environment
variable $MANOPT.

o If this does not work a reasonable default path from $PATH is
searched for man pages.

o If this does not work, the manpath(1) program for determining a path
of man directories is tried.

After this, the path elements for the language (locale) and operating
system specific man pages are added to the man path; their sequence is
determined automatically. For example, both /usr/share/man/linux/fr
and /usr/share/man/fr/linux for french linux man pages are found. The
language and operating system names are determined from both environ-
ment variables and command line options.

The locale (language) is determined like in GNU man, that is from high-
est to lowest precedence:

o –locale

o $GROFFER_OPT
but the two-letter code in <language> is sufficient for most purposes.

If no man pages for a complicated locale are found the country part
consisting of the first two characters (without the `_’, `.’, and `,’,
parts) of the locale is searched as well.

If still not found the corresponding man page in the default language
is used instead. As usual, this default can be specified by one of C
or POSIX. The man pages in the default language are usually in En-
glish.

Several operating systems can be given by appending their names, sepa-
rated by a comma. This is then specified by the environment variable
$SYSTEM or by the command line option –systems. The precedence is
similar to the locale case above from highest to lowest precedence:
Topic –systems

o $GROFFER_OPT

o $MANOPT

o $SYSTEM.

When searching for man pages this man path with the additional language
and system specific directories is used.

The search can further be restricted by limiting it to certain sec-
tions. A single section can be specified within each filespec argu-
ment, several sections as a colon-separated list in command line option
–sections or environment variable $MANSECT. When no section was spec-
ified a set of standard sections is searched until a suitable man page
was found.

Finally, the search can be restricted to a so-called extension. This
is a postfix that acts like a subsection. It can be specified by
–extension or environment variable $EXTENSION.

For further details on man page searching, see man(1).

DECOMPRESSION
The program has a decompression facility. If standard input or a file
that was retrieved from the command line parameters is compressed with
a format that is supported by either gzip(1) or bzip2(1) it is decom-
pressed on-the-fly. This includes the GNU .gz, .bz2, and the tradi-
tional .Z compression. The program displays the concatenation of all
decompressed input in the sequence that was specified on the command
line.

ENVIRONMENT
The groffer programs supports many system variables, most of them by
courtesy of other programs. All environment variables of groff(1) and
GNU man(1) and some standard system variables are honored.

$DISPLAY
If this variable is set this indicates that the X Window system
is running. Testing this variable decides on whether graphical
or text output is generated. This variable should not be
changed by the user carelessly, but it can be used to start the
graphical groffer on a remote X terminal. For example, depend-
ing on your system, groffer can be started on the second monitor
by the command
sh# DISPLAY=:0.1 groffer what.ever&

$LC_ALL
$LC_MESSAGES
$LANG If one of these variables is set (in the above sequence), its
content is interpreted as the locale, the language to be used,
especially when retrieving man pages. A locale name is typical-
ly of the form language[_territory[.codeset[@modifier]]], where
language is an ISO 639 language code, territory is an ISO 3166
country code, and codeset is a character set or encoding identi-
fier like ISO-8859-1 or UTF-8; see setlocale(3). The locale
values C and POSIX stand for the default, i.e. the man page di-
rectories without a language prefix. This is the same behavior
as when all 3 variables are unset.

$PAGER This variable can be used to set the pager for the tty output.
For example, to disable the use of a pager completely set this
variable to the cat(1) program
sh# PAGER=cat groffer anything

$PATH All programs within the groffer shell script are called without
a fixed path. Thus this environment variable determines the set
of programs used within the run of groffer.

$POSIXLY_CORRECT
If set to a non-empty value this chooses the POSIX mode. This
is done internally by some shells. groffer ignores the bad
POSIX behavior for option processing, that means that option
processing will be finished as soon as a non-option argument is
found. Instead the GNU behavior of freely mixing options and
filespec arguments is used in any case. Usually, you do not
want to set this environment variable externally.

Groff Variables
The groffer program internally calls groff, so all environment vari-
ables documented in groff(1) are internally used within groffer as
well. The following variables have a direct meaning for the groffer
program.

$GROFF_TMPDIR
If the value of this variable is an existing, writable directo-
ry, groffer uses it for storing its temporary files, just as
groff does.

$MANOPT
This variable contains options as a preset for man(1). As not
all of these are relevant for groffer only the essential parts
of its value are extracted. The options specified in this vari-
able overwrite the values of the other environment variables
taht are specific to man. All options specified in this vari-
able are overridden by the options given on the command line.

$MANPATH
If set, this variable contains the directories in which the
man page trees are stored. This is overridden by option
–manpath.

$MANSECT
If this is a colon separated list of section names, the search
for man pages is restricted to those manual sections in that or-
der. This is overridden by option –sections.

$SYSTEM
If this is set to a comma separated list of names these are in-
terpreted as man page trees for different operating systems.
This variable can be overwritten by option –systems; see there
for details.

The environment variable $MANROFFSEQ is ignored by groffer because the
necessary preprocessors are determined automatically.

CONFIGURATION FILES
The groffer program can be preconfigured by two configuration files.
This configuration can be overridden at each program start by command
line options or by the environment variable $GROFFER_OPT.

/etc/groff/groffer.conf
System-wide configuration file for groffer.

$HOME/.groff/groffer.conf
User-specific configuration file for groffer, where $HOME de-
notes the user’s home directory. This script is called after
the system-wide configuration file to enable overriding by the
user.

Their lines either start with a minus character or are shell commands.
Arbitrary spaces are allowed at the beginning, they are just ignored.
The lines with the beginning minus are appended to the existing value
of $GROFFER_OPT. This easily allows to set general groffer options
that are used with any call of groffer.

After the transformation of the minus lines the emerging shell scripts
that are called by groffer using the `. filename’ syntax.

The only option that needs a minus line in the configuration files is
–shell. The reason is that its argument must be called at a very ear-
program in the system path $PATH in order to be recognized by grof-
fer.

As an example, consider the following configuration file in
~/.groff/groffer.conf, say.

# groffer configuration file
#
# groffer options that are used in each call of groffer
–shell=/bin/bash
–resolution=100
–foreground=DarkBlue
–x-viewer=’gxditview -geometry 850×800′
#
# some shell commands
if test “$DISPLAY” = “”; then
DISPLAY=’localhost:0.0′
fi
date >>~/mygroffer.log

This configuration sets four groffer options and runs two shell com-
mands. This has the following effects:

o Lines starting with a # character are

o Use /bin/bash as the shell to run the groffer script.

o Take a resolution of 100 dpi and a text color of DarkBlue in all
viewers that support this.

o Force gxditview(1) as the X-mode viewer using the geometry option for
setting the width to 850 dpi and the height to 800 dpi.

o The variable $DISPLAY is set to localhost:0.0 which allows to start
groffer in the standard X display, even when the program is called
from a text console.

o Just for fun, the date of each groffer start is written to the file
mygroffer.log in the home directory.

EXAMPLES
The usage of groffer is very easy. Usually, it is just called with a
file name or man page. The following examples, however, show that
groffer has much more fancy capabilities.

sh# groffer /usr/local/share/doc/groff/meintro.ms.gz
Decompress, format and display the compressed file meintro.ms.gz
in the directory /usr/local/share/doc/groff, using gxditview as
graphical viewer when in X Window, or the less(1) pager program
when not in X.

sh# groffer groff
sh# groffer fb.modes
If the file ./fb.modes does not exist interpret this as a search
for the man page of fb.modes. As the extension modes is not a
single character in classical section style the argument is not
split to a search for fb.

sh# groffer groff ‘troff(1)‘ man:roff
The arguments that are not existing files are looked-up as the
following man pages: groff (automatic search, should be found in
man section 1), troff (in section 1), and roff (in the section
with the lowest number, being 7 in this case). The quotes
around ‘troff(1)‘ are necessary because the paranthesis are spe-
cial shell characters; escaping them with a backslash character
\( and \) would be possible, too. The formatted files are con-
catenated and displayed in one piece.

sh# LANG=de groffer –man –www –www-viever=mozilla ls
Retrieve the German man page (language de) for the ls program,
decompress it, format it to html format (www mode) and view the
result in the web browser galeon . The option –man guarantees
that the man page is retrieved, even when a local file ls exists
in the actual directory.

sh# groffer –source ‘man:roff(7)
Get the man page called roff in man section 7, decompress it,
and print its unformatted content, its source code.

sh# cat file.gz | groffer -Z -mfoo
Decompress the standard input, send this to groff intermediate
mode without post-processing (groff option -Z), using macro
package by foo (groff option -m)

sh# echo ‘\f[CB]WOW!’ |
> groffer –x –bg red –fg yellow –geometry 200×100 -
Display the word WOW! in a small window in constant-width bold
font, using color yellow on red background.

COMPATIBILITY
The groffer shell script is compatible with both GNU and POSIX. POSIX
compatibility refers to IEEE P1003.2/D11.2 of September 1991, a very
early version of the POSIX standard that is still freely available in
the internet. Unfortunately, this version of the standard has `local’
for shell function variables removed. As `local’ is needed for serious
programming this temporary POSIX deprecation was ignored.

Most GNU shells are compatible with this interpretation of POSIX, but
provide much more facilities. Nevertheless this script uses only a re-
stricted set of shell language elements and shell builtins. The grof-
fer script should work on most actual free and commercial operating
systems.

The groffer program provides its own parser for command line options;
The groffer program provides its own parser for command line arguments
that is compatible to both POSIX getopts(1) and GNU getopt(1) except
for shortcuts of long options. The following standard types of options
are supported.

o A single minus always refers to single character option or a combina-
tion thereof, for example, the groffer short option combination
-Qmfoo is equivalent to -Q -m foo.

o Long options are options with names longer than one character; they
are always prededed by a double minus. An option argument can either
go to the next command line argument or be appended with an equal
sign to the argument; for example, –long=arg is equivalent to
–long arg .

o An argument of — ends option parsing; all further command line argu-
ments are interpreted as file name arguments.

o By default, all command line arguments that are neither options nor
option arguments are interpreted as filespec parameters and stored
until option parsing has finished. For example, the command line
sh# groffer file1 -a -o arg file2
is, by default, equivalent to
sh# groffer -a -o arg — file1 file2

This behavior can be changed by setting the environment variable
$POSIXLY_CORRECT to a non-empty value. Then the strange POSIX non-op-
tion behavior is adopted, i. e. option processing is stopped as soon as
the first non-option argument is found and each following argument is
taken as a file name. For example, in posixly correct mode, the com-
mand line
sh# groffer file1 -a -o arg file 2
is equivalent to
sh# groffer — file1 -a -o arg file 2
As this leads to unwanted behavior in most cases, most people do not
want to set $POSIXLY_CORRECT.

SEE ALSO
groff(1)
troff(1)
Details on the options and environment variables available in
groff; all of them can be used with groffer.

man(1) The standard program to diplay man pages. The information there
is only useful if it is the man page for GNU man. Then it docu-
ments the options and environment variables that are supported
by groffer.

gxditview(1)
xditview(1x)
Viewers for groffer’s x mode.

gzip(1)
bzip2(1)
The decompression programs supported by groffer.

groff(7)
Documentation of the groff language.

grog(1)
Internally, groffer tries to guess the groff command line op-
tions from the input using this program.

groff_out(5)
Documentation on the groff intermediate output (ditroff output).

AUTHOR
This file was written by Bernd Warken.

COPYING
Copyright (C) 2001,2002,2004 Free Software Foundation, Inc.

This file is part of groff, a free software project. You can redis-
tribute it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either version 2,
or (at your option) any later version.

You should have received a copy of the GNU General Public License along
with groff, see the files COPYING and LICENSE in the top directory of
the groff source package. Or read the man page gpl(1). You can also
write to the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.

Groff Version 1.18.1 07 March 2005 GROFFER(1)

pbmtowbmp

Monday, March 29th, 2010



SYNOPSIS
pbmtowbmp [pbmfile]

DESCRIPTION
Reads a portable bitmap as input. Produces a wbmp file as output.

LIMITATIONS
Currently only WBMP type 0 is generated. This is the only type speci-
fied in the WAP 1.1 specifications.

SEE ALSO
pbm(5), wbmptopbm(1), Wireless Application Environment Specification.

AUTHOR
Copyright (C) 1999 Terje Sannum <terje@looplab.com>.

19 November 1999 pbmtowbmp(1)

make

Sunday, March 28th, 2010



SYNOPSIS
make [ -f makefile ] [ options ] … [ targets ] …

WARNING
This man page is an extract of the documentation of GNU make. It is
updated only occasionally, because the GNU project does not use nroff.
For complete, current documentation, refer to the Info file make.info
which is made from the Texinfo source file make.texi.

DESCRIPTION
The purpose of the make utility is to determine automatically which
pieces of a large program need to be recompiled, and issue the commands
to recompile them. The manual describes the GNU implementation of
make, which was written by Richard Stallman and Roland McGrath, and is
currently maintained by Paul Smith. Our examples show C programs,
since they are most common, but you can use make with any programming
language whose compiler can be run with a shell command. In fact, make
is not limited to programs. You can use it to describe any task where
some files must be updated automatically from others whenever the oth-
ers change.

To prepare to use make, you must write a file called the makefile that
describes the relationships among files in your program, and the states
the commands for updating each file. In a program, typically the exe-
cutable file is updated from object files, which are in turn made by
compiling source files.

Once a suitable makefile exists, each time you change some source
files, this simple shell command:

make

suffices to perform all necessary recompilations. The make program
uses the makefile data base and the last-modification times of the
files to decide which of the files need to be updated. For each of
those files, it issues the commands recorded in the data base.

make executes commands in the makefile to update one or more target
names, where name is typically a program. If no -f option is present,
make will look for the makefiles GNUmakefile, makefile, and Makefile,
in that order.

Normally you should call your makefile either makefile or Makefile.
(We recommend Makefile because it appears prominently near the begin-
ning of a directory listing, right near other important files such as
README.) The first name checked, GNUmakefile, is not recommended for
most makefiles. You should use this name if you have a makefile that
is specific to GNU make, and will not be understood by other versions
of make. If makefile is `-’, the standard input is read.

make updates a target if it depends on prerequisite files that have
been modified since the target was last modified, or if the target does
-C /etc. This is typically used with recursive invocations of
make.

-d Print debugging information in addition to normal processing. The
debugging information says which files are being considered for
remaking, which file-times are being compared and with what
results, which files actually need to be remade, which implicit
rules are considered and which are applied—everything interest-
ing about how make decides what to do.

–debug[=FLAGS]
Print debugging information in addition to normal processing. If
the FLAGS are omitted, then the behavior is the same as if -d was
specified. FLAGS may be a for all debugging output (same as using
-d), b for basic debugging, v for more verbose basic debugging, i
for showing implicit rules, j for details on invocation of com-
mands, and m for debugging while remaking makefiles.

-e, –environment-overrides
Give variables taken from the environment precedence over vari-
ables from makefiles.

-f file, –file=file, –makefile=FILE
Use file as a makefile.

-i, –ignore-errors
Ignore all errors in commands executed to remake files.

-I dir, –include-dir=dir
Specifies a directory dir to search for included makefiles. If
several -I options are used to specify several directories, the
directories are searched in the order specified. Unlike the argu-
ments to other flags of make, directories given with -I flags may
come directly after the flag: -Idir is allowed, as well as -I dir.
This syntax is allowed for compatibility with the C preprocessor’s
-I flag.

-j [jobs], –jobs[=jobs]
Specifies the number of jobs (commands) to run simultaneously. If
there is more than one -j option, the last one is effective. If
the -j option is given without an argument, make will not limit
the number of jobs that can run simultaneously.

-k, –keep-going
Continue as much as possible after an error. While the target
that failed, and those that depend on it, cannot be remade, the
other dependencies of these targets can be processed all the same.

-l [load], –load-average[=load]
Specifies that no new jobs (commands) should be started if there
are others jobs running and the load average is at least load (a
floating-point number). With no argument, removes a previous load

-p, –print-data-base
Print the data base (rules and variable values) that results from
reading the makefiles; then execute as usual or as otherwise spec-
ified. This also prints the version information given by the -v
switch (see below). To print the data base without trying to
remake any files, use make -p -f/dev/null.

-q, –question
“Question mode”. Do not run any commands, or print anything;
just return an exit status that is zero if the specified targets
are already up to date, nonzero otherwise.

-r, –no-builtin-rules
Eliminate use of the built-in implicit rules. Also clear out the
default list of suffixes for suffix rules.

-R, –no-builtin-variables
Don’t define any built-in variables.

-s, –silent, –quiet
Silent operation; do not print the commands as they are executed.

-S, –no-keep-going, –stop
Cancel the effect of the -k option. This is never necessary
except in a recursive make where -k might be inherited from the
top-level make via MAKEFLAGS or if you set -k in MAKEFLAGS in your
environment.

-t, –touch
Touch files (mark them up to date without really changing them)
instead of running their commands. This is used to pretend that
the commands were done, in order to fool future invocations of
make.

-v, –version
Print the version of the make program plus a copyright, a list of
authors and a notice that there is no warranty.

-w, –print-directory
Print a message containing the working directory before and after
other processing. This may be useful for tracking down errors
from complicated nests of recursive make commands.

–no-print-directory
Turn off -w, even if it was turned on implicitly.

-W file, –what-if=file, –new-file=file, –assume-new=file
Pretend that the target file has just been modified. When used
with the -n flag, this shows you what would happen if you were to
modify that file. Without -n, it is almost the same as running a
touch command on the given file before running make, except that

BUGS
See the chapter `Problems and Bugs’ in The GNU Make Manual.

AUTHOR
This manual page contributed by Dennis Morse of Stanford University.
It has been reworked by Roland McGrath. Further updates contributed by
Mike Frysinger.

COPYRIGHT
Copyright (C) 1992, 1993, 1996, 1999 Free Software Foundation, Inc.
This file is part of GNU make.

GNU make is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2, or (at your option) any
later version.

GNU make is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License along
with GNU make; see the file COPYING. If not, write to the Free Soft-
ware Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301, USA.

GNU 22 August 1989 MAKE(1)

zcmp

Saturday, March 27th, 2010



SYNOPSIS
zcmp [ cmp_options ] file1 [ file2 ]
zdiff [ diff_options ] file1 [ file2 ]

DESCRIPTION
Zcmp and zdiff are used to invoke the cmp or the diff program on files
compressed via gzip. All options specified are passed directly to cmp
or diff. If only 1 file is specified, then the files compared are
file1 and an uncompressed file1.gz. If two files are specified, then
they are uncompressed if necessary and fed to cmp or diff. The exit
status from cmp or diff is preserved.

SEE ALSO
cmp(1), diff(1), zmore(1), zgrep(1), znew(1), zforce(1), gzip(1),
gzexe(1)

BUGS
Messages from the cmp or diff programs refer to temporary filenames
instead of those specified.

ZDIFF(1)

pnmmontage

Friday, March 26th, 2010



SYNOPSIS
pnmmontage [-?|-help] [-header=headerfile] [-quality=n] [-prefix=pre-
fix] [-0|-1|-2|...|-9] pnmfile…

DESCRIPTION
Packs images of differing sizes into a minimum-area composite image,
optionally producing a C header file with the locations of the subim-
ages within the composite image.

OPTIONS
-?, -help
Displays a (very) short usage message.

-header
Tells pnmmontage to write a C header file of the locations of
the original images within the packed image. Each original
image generates four #defines within the packed file: xxxX,
xxxY, xxxSZX, and xxxSZY, where xxx is the name of the file,
converted to all uppercase. The #defines OVERALLX and OVERALLY
are also produced, specifying the total size of the montage
image.

-prefix
Tells pnmmontage to use the specified prefix on all of the
#defines it generates.

-quality
Before attempting to place the subimages, pnmmontage will calcu-
late a minimum possible area for the montage; this is either the
total of the areas of all the subimages, or the width of the
widest subimage times the height of the tallest subimage,
whichever is greater. pnmmontage then initiates a problem-space
search to find the best packing; if it finds a solution that is
(at least) as good as the minimum area times the quality as a
percent, it will break out of the search. Thus, -q 100 will
find the best possible solution; however, it may take a very
long time to do so. The default is -q 200.

-0, -1, … -9
These options control the quality at a higher level than -q; -0
is the worst quality (literally pick the first solution found),
while -9 is the best quality (perform an exhaustive search of
problem space for the absolute best packing). The higher the
number, the slower the computation. The default is -5.

NOTES
Using -9 is excessively slow on all but the smallest image sets. If
the anymaps differ in maxvals, then pnmmontage will pick the smallest
maxval which is evenly divisible by each of the maxvals of the original
images.

SEE ALSO

defoma-id

Thursday, March 25th, 2010



SYNOPSIS
defoma-id [options] list-cache app
defoma-id [options] install app/id-cache id font
defoma-id [options] exclude app/id-cache id font
defoma-id [options] unset app/id-cache id font
defoma-id [options] add-alias app/id-cache id font alias
defoma-id [options] remove-alias app/id-cache alias font

DESCRIPTION
defoma-id is supposed to be invoked not from a command line, but from
dfontmgr.

SEE ALSO
defoma(1). dfontmgr(1).

March 4, 2001 defoma-id(1)

mysql_tzinfo_to_sql

Wednesday, March 24th, 2010



SYNOPSIS
mysql_tzinfo_to_sql arguments

DESCRIPTION
The mysql_tzinfo_to_sql program loads the time zone tables in the mysql
database. It is used on systems that have a zoneinfo database (the set
of files describing time zones). Examples of such systems are Linux,
FreeBSD, Sun Solaris, and Mac OS X. One likely location for these files
is the /usr/share/zoneinfo directory. If your system does not have a
zoneinfo database, you can use the downloadable package described in
Section 9, “MySQL Server Time Zone Support”.

mysql_tzinfo_to_sql can be invoked several ways:

shell> mysql_tzinfo_to_sql tz_dir
shell> mysql_tzinfo_to_sql tz_file tz_name
shell> mysql_tzinfo_to_sql –leap tz_file

For the first invocation syntax, pass the zoneinfo directory pathname
to mysql_tzinfo_to_sql and send the output into the mysql program. For
example:

shell> mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql

mysql_tzinfo_to_sql reads your system’s time zone files and generates
SQL statements from them. mysql processes those statements to load the
time zone tables.

The second syntax causes mysql_tzinfo_to_sql to load a single time zone
file tz_file that corresponds to a time zone name tz_name:

shell> mysql_tzinfo_to_sql tz_file tz_name | mysql -u root mysql

If your time zone needs to account for leap seconds, invoke
mysql_tzinfo_to_sql using the third syntax, which initializes the leap
second information. tz_file is the name of your time zone file:

shell> mysql_tzinfo_to_sql –leap tz_file | mysql -u root mysql

After running mysql_tzinfo_to_sql, it is best to restart the server so
that it does not continue to use any previously cached time zone data.

COPYRIGHT
Copyright 2007-2008 MySQL AB

This documentation is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; version 2 of the License.

This documentation is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU

MySQL 5.0 01/11/2008 MYSQL_TZINFO_TO_S(1)

mgrtopbm

Tuesday, March 23rd, 2010



SYNOPSIS
mgrtopbm [mgrfile]

DESCRIPTION
Reads a MGR bitmap as input. Produces a portable bitmap as output.

SEE ALSO
pbmtomgr(1), pbm(5)

AUTHOR
Copyright (C) 1989 by Jef Poskanzer.

24 January 1989 mgrtopbm(1)

dig

Monday, March 22nd, 2010



SYNOPSIS
dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-m]
[-p port#] [-q name] [-t type] [-x addr] [-y [hmac:]name:key] [-4]
[-6] [name] [type] [class] [queryopt...]

dig [-h]

dig [global-queryopt...] [query...]

DESCRIPTION
dig (domain information groper) is a flexible tool for interrogating
DNS name servers. It performs DNS lookups and displays the answers that
are returned from the name server(s) that were queried. Most DNS
administrators use dig to troubleshoot DNS problems because of its
flexibility, ease of use and clarity of output. Other lookup tools tend
to have less functionality than dig.

Although dig is normally used with command-line arguments, it also has
a batch mode of operation for reading lookup requests from a file. A
brief summary of its command-line arguments and options is printed when
the -h option is given. Unlike earlier versions, the BIND 9
implementation of dig allows multiple lookups to be issued from the
command line.

Unless it is told to query a specific name server, dig will try each of
the servers listed in /etc/resolv.conf.

When no command line arguments or options are given, dig will perform
an NS query for “.” (the root).

It is possible to set per-user defaults for dig via ${HOME}/.digrc.
This file is read and any options in it are applied before the command
line arguments.

The IN and CH class names overlap with the IN and CH top level domains
names. Either use the -t and -c options to specify the type and class,
use the -q the specify the domain name, or use “IN.” and “CH.” when
looking up these top level domains.

SIMPLE USAGE
A typical invocation of dig looks like:

dig @server name type

where:

server
is the name or IP address of the name server to query. This can be
an IPv4 address in dotted-decimal notation or an IPv6 address in
colon-delimited notation. When the supplied server argument is a
hostname, dig resolves that name before querying that name server.
If no server argument is provided, dig consults /etc/resolv.conf

“0.0.0.0″ or “::”. An optional port may be specified by appending
“#<port>”

The default query class (IN for internet) is overridden by the -c
option. class is any valid class, such as HS for Hesiod records or CH
for Chaosnet records.

The -f option makes dig operate in batch mode by reading a list of
lookup requests to process from the file filename. The file contains a
number of queries, one per line. Each entry in the file should be
organized in the same way they would be presented as queries to dig
using the command-line interface.

The -m option enables memory usage debugging.

If a non-standard port number is to be queried, the -p option is used.
port# is the port number that dig will send its queries instead of the
standard DNS port number 53. This option would be used to test a name
server that has been configured to listen for queries on a non-standard
port number.

The -4 option forces dig to only use IPv4 query transport. The -6
option forces dig to only use IPv6 query transport.

The -t option sets the query type to type. It can be any valid query
type which is supported in BIND 9. The default query type is “A”,
unless the -x option is supplied to indicate a reverse lookup. A zone
transfer can be requested by specifying a type of AXFR. When an
incremental zone transfer (IXFR) is required, type is set to ixfr=N.
The incremental zone transfer will contain the changes made to the zone
since the serial number in the zone’s SOA record was N.

The -q option sets the query name to name. This useful do distinguish
the name from other arguments.

Reverse lookups — mapping addresses to names — are simplified by the
-x option. addr is an IPv4 address in dotted-decimal notation, or a
colon-delimited IPv6 address. When this option is used, there is no
need to provide the name, class and type arguments. dig automatically
performs a lookup for a name like 11.12.13.10.in-addr.arpa and sets the
query type and class to PTR and IN respectively. By default, IPv6
addresses are looked up using nibble format under the IP6.ARPA domain.
To use the older RFC1886 method using the IP6.INT domain specify the -i
option. Bit string labels (RFC2874) are now experimental and are not
attempted.

To sign the DNS queries sent by dig and their responses using
transaction signatures (TSIG), specify a TSIG key file using the -k
option. You can also specify the TSIG key itself on the command line
using the -y option; hmac is the type of the TSIG, default HMAC-MD5,
name is the name of the TSIG key and key is the actual key. The key is
a base-64 encoded string, typically generated by dnssec-keygen(8).
Each query option is identified by a keyword preceded by a plus sign
(+). Some keywords set or reset an option. These may be preceded by the
string no to negate the meaning of that keyword. Other keywords assign
values to options like the timeout interval. They have the form
+keyword=value. The query options are:

+[no]tcp
Use [do not use] TCP when querying name servers. The default
behavior is to use UDP unless an AXFR or IXFR query is requested,
in which case a TCP connection is used.

+[no]vc
Use [do not use] TCP when querying name servers. This alternate
syntax to +[no]tcp is provided for backwards compatibility. The
“vc” stands for “virtual circuit”.

+[no]ignore
Ignore truncation in UDP responses instead of retrying with TCP. By
default, TCP retries are performed.

+domain=somename
Set the search list to contain the single domain somename, as if
specified in a domain directive in /etc/resolv.conf, and enable
search list processing as if the +search option were given.

+[no]search
Use [do not use] the search list defined by the searchlist or
domain directive in resolv.conf (if any). The search list is not
used by default.

+[no]showsearch
Perform [do not perform] a search showing intermediate results.

+[no]defname
Deprecated, treated as a synonym for +[no]search

+[no]aaonly
Sets the “aa” flag in the query.

+[no]aaflag
A synonym for +[no]aaonly.

+[no]adflag
Set [do not set] the AD (authentic data) bit in the query. The AD
bit currently has a standard meaning only in responses, not in
queries, but the ability to set the bit in the query is provided
for completeness.

+[no]cdflag
Set [do not set] the CD (checking disabled) bit in the query. This
requests the server to not perform DNSSEC validation of responses.

name servers for the zone containing the name being looked up and
display the SOA record that each name server has for the zone.

+[no]trace
Toggle tracing of the delegation path from the root name servers
for the name being looked up. Tracing is disabled by default. When
tracing is enabled, dig makes iterative queries to resolve the name
being looked up. It will follow referrals from the root servers,
showing the answer from each server that was used to resolve the
lookup.

+[no]cmd
Toggles the printing of the initial comment in the output
identifying the version of dig and the query options that have been
applied. This comment is printed by default.

+[no]short
Provide a terse answer. The default is to print the answer in a
verbose form.

+[no]identify
Show [or do not show] the IP address and port number that supplied
the answer when the +short option is enabled. If short form answers
are requested, the default is not to show the source address and
port number of the server that provided the answer.

+[no]comments
Toggle the display of comment lines in the output. The default is
to print comments.

+[no]stats
This query option toggles the printing of statistics: when the
query was made, the size of the reply and so on. The default
behavior is to print the query statistics.

+[no]qr
Print [do not print] the query as it is sent. By default, the query
is not printed.

+[no]question
Print [do not print] the question section of a query when an answer
is returned. The default is to print the question section as a
comment.

+[no]answer
Display [do not display] the answer section of a reply. The default
is to display it.

+[no]authority
Display [do not display] the authority section of a reply. The
default is to display it.

of the default, 3. If T is less than or equal to zero, the number
of tries is silently rounded up to 1.

+retry=T
Sets the number of times to retry UDP queries to server to T
instead of the default, 2. Unlike +tries, this does not include the
initial query.

+ndots=D
Set the number of dots that have to appear in name to D for it to
be considered absolute. The default value is that defined using the
ndots statement in /etc/resolv.conf, or 1 if no ndots statement is
present. Names with fewer dots are interpreted as relative names
and will be searched for in the domains listed in the search or
domain directive in /etc/resolv.conf.

+bufsize=B
Set the UDP message buffer size advertised using EDNS0 to B bytes.
The maximum and minimum sizes of this buffer are 65535 and 0
respectively. Values outside this range are rounded up or down
appropriately. Values other than zero will cause a EDNS query to be
sent.

+edns=#
Specify the EDNS version to query with. Valid values are 0 to 255.
Setting the EDNS version will cause a EDNS query to be sent.
+noedns clears the remembered EDNS version.

+[no]multiline
Print records like the SOA records in a verbose multi-line format
with human-readable comments. The default is to print each record
on a single line, to facilitate machine parsing of the dig output.

+[no]fail
Do not try the next server if you receive a SERVFAIL. The default
is to not try the next server which is the reverse of normal stub
resolver behavior.

+[no]besteffort
Attempt to display the contents of messages which are malformed.
The default is to not display malformed answers.

+[no]dnssec
Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO)
in the OPT record in the additional section of the query.

+[no]sigchase
Chase DNSSEC signature chains. Requires dig be compiled with
-DDIG_SIGCHASE.

+trusted-key=####
Specifies a file containing trusted keys to be used with +sigchase.

MULTIPLE QUERIES
The BIND 9 implementation of dig supports specifying multiple queries
on the command line (in addition to supporting the -f batch file
option). Each of those queries can be supplied with its own set of
flags, options and query options.

In this case, each query argument represent an individual query in the
command-line syntax described above. Each consists of any of the
standard options and flags, the name to be looked up, an optional query
type and class and any query options that should be applied to that
query.

A global set of query options, which should be applied to all queries,
can also be supplied. These global query options must precede the first
tuple of name, class, type, options, flags, and query options supplied
on the command line. Any global query options (except the +[no]cmd
option) can be overridden by a query-specific set of query options. For
example:

dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr

shows how dig could be used from the command line to make three
lookups: an ANY query for www.isc.org, a reverse lookup of 127.0.0.1
and a query for the NS records of isc.org. A global query option of +qr
is applied, so that dig shows the initial query it made for each
lookup. The final query has a local query option of +noqr which means
that dig will not print the initial query when it looks up the NS
records for isc.org.

IDN SUPPORT
If dig has been built with IDN (internationalized domain name) support,
it can accept and display non-ASCII domain names. dig appropriately
converts character encoding of domain name before sending a request to
DNS server or displaying a reply from the server. If you’d like to turn
off the IDN support for some reason, defines the IDN_DISABLE
environment variable. The IDN support is disabled if the variable is
set when dig runs.

FILES
/etc/resolv.conf

${HOME}/.digrc

SEE ALSO
host(1), named(8), dnssec-keygen(8), RFC1035.

BUGS
There are probably too many query options.

COPYRIGHT
Copyright (C) 2004-2008 Internet Systems Consortium, Inc. (”ISC”)
Copyright (C) 2000-2003 Internet Software Consortium.