gnustep/libs-base
0
0
Fork 0
mirror of https://github.com/gnustep/libs-base.git synced 2025-04-22 16:33:29 +00:00
Code Issues Projects Releases Packages Wiki Activity

Added some files I missed.

Browse source 
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/base/trunk@18992 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
Richard Frith-Macdonald 2004-03-31 19:29:50 +00:00
parent 8f8e4fbf8f
commit 9b1f0706a1
8 changed files with 1533 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

608
Tools/autogsdoc.1 Normal file
View file

@ -0,0 +1,608 @@
.\"autogsdoc(1) man page
.\"written by Adrian Robert <arobert@cogsci.ucsd.edu>
.\"
.\"Process this file with
.\"groff -man -Tascii autogsdoc.1
.\"
.TH AUTOGSDOC 1 "March 2004" GNUstep "GNUstep System Manual"
.SH NAME
autogsdoc \- GNUstep API documentation generator and XML\->HTML converter
.SH SYNOPSIS
.B autogsdoc
.RB [ -Files
.IR filename ]
.RB [ -GenerateHtml
.IR YES|no ]
.RB [ -Clean
.IR yes|NO ]
.RB [ -CleanTemplates
.IR yes|NO ]
.RB [ -IgnoreDependencies
.IR yes|NO ]
.RB [ -MakeDependencies
.IR yes|NO ]
.RB [ -ShowDependencies
.IR yes|NO ]
.RB [ -HeaderDirectory
.IR path ]
.RB [ -DocumentationDirectory
.IR path ]
.RB [ -Declared
.IR location ]
.RB [ -Project
.IR title ]
.RB [ -Standards
.IR yes|NO ]
.RB [ -DocumentAllInstanceVariables
.IR yes|NO ]
.RB [ -DocumentInstanceVariables
.IR YES|no ]
.RB [ -InstanceVariablesAtEnd
.IR yes|NO ]
.RB [ -ConstantsTemplate
.IR filename ]
.RB [ -FunctionsTemplate
.IR filename ]
.RB [ -MacrosTemplate
.IR filename ]
.RB [ -TypedefsTemplate
.IR filename ]
.RB [ -VariablesTemplate
.IR filename ]
.RB [ -SystemProjects
.IR string ]
.RB [ -LocalProjects
.IR string ]
.RB [ -Projects
.IR dictString ]
.RB [ -Verbose
.IR yes|NO ]
.RB [ -Warn
.IR yes|NO ]
.RB [ -WordMap
.IR dictString ]
.IR [ files ]
.SH DESCRIPTION
The autogsdoc tool is a command-line utility that helps developers produce
reference documentation for GNUstep APIs. It also enables developers to write
and maintain other documentation in XML and have it converted to HTML. In
detail, autogsdoc will:
.IP - 2
Extract special comments describing the public interfaces of classes,
categories, protocols, functions, and macros from Objective C source
code (header files and optionally source files) into GSDoc XML files.
.IP - 2
Convert GSDoc XML files, whether generated from source code or
written manually by developers, into HTML.
.IP - 2
Construct indices based on GSDoc XML file sets, and convert those
to HTML as well.
.P
The most common usage this is to run the command with one or more header file
names as arguments ... the tool will automatically parse corresponding source
files in the same directory as the headers (or the current directory, or the
directory specified using the DocumentationDirectory default), and produce
GSDoc and HTML files as output. For best results this mode should be run from
the directory containing the source files.
.P
GSDoc files may also be given directly in addition or by themselves, and will
be converted to HTML. See the GSDoc HTML documentation or the gsdoc(7) man
page for information on the GSDoc format.
.P
Finally, HTML files may be given on the command line. Cross-references
to other parts of code documentation found within them will be rewritten
based on what is found in the project currently.
.SH
SOURCE CODE MARKUP
.P
The source code parser will automatically produce GSDoc documents
listing the methods in the classes found in the source files, and it
will include text from specially formatted comments from the source
files.
.P
Any comment beginning with slash and
.I two
asterisks rather than the common slash and single asterisk, is taken to be
GSDoc markup, to be use as the description of the class or method following
it. This comment text is reformatted and then inserted into the output.
.RS 0
Where multiple comments are associated with the same item, they are joined
together with a line break (<br/>) between each if necessary.
.P
The tool can easily be used to document programs as well as libraries,
simply by giving it the name of the source file containing the main()
function of the program - it takes the special comments from that
function and handles them specially, inserting them as a section at
the end of the first chapter of the document (it creates the first
chapter if necessary).
.P
.B Options
are described in the section
.I Arguments and Defaults
below.
.SH
EXTRA MARKUP
.P
There are some cases where special extra processing is performed,
predominantly in the first comment found in the source file, from which
various chunks of GSDoc markup may be extracted and placed into appropriate
locations in the output document -
.IP "\fBAutogsdocSource:" 4
In any line where
.I AutogsdocSource:
is found, the remainder of the line is taken as a source file name to be used
instead of making the assumption that each .h file processed uses a .m file of
the same name. You may supply multiple
.I AutogsdocSource:
lines where a header file declares items which are defined in multiple source
files. If a file name is absolute, it is used just as supplied. If on the
other hand, it is a relative path, the software looks for the source file
first relative to the location of the header file, and if not found there,
relative to the current directory in which autogsdoc is running, and finally
relative to the directory specified by the
.I DocumentationDirectory
default.
.IP "\fB<abstract>" 4
An abstract of the content of the document ... placed in the head of the GSDoc
output.
.IP "\fB<author>" 4
A description of the author of the code - may be repeated to handle
the case where a document has multiple authors. Placed in the
head of the GSDoc output.
As an aid to readability of the source, some special additional
processing is performed related to the document author -
Any line of the form
.SM 'Author:
name <email-address>', or
.SM 'By:
name <email-address>', or
.SM 'Author:
name' or
.SM 'By:
name' will be recognised and converted to an
.I author
element, possibly containing an
.I email
element.
.IP "\fB<back>" 4
Placed in the GSDoc output just before the end of the body of the document -
intended to be used for appendices, index etc..
.IP "\fB<chapter>" 4
Placed immediately before any generated class documentation ...
intended to be used to provide overall description of how the
code being documented works. Any documentation for the main()
function of a program is inserted as a section at the end of this
chapter.
.IP "\fB<copy>" 4
Copyright of the content of the document ... placed in the head of the GSDoc
output. As an aid to readability of the source, some special additional
processing is performed - Any line of the form 'Copyright (C) text' will be
recognised and converted to a
.I copy
element.
.IP "\fB<date>" 4
Date of the revision of the document ... placed in the head
of the GSDoc output. If this is omitted the tool will try to
construct a value from the RCS Date tag (if available).
.IP "\fB<front>" 4
Inserted into the document at the start of the body ... intended
to provide for introduction or contents pages etc.
.IP "\fB<title>" 4
Title of the document ... placed in the head of the GSDoc output.
If this is omitted the tool will generate a (probably poor)
title of its own - so you should include this markup manually.
.IP "\fB<version>" 4
Version identifier of the document ... placed in the head
of the GSDoc output. If this is omitted the tool will try to
construct a value from the RCS Revision tag (if available).
.P
.B NB
The markup just described may be used within class, category, or protocol
documentation ... if so, it is extracted and wrapped round the rest of the
documentation for the class as the class's chapter. The rest of the class
documentation is normally inserted at the end of the chapter, but may instead
be substituted in in place of the <unit> pseudo-element within the <chapter>
element.
.SH
METHOD MARKUP
.P
In comments being used to provide text for a method description, the
following markup is removed from the text and handled specially -
.IP "\fB<init>" 4
The method is marked as being the designated initialiser for the class.
.IP "\fB<override-subclass>" 4
The method is marked as being one which subclasses must override
(e.g. an abstract method).
.IP "\fB<override-never>" 4
The method is marked as being one which subclasses should
.I NOT
override.
.IP "\fB<standards>" 4
The markup is removed from the description and placed
.I after
it in the GSDoc output - so that the method is described as
conforming (or not conforming) to the specified standards.
.SH
AUTOMATED MARKUP
.P
Generally, the text in comments is reformatted to standardise and
indent it nicely ... the reformatting is
.I not
performed on any text inside an <example> element. When the text is
reformatted, it is broken into whitespace separated
'words' which are then subjected to some extra processing ...
.IP "" 4
Certain well known constants such as YES, NO, and nil are enclosed in <code>
... </code> markup.
.IP "" 4
The names of method arguments within method descriptions are enclosed in
<var> ... </var> markup.
.IP "" 4
Method names (beginning with a plus or minus) are enclosed in <ref...>
... </ref> markup. E.g. "-init" (without the quotes) would be
wrapped in a GSDoc reference element to point to the init method of the
current class or, if only one known class had an init method, it would refer
to the method of that class. Note the fact that the method name must be
surrounded by whitespace to be recognized (though a comma, fullstop, or
semicolon at the end of the specifier will act like whitespace).
.IP "" 4
Method specifiers including class names (beginning and ending with square
brackets) are enclosed in <ref...> ... </ref> markup.
e.g. '[NSObject-init]', will create a reference to the init method of NSObject
(either the class proper, or any of its categories), while
'[(NSCopying)-copyWithZone:]', creates a reference to a method in the
NSCopying protocol. Note that no spaces must appear between the square
brackets in these specifiers. Protocol names are enclosed in round
brackets rather than the customary angle brackets, because GSDoc is an XML
language, and XML treats angle brackets specially.
.IP "" 4
Function names (ending with '()') other than 'main()' are enclosed in
<ref...> ... </ref> markup. E.g. "NSLogv()" (without the
quotes) would be wrapped in a GSDoc reference element to point to the
documentation of the NSLog function. Note the fact that the function
name must be surrounded by whitespace (though a comma, fullstop, or semicolon
at the end of the specifier will also act as a whitespace terminator).
.SH ARGUMENTS AND DEFAULTS
.P
The tool accepts certain user defaults (which can of course be supplied as
command-line arguments by prepending '-' before the default name and giving
the value afterwards, as in -Clean YES):
.IP "\fBClean" 4
If this boolean value is set to YES, then rather than generating
documentation, the tool removes all GSDoc files generated in the
project, and all html files generated from them (as well as any
which would be generated from GSDoc files listed explicitly),
and finally removes the project index file.
The only exception to this is that template GSDoc files (i.e. those
specified using "-ConstantsTemplate ...", "-FunctionsTemplate ..."
arguments etc) are not deleted unless the CleanTemplates flag is set.
.IP "\fBCleanTemplates" 4
This flag specifies whether template GSDoc files are to be removed
along with other files when the Clean option is specified.
The default is for them not to be removed ... since these templates
may have been produced manually and just had data inserted into them.
.IP "\fBConstantsTemplate" 4
Specify the name of a template document into which documentation
about constants should be inserted from all files in the project.
This is useful if constants in the source code are scattered around many
files, and you need to group them into one place.
You are responsible for ensuring that the basic template document
(into which individual constant documentation is inserted) contains
all the other information you want, but as a convenience autogsdoc
will generate a simple template (which you may then edit) for you
if the file does not exist.
Insertion takes place immediately before the
.I back
element (or if that does not exist, immediately before the end
of the
.I body
element) in the template.
.IP "\fBDeclared" 4
Specify where headers are to be documented as being found.
The actual name produced in the documentation is formed by appending
the last component of the header file name to the value of this
default.
If this default is not specified, the full name of the header file
(as supplied on the command line), with the HeaderDirectory
default prepended, is used.
A typical usage of this might be '"-Declared Foundation"'
when generating documentation for the GNUstep base library. This
would result in the documentation saying that NSString is declared
in 'Foundation/NSString.h'
.IP "\fBDocumentAllInstanceVariables" 4
This flag permits you to generate documentation for all instance
variables. Normally, only those explicitly declared 'public' or
'protected' will be documented.
.IP "\fBDocumentInstanceVariables" 4
This flag permits you to turn off documentation for instance variables
completely. Normally, explicitly declared 'public' or 'protected' instance
variables will be documented.
.IP "\fBInstanceVariablesAtEnd" 4
This flag, if set, directs the HTML generator to place instance variable
documentation at the end of the class, instead of the beginning. This is
useful if you use a lot of protected instance variables which are only going
to be of secondary interest to general users of the class.
.IP "\fBDocumentationDirectory" 4
May be used to specify the directory in which generated documentation
is to be placed. If this is not set, output is placed in the current
directory. This directory is also used as a last resort to locate
source files (not headers), and more importantly, it is used as the
.I first and only
resort to locate any .gsdoc files
that are passed in on the command line. Any path information given
for these files is
.B removed
and they are searched for in 'DocumentationDirectory' (even though they
may not have been autogenerated).
.IP "\fBFiles" 4
Specifies the name of a file containing a list of file names as
a property list array
.I (name1,name2,...)
format. If this is present, filenames in the program argument list are
ignored and the names in this file are used as the list of names to process.
.IP "\fBFunctionsTemplate" 4
Specify the name of a template document into which documentation
about functions should be inserted from all files in the project.
This is useful if function source code is scattered around many
files, and you need to group it into one place.
You are responsible for ensuring that the basic template document
(into which individual function documentation is inserted) contains
all the other information you want, but as a convenience autogsdoc
will generate a simple template (which you may then edit) for you
if the file does not exist.
Insertion takes place immediately before the
.I back
element (or if that does not exist, immediately before the end
of the
.I body
element) in the template.
.IP "\fBGenerateHtml" 4
May be used to specify if HTML output is to be generated.
Defaults to YES.
.IP "\fBHeaderDirectory" 4
May be used to specify the directory to be searched for header files.
When supplied, this value is prepended to relative header names,
otherwise the relative header names are interpreted relative to
the current directory.
Header files specified as absolute paths are not influenced by this
default.
.IP "\fBIgnoreDependencies" 4
A boolean value which may be used to specify that the program should
ignore file modification times and regenerate files anyway. Provided
for use in conjunction with the 'make' system, which is
expected to manage dependency checking itsself.
.IP "\fBLocalProjects" 4
This value is used to control the automatic inclusion of local
external projects into the indexing system for generation of
cross-references in final document output.
If set to 'None', then no local project references are done,
otherwise, the 'Local' GNUstep documentation directory is recursively
searched for files with a '.igsdoc' extension, and the
indexing information from those files is used.
The value of this string is also used to generate the filenames in
the cross reference ... if it is an empty string, the path to use
is assumed to be a file in the same directory where the igsdoc
file was found, otherwise it is used as a prefix to the name in
the index.
NB. Local projects with the same name as the project currently
being documented will
.I not
be included by this mechanism.
If you wish to include such projects, you must do so explicitly
using
.I "-Projects ..."
.IP "\fBMacrosTemplate" 4
Specify the name of a template document into which documentation
about macros should be inserted from all files in the project.
This is useful if macro code is scattered around many
files, and you need to group it into one place.
You are responsible for ensuring that the basic template document
(into which individual macro documentation is inserted) contains
all the other information you want, but as a convenience autogsdoc
will generate a simple template (which you may then edit) for you
if the file does not exist.
Insertion takes place immediately before the
.I back
element (or if that does not exist, immediately before the end
of the
.I body
element) in the template.
.IP "\fBMakeDependencies" 4
A filename to be used to output dependency information for make. This
will take the form of listing all header and source files known for
the project as dependencies of the project name (see
'Project').
.IP "\fBProject" 4
May be used to specify the name of this project ... determines the
name of the index reference file produced as part of the documentation
to provide information enabling other projects to cross-reference to
items in this project.
.IP "\fBProjects" 4
This value may be supplied as a dictionary containing the paths to
the igsdoc index/reference files used by external projects, along
with values to be used to map the filenames found in the indexes.
For example, if a project index (igsdoc) file says that the class
'Foo' is found in the file 'Foo', and the
path associated with that project index is '/usr/doc/proj',
Then generated html output may reference the class as being in
'/usr/doc/prj/Foo.html' . Note that a dictionary may be
given on the command line by using the standard PropertyList format
(not the XML format of OS X), using semicolons as line-separators, and
enclosing it in single quotes.
.IP "\fBShowDependencies" 4
A boolean value which may be used to specify that the program should
log which files are being regenerated because of their dependencies
on other files.
.IP "\fBStandards" 4
A boolean value used to specify whether the program should insert
information about standards complience into the documentation.
This should only be used when documenting the GNUstep libraries
and tools themselves as it assumes that the code being documented
is part of GNUstep and possibly complies with the OpenStep standard
or implements MacOS-X compatible methods.
.IP "\fBSystemProjects" 4
This value is used to control the automatic inclusion of system
external projects into the indexing system for generation of
cross-references in final document output.
If set to 'None', then no system project references are done,
otherwise, the 'System' GNUstep documentation directory is recursively
searched for files with a '.igsdoc' extension, and the
indexing information from those files is used.
The value of this string is also used to generate the filenames in
the cross reference ... if it is an empty string, the path to use
is assumed to be a file in the same directory where the igsdoc
file was found, otherwise it is used as a prefix to the name in
the index.
NB. System projects with the same name as the project currently
being documented will
.I not
be included by this mechanism.
If you wish to include such projects, you must do so explicitly
using
.I "-Projects ..."
.IP "\fBTypedefsTemplate" 4
Specify the name of a template document into which documentation
about typedefs should be inserted from all files in the project.
This is useful if typedef source code is scattered around many
files, and you need to group it into one place.
You are responsible for ensuring that the basic template document
(into which individual typedef documentation is inserted) contains
all the other information you want, but as a convenience autogsdoc
will generate a simple template (which you may then edit) for you
if the file does not exist.
Insertion takes place immediately before the
.I back
element (or if that does not exist, immediately before the end
of the
.I body
element) in the template.
.IP "\fBUp" 4
A string used to supply the name to be used in the 'up' link from
generated GSDoc documents. This should normally be the name of a
file which contains an index of the contents of a project.
If this is missing or set to an empty string, then no 'up' link
will be provided in the documents.
.IP "\fBVariablesTemplate" 4
Specify the name of a template document into which documentation
about variables should be inserted from all files in the project.
This is useful if variable source code is scattered around many
files, and you need to group it into one place.
You are responsible for ensuring that the basic template document
(into which individual variable documentation is inserted) contains
all the other information you want, but as a convenience autogsdoc
will generate a simple template (which you may then edit) for you
if the file does not exist.
Insertion takes place immediately before the
.I back
element (or if that does not exist, immediately before the end
of the
.I body
element) in the template.
.IP "\fBVerbose" 4
A boolean used to specify whether you want verbose debug/warning
output to be produced.
.IP "\fBWarn" 4
A boolean used to specify whether you want standard warning
output (e.g. report of undocumented methods) produced.
.IP "\fBWordMap" 4
This value is a dictionary used to map identifiers/keywords found
in the source files to other words. Generally you will not have
to use this, but it is sometimes helpful to avoid the parser being
confused by the use of C preprocessor macros. You can effectively
redefine the macro to something less confusing.
The value you map the identifier to must be one of -
Another identifier,
An empty string - the value is ignored,
Two slashes ('//') - the rest of the line is ignored.
Note that a dictionary may be given on the command line by using the
standard PropertyList format (not the XML format of OS X), using
semicolons as line-separators, and enclosing it in single quotes.
.SH INTER-DOCUMENT LINKAGE
.P
The 'Up' default is used to specify the name of a document which should be
used as the 'up' link for any other documents used. This name must not
include a path or extension. Generally, the document referred to by this
default should be a hand-edited GSDoc document which should have a
<em>back</em> section containing a project index. e.g.
.P
<?xml version="1.0"?>
.RS 0
<!DOCTYPE gsdoc PUBLIC "-//GNUstep//DTD gsdoc 1.0.1//EN"
.RS 0
"http://www.gnustep.org/gsdoc-1_0_1.xml">
.RS 0
<gsdoc base="index">
.RS 0
<head>
.RS 0
<title>My project reference</title>
.RS 0
<author name="my name"></author>
.RS 0
</head>
.RS 0
<body>
.RS 0
<chapter>
.RS 0
<heading>My project reference</heading>
.RS 0
</chapter>
.RS 0
<back>
.RS 0
<index scope="project" type="title" />
.RS 0
</back>
.RS 0
</body>
.RS 0
</gsdoc>
.RS 0
.P
.RS 0
.SH FILES
Source: .h, .m
.RS 0
GSDoc: .gsdoc
.RS 0
Index: .igsdoc
.RS 0
HTML: .html
.SH BUGS
Several GSDoc elements are not rendered properly into HTML yet. These
are: <prjref>, <EOEntity>, <EOModel>.
.SH DIAGNOSTICS
.P
Error messages and warnings can come from each of the stages of the pipeline:
top-level control, source parsing, GSDoc parsing, and indexing.
.SH SEE ALSO
.P
gsdoc(7), GNUstep(7)
.P
.SH HISTORY
Autogsdoc combined the capabilities of two earlier
tools, 'autodoc' and 'gsdoc', which performed the source->GSDoc and
GSDoc->HTML translations respectively. These earlier tools and the GSDoc
format were developed for GNUstep based on the earlier GDML SGML language.
.P
This manual page first appeared in gnustep-base 1.9.2 (March 2004).
.P
.SH AUTHORS
.B autogsdoc
was written by Richard Frith-McDonald <rfm@gnu.org>
.P
This manual page added by Adrian Robert <arobert@cogsci.ucsd.edu>.

43
Tools/cvtenc.1 Normal file
View file

@ -0,0 +1,43 @@
.TH CVTENC "1" "February 2004" "GNUstep" "GNUstep System Manual"
.SH NAME
cvtenc \- file encoding converter
.SH SYNOPSIS
.B cvtenc
[\fB-Encoding\fR \fIencoding\fR]
[\fB-EscapeIn\fR \fIyes|NO\fR]
[\fB-EscapeOut\fR \fIyes|NO\fR]
\fIfilename\fR
.SH DESCRIPTION
.P
Converts a file encoded in a specified or default non-unicode encoding to
unicode, or, if the file is already in unicode, converts it to a specified
or default non-unicode encoding. The converted text is printed to standard
out.
.SH OPTIONS
.IP "\fB\-Encoding\fR \fI encoding\fR" 4
Specify non-unicode encoding to be used. The direction of conversion depends
on whether the file given as input is recognized as unicode (from the higher
order bytes). To get a list of available encodings, enter "list" for the
encoding. If this is not specified, the default encoding for the current
locale is used.
.IP "\fB\-EscapeIn\fR \fIYES|NO\fR" 4
Specify '-EscapeIn YES' (the default is 'NO') to parse the input for \\u
escape sequences (as in property lists).
.IP "\fB\-EscapeOut\fR \fIYES|NO\fR" 4
Specify '-EscapeOut YES' (the default is 'NO') to generate \\u escape
sequences (as in property lists) in the output. Note, this might produce
unexpected results for some encodings.
.SH HISTORY
.RS 0
Written in 2002.
.P
This manual page first appeared in gnustep-base 1.9.2 (March 2004).
.P
.SH AUTHORS
.B cvtenc
was written by Richard Frith-McDonald <rfm@gnu.org>

151
Tools/defaults.1 Normal file
View file

@ -0,0 +1,151 @@
.TH DEFAULTS "1" "February 2004" "GNUstep" "GNUstep System Manual"
.SH NAME
defaults - read or modify GNUstep user defaults
.SH SYNOPSIS
.B defaults [ action ]
.SH DESCRIPTION
The 'defaults' command lets you to read and modify a user's defaults.
.PP
This program replaces the old NeXTstep style dread, dwrite, and dremove
programs.
.PP
If you have access to another user's defaults database, you may include
\&'-u username' before any other options to use that user's database rather
than your own.
.PP
defaults read [ domain [ key] ]
.IP
read the named default from the specified domain.
If no 'key' is given - read all defaults from the domain.
If no 'domain' is given - read all defaults from all domains.
.PP
defaults readkey key
.IP
read the named default from all domains.
.PP
defaults write domain key value
.IP
write 'value' as default 'key' in the specified domain.
\&'value' must be a property list in single quotes.
.PP
defaults write domain dictionary
.IP
write 'dictionary' as a replacement for the specified domain.
\&'dictionary' must be a property list in single quotes.
.PP
defaults write
.IP
reads standard input for defaults in the format produced by
\&'defaults read' and writes them to the database.
.PP
defaults delete [ domain [ key] ]
.IP
remove the specified default(s) from the domain.
If no 'key' is given - delete the entire domain.
.PP
defaults delete
.IP
read standard input for a series of lines containing pairs of domains
and keys for defaults to be deleted.
.PP
defaults domains
.IP
lists the domains in the database (one per line)
.PP
defaults find word
.IP
searches domain names, default names, and default value strings for
those equal to the specified word and lists them on standard output.
.PP
defaults plist
.IP
output some information about property lists
.PP
defaults help
.IP
list options fo the defaults command.
.PP
This program replaces the old NeXTstep style dread, dwrite, and dremove
programs.
.PP
If you have access to another user's defaults database, you may include
\&'-u username' before any other options to use that user's database rather
than your own.
.PP
defaults read [ domain [ key] ]
.IP
read the named default from the specified domain.
If no 'key' is given - read all defaults from the domain.
If no 'domain' is given - read all defaults from all domains.
.PP
defaults readkey key
.IP
read the named default from all domains.
.PP
defaults write domain key value
.IP
write 'value' as default 'key' in the specified domain.
\&'value' must be a property list in single quotes.
.PP
defaults write domain dictionary
.IP
write 'dictionary' as a replacement for the specified domain.
\&'dictionary' must be a property list in single quotes.
.PP
defaults write
.IP
reads standard input for defaults in the format produced by
\&'defaults read' and writes them to the database.
.PP
defaults delete [ domain [ key] ]
.IP
remove the specified default(s) from the domain.
If no 'key' is given - delete the entire domain.
.PP
defaults delete
.IP
read standard input for a series of lines containing pairs of domains
and keys for defaults to be deleted.
.PP
defaults domains
.IP
lists the domains in the database (one per line)
.PP
defaults find word
.IP
searches domain names, default names, and default value strings for
those equal to the specified word and lists them on standard output.
.PP
defaults plist
.IP
output some information about property lists
.PP
defaults help
.IP
list options for the defaults command.
.SH FILES
.IT ~/GNUstep/Defaults/.GNUstepDefaults
holds defaults for a user
.SH BUGS
None known.
.SH DIAGNOSTICS
.P
Hopefully self-explanatory.
.P
.SH HISTORY
The 'defaults' command appeared in OpenStep and combined the capabilities of
the earlier NeXTstep commands 'dread', 'dwrite', and 'dremove'.
.RS 0
The GNUstep version was written in 1998.
.P
This manual page first appeared in gnustep-base 1.9.2 (March 2004).
.P
.SH AUTHORS
.B defaults
was written by Richard Frith-McDonald <rfm@gnu.org>

559
Tools/gsdoc-1_0_1.dtd Normal file
View file

@ -0,0 +1,559 @@
<!--
XML Document Type Definition for GNUstep Documentation Markup
Language (gsdoc).
Written by Richard Frith-Macdonald
Based on GDML by 1997 Yoo C. Chung
This 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 of the License, or (at your option) any later
version.
This document 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 this software; if not, write to the
Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
02139, USA.
-->
<!--
gsdoc is an XML language - Typical usage:
<?xml version="1.0"?>
<!DOCTYPE gsdoc PUBLIC "-//GNUstep//DTD gsdoc 1.0.1//EN"
"http://www.gnustep.org/gsdoc.xml">
<gsdoc base="myDocName">
</gsdoc>
-->
<!--***** Character entities. *****-->
<!-- General purpose characters for gsdoc. -->
<!ENTITY copy "&#169;"> <!-- copyright symbol -->
<!ENTITY tm "&#174;"> <!-- trademark symbol -->
<!ENTITY reg "&#174;">
<!ENTITY dots "&#8230;"> <!-- ellipsis (...) -->
<!ENTITY nbsp "&#160;"> <!-- non breakable space -->
<!ENTITY amp "&#38;#38;"> <!-- ampersand -->
<!ENTITY apos "&#39;"> <!-- apos -->
<!ENTITY quot "&#34;"> <!-- quotation mark (") -->
<!ENTITY lt "&#38;#60;"> <!-- lesser than symbol -->
<!ENTITY gt "&#62;"> <!-- greater than symbol -->
<!--***** Entity declarations. *****-->
<!-- Boolean values for attributes -->
<!ENTITY % boolean "(yes|no)">
<!-- Entity for phrase elements. -->
<!ENTITY % phrase "var | ivar | em | code | strong | file | site">
<!-- Entity for cross references. -->
<!ENTITY % xref "ref | uref | url | email | prjref">
<!-- Entity for anchors. -->
<!ENTITY % anchor "label | entry">
<!-- Entity for simple text level elements. -->
<!ENTITY % text "#PCDATA | %xref; | %anchor; | %phrase; | footnote | br">
<!-- Entity for list elements. -->
<!ENTITY % list "list | enum | deflist | qalist | dictionary">
<!-- Entity for block level elements. -->
<!ENTITY % block "%text; | %list; | p | example | embed | index">
<!-- Entity for definition elements and blocks. -->
<!ENTITY % defblock "%text; | %list; | heading | p | example | embed | index | class | category | protocol | function | macro | type | variable | constant | EOModel | EOEntity">
<!--**********-->
<!-- Used for describing something. -->
<!ELEMENT desc (%block;)*>
<!-- A footnote. -->
<!ELEMENT footnote (%text;)*>
<!--***** Phrase elements. *****-->
<!-- The content is a metasyntactic variable or argument name. -->
<!ELEMENT var (%text;)*>
<!-- The content is a metasyntactic ivariable name. -->
<!ELEMENT ivar (%text;)*>
<!-- Emphasize the content. -->
<!ELEMENT em (%text;)*>
<!-- The content is too important that simple emphasizing isn't
enough. -->
<!ELEMENT strong (%text;)*>
<!-- The content is either a name for code (e.g. class names), or a
relatively short code fragment. -->
<!ELEMENT code (%text;)*>
<!-- The content is a file name. -->
<!ELEMENT file (#PCDATA)*>
<!-- The content is a fully qualified domain name on the Internet. -->
<!ELEMENT site (#PCDATA)*>
<!--***** List elements. *****-->
<!-- An item in a list. -->
<!ELEMENT item (%block;)*>
<!-- An enumerated list. -->
<!ELEMENT enum (item+)>
<!-- A ordinary, unnumbered list. -->
<!ELEMENT list (item+)>
<!-- A term to defined in a definition list. -->
<!ELEMENT term (%text;)*>
<!-- A definition list. -->
<!ELEMENT deflist (term, desc)+>
<!-- A question for a question and answer list. -->
<!ELEMENT question (%text;)*>
<!-- An answer for a question and answer list. -->
<!ELEMENT answer (%block;)*>
<!-- A question and answer list. -->
<!ELEMENT qalist (question, answer)+>
<!--**********-->
<!--***** Cross references. *****-->
<!-- A reference.
ID of the reference.
TYPE of reference, if implied, a reference to a label.
CLASS specific class for a method, may be one of the following formats -
classname, classname(categoryname), (protocolname)
-->
<!ELEMENT ref (%text;)*>
<!ATTLIST ref
id CDATA #REQUIRED
type (class|category|protocol|method|ivariable|function|type|macro|variable|constant|label|EOModel|EOEntity|tool) "label"
class CDATA #IMPLIED
>
<!-- An e-mail address. -->
<!ELEMENT email (%text;)*>
<!ATTLIST email
address CDATA #IMPLIED
>
<!-- A URL. -->
<!ELEMENT url EMPTY>
<!ATTLIST url
url CDATA #IMPLIED
>
<!-- A reference to a URL.
The text contained appears in the output.
-->
<!ELEMENT uref (%text;)*>
<!ATTLIST uref
url CDATA #REQUIRED
>
<!-- A reference to a project.
The text contained appears in the output.
-->
<!ELEMENT prjref (%text;)*>
<!ATTLIST prjref
prjname CDATA #IMPLIED
file CDATA #IMPLIED
>
<!--***** Anchors. *****-->
<!-- An anchor for a general reference.
The text contained appears in the output.
If the id attribute is omitted, the text is used in its place.
-->
<!ELEMENT label (%text;)*>
<!ATTLIST label
id CDATA #IMPLIED
>
<!-- An entry for the general index.
The text that is contained appears in the index, and never in
the text itself.
If the id attribute is omitted, the text is used in its place.
-->
<!ELEMENT entry (%text;)*>
<!ATTLIST entry
id CDATA #IMPLIED
>
<!-- Entity for standard elements. -->
<!ELEMENT GNUstep EMPTY>
<!ELEMENT OpenStep EMPTY>
<!ELEMENT NotOpenStep EMPTY>
<!ELEMENT MacOS-X EMPTY>
<!ELEMENT NotMacOS-X EMPTY>
<!-- A standard that something is or isn't compliant with. -->
<!ENTITY % standard "GNUstep | OpenStep | NotOpenStep | MacOS-X | NotMacOS-X">
<!ELEMENT standards (%standard;)*>
<!--***** Argument elements. *****-->
<!-- An argument. -->
<!ELEMENT arg (#PCDATA)*>
<!ATTLIST arg
type CDATA #IMPLIED
>
<!-- Denotes that the rest of the arguments is a variable list,
like in printf().
-->
<!ELEMENT vararg EMPTY>
<!--***** Method elements. *****-->
<!-- A component for a method selector. -->
<!ELEMENT sel (#PCDATA)*>
<!-- A method. If there is no DESC, it is understood that the element
is used to override some information from the same method in the
superclass.
If factory not set, instance method
-->
<!ELEMENT method (((sel, arg?), (sel, arg)*, vararg?), desc?, standards?)>
<!ATTLIST method
type CDATA #IMPLIED
factory %boolean; "no"
init %boolean; "no"
override (subclass|never) #IMPLIED
>
<!--***** Elements for definitions of classes, functions, etc. *****-->
<!-- Show what header file something lives in. -->
<!ELEMENT declared (#PCDATA)*>
<!-- A macro definition. -->
<!ELEMENT macro ((arg*, vararg?), declared?, desc?, standards?)>
<!ATTLIST macro
name CDATA #REQUIRED
>
<!-- A type definition. -->
<!ELEMENT type (declared?, desc?, standards?)>
<!ATTLIST type
name CDATA #REQUIRED
type CDATA #REQUIRED
>
<!-- Variable definition.
VALUE may be set for a constant or a default value
-->
<!ELEMENT variable (declared?, desc?, standards?)>
<!ATTLIST variable
name CDATA #REQUIRED
type CDATA #REQUIRED
value CDATA #IMPLIED
>
<!-- Ivariable definition.
-->
<!ELEMENT ivariable (desc?, standards?)>
<!ATTLIST ivariable
name CDATA #REQUIRED
type CDATA #REQUIRED
validity (public|protected|private) "public"
>
<!-- Constant definition.
VALUE may be set for a constant or a default value
-->
<!ELEMENT constant (declared?, desc?, standards?)>
<!ATTLIST constant
name CDATA #REQUIRED
type CDATA #REQUIRED
value CDATA #IMPLIED
role (except|defaults|notify|key) #IMPLIED
>
<!-- A function definition. -->
<!ELEMENT function ((arg*, vararg?), declared?, desc?, standards?)>
<!ATTLIST function
name CDATA #REQUIRED
type CDATA #REQUIRED
>
<!-- Protocol definition. -->
<!ELEMENT protocol (declared?, conform*, desc?, method*, standards?)>
<!ATTLIST protocol
name CDATA #REQUIRED
>
<!-- Category definition. -->
<!ELEMENT category (declared?, conform*, desc?, method*, standards?)>
<!ATTLIST category
name CDATA #REQUIRED
class CDATA #REQUIRED
>
<!-- Show a protocol a class conforms to. -->
<!ELEMENT conform (#PCDATA)*>
<!ELEMENT class (declared?, conform*, desc?, ivariable*, method*, standards?)>
<!ATTLIST class
name CDATA #REQUIRED
super CDATA #IMPLIED
>
<!--***** Elements for definitions of EOModels, etc. *****-->
<!-- a dictionary Item. -->
<!ELEMENT dictionaryItem (%block;)*>
<!ATTLIST dictionaryItem
key CDATA #REQUIRED
value CDATA #IMPLIED
>
<!-- a dictionary -->
<!ELEMENT dictionary (dictionaryItem+)>
<!ELEMENT EOConnectionDictionary (dictionaryItem+)>
<!ELEMENT EOUserDictionary (dictionaryItem+)>
<!--***** Elements for definitions of EOModels, etc. *****-->
<!-- EORelationshipComponent -->
<!ELEMENT EORelationshipComponent (EORelationshipComponent*)>
<!ATTLIST EORelationshipComponent
definition CDATA #REQUIRED
>
<!-- EOJoin -->
<!ELEMENT EOJoin (desc?)>
<!ATTLIST EOJoin
relationshipName CDATA #IMPLIED
joinOperator CDATA #REQUIRED
joinSemantic CDATA #REQUIRED
sourceAttribute CDATA #REQUIRED
destinationAttribute CDATA #REQUIRED
>
<!-- EORelationship -->
<!ELEMENT EORelationship ((EORelationshipComponent | (EOJoin*)), EOUserDictionary?, desc?)>
<!ATTLIST EORelationship
entityName CDATA #REQUIRED
destinationEntityName CDATA #REQUIRED
name CDATA #REQUIRED
isToMany CDATA #IMPLIED
>
<!-- EOAttributeRef -->
<!ELEMENT EOAttributeRef EMPTY>
<!ATTLIST EOAttributeRef
name CDATA #REQUIRED
>
<!-- EOPrimaryKeyAttributes -->
<!ELEMENT EOPrimaryKeyAttributes (EOAttributeRef+)>
<!-- EOClassProperties -->
<!ELEMENT EOClassProperties ((EOAttributeRef)+)>
<!-- EOAttributesUsedForLocking -->
<!ELEMENT EOAttributesUsedForLocking (EOAttributeRef+)>
<!-- EOAttribute -->
<!ELEMENT EOAttribute (EOUserDictionary?, desc?)>
<!ATTLIST EOAttribute
columnName CDATA #IMPLIED
definition CDATA #IMPLIED
externalType CDATA #IMPLIED
name CDATA #REQUIRED
valueClassName CDATA #IMPLIED
valueType CDATA #IMPLIED
entityName CDATA #IMPLIED
isReadOnly CDATA #IMPLIED
isDerived CDATA #IMPLIED
isFlattened CDATA #IMPLIED
>
<!-- EOEntity -->
<!ELEMENT EOEntity (EOAttribute*, EOAttributesUsedForLocking?, EOClassProperties?, EOPrimaryKeyAttributes?, EORelationship*, EOUserDictionary?, desc?)>
<!ATTLIST EOEntity
name CDATA #REQUIRED
externalName CDATA #IMPLIED
className CDATA #IMPLIED
modelName CDATA #IMPLIED
isReadOnly CDATA #IMPLIED
>
<!-- EOModel -->
<!ELEMENT EOModel (EOConnectionDictionary?, (EOEntity+ | list), EOUserDictionary?, desc?)>
<!ATTLIST EOModel
name CDATA #REQUIRED
version CDATA #IMPLIED
adaptorName CDATA #REQUIRED
adaptorClassName CDATA #REQUIRED
>
<!--***** Elements for ordinary block level elements. *****-->
<!-- A line break. -->
<!ELEMENT br EMPTY>
<!-- A paragraph. -->
<!ELEMENT p (%text;)*>
<!-- An example. -->
<!ELEMENT example (#PCDATA)*>
<!ATTLIST example
caption CDATA #IMPLIED
>
<!-- An embedded object. If it is of a type that the SGML processor
cannot handle, then use the content, which is ignored otherwise.
refer - method of referring to object (default is file)
src - the reference to the object
type - Internet media type of the objec
title - optional title describing object
-->
<!ELEMENT embed (%block;)*>
<!ATTLIST embed
refer (file|url) #IMPLIED
src CDATA #REQUIRED
type CDATA #IMPLIED
title CDATA #IMPLIED
>
<!--***** Elements for document structure such as chapters. *****-->
<!-- A heading for chapters, sections, ... -->
<!ELEMENT heading (%text;)*>
<!-- A subsubsection. -->
<!ELEMENT subsubsect (%defblock;)*>
<!ATTLIST subsubsect
id CDATA #IMPLIED
>
<!-- A subsection. -->
<!ELEMENT subsect (%defblock; | subsubsect)*>
<!ATTLIST subsect
id CDATA #IMPLIED
>
<!-- A section. -->
<!ELEMENT section (%defblock; | subsect)*>
<!ATTLIST section
id CDATA #IMPLIED
>
<!-- A chapter. -->
<!ELEMENT chapter (%defblock; | section)*>
<!ATTLIST chapter
id CDATA #IMPLIED
>
<!--***** Elements that make searching for things easier. *****-->
<!-- Table of contents. -->
<!ELEMENT contents EMPTY>
<!-- Index ... generates an index of the specified type of elements.
'scope' determines whether the index is generated for the current file
or for the whole of the current project, or for everything the software
can find (global) ... if the document is processed in a standalone manner,
the scope if always file. For method or ivariable indexing, if the index
is inside a class, protocol, or category, only indexes for that unit
should be generated.
'type' determines the type of entry listed in the index. The 'title'
type really only makes sense for a project scope index as it produces
a list of the files in the project (by title).
-->
<!ELEMENT index EMPTY>
<!ATTLIST index
type (class | category | protocol | method | ivariable | function | type | macro | variable | constant | EOModel | EOEntity | label | title | tool) "label"
scope (file | project | global) "file"
style ( normal | bare ) "normal"
target CDATA #IMPLIED
>
<!--***** Elements that describe the document itself. *****-->
<!-- Copyright of the document. -->
<!ELEMENT copy (%text;)*>
<!-- An abstract. -->
<!ELEMENT abstract (%text;)*>
<!-- The version of the document. -->
<!ELEMENT version (%text;)*>
<!-- The date the document was written. -->
<!ELEMENT date (%text;)*>
<!-- An author. -->
<!ELEMENT author (email?, url?, desc?)>
<!ATTLIST author
name CDATA #REQUIRED
>
<!-- The title of the document. -->
<!ELEMENT title (%text;)*>
<!--***** The topmost structures for the document body. *****-->
<!-- Unnumbered parts appearing in the front, such as a preface. -->
<!ELEMENT front (contents?, chapter*)>
<!-- Unnumbered parts appearing in the back, such as an afterword and/or
indices.
-->
<!ELEMENT back (chapter*, index*)>
<!--***** The topmost structures for the document. *****-->
<!-- The head containing general information about the document. -->
<!ELEMENT head (title, author*, version?, date?, abstract?, copy?)>
<!-- The main part of the document. -->
<!ELEMENT body (front?, chapter+, back?)>
<!--**********-->
<!-- The entire document. -->
<!ELEMENT gsdoc (head, body)>
<!ATTLIST gsdoc
base CDATA #IMPLIED
next CDATA #IMPLIED
prev CDATA #IMPLIED
up CDATA #IMPLIED
stylesheeturl CDATA #IMPLIED
>

49
Tools/gsdoc.7 Normal file
View file

@ -0,0 +1,49 @@
.\"gsdoc(1) man page
.\"written by Adrian Robert <arobert@cogsci.ucsd.edu>
.\"
.\"Process this file with
.\"groff -man -Tascii gsdoc.7
.\"
.TH GSDOC 1 "March 2004" GNUstep "GNUstep System Manual"
.SH NAME
GSDoc \- GNUstep XML documentation format
.SH DESCRIPTION
GSDoc is an XML language designed specifically for writing documentation for
the GNUstep project. In practice, that means that it is designed for writing
about software, and in particular, for writing about Objective-C classes.
.SH DEFINITION
The GSDoc markup language is defined by an SGML DTD, that specifies the tags
that may be used in marking up a GSDoc document, and how and where those tags
may be placed. The reader is encouraged to consult the DTD directly on any
points that the other documentation leaves unclear. The DTD is stored under
\fI$GNUSTEP_ROOT/System/Library/DTDs\fR in a standard GNUstep installation.
.SH USAGE
GSDoc may be written by hand, but it is primarily autogenerated from
Objective-C source files by a tool called \fIautogsdoc\fR.
See the man page for that tool for more information. This tool also converts
GSDoc into HTML for viewing. In the future it is planned to convert the XML
into HTML, texinfo, man page, and other formats using XSLT.
.SH OTHER DOCUMENTATION
The primary documentation source for GSDoc is the GNUstep system HTML
documentation, under the Tools section. In a standard GNUstep installation
this should be found under
\fI$GNUSTEP_ROOT/System/Library/Documentation/Developer/Tools\fR.
.SH SEE ALSO
.P
autogsdoc(1), GNUstep(7)
.P
.SH HISTORY
The GSDoc format was developed for GNUstep based on the earlier GDML SGML
language.
.P
This manual page first appeared in gnustep-base 1.9.2 (March 2004).
.P
.SH AUTHORS
.B gsdoc
was defined by Richard Frith-McDonald <rfm@gnu.org>

67
Tools/pldes.1 Normal file
View file

@ -0,0 +1,67 @@
.\"property list tools man page
.\"written by Adrian Robert (arobert@cogsci.ucsd.edu)
.\"
.\"Process this file with
.\"groff -man -Tascii gdnc.1
.\"
.TH PLDES 1 "August 2003" GNUstep "GNUstep System Manual"
.SH NAME
pldes, plser, plmerge, plparse, pl2link \- property list tools
.SH SYNOPSIS
.nf
.BI "pldes " "filename(s)"
.nl
.BI "plser " "filename(s)"
.nl
.BI "plmerge [ " "destination-file" " ] [ " "input-file(s)" " ]"
.nl
.BI "plparse " "filename(s)"
.nl
.BI "pl2link " "input-file" " [ " "destination-file" " ]"
.nl
.SH DESCRIPTION
.P
Property lists in GNUstep are hierarchical lists of values or attribute-value
pairs. Programmatically they are represented by instances of the NSString,
NSData, NSArray, or NSDictionary (most common) class (which may contain other
instances of such classes). These instances can be serialized as binary
objects to form a persistent representation. In addition, there are two
alternative human-readable representations. The first, utilized in NeXTstep
and OpenStep, utilizes a text format with equals signs expressing
attribute-value bindings and set braces expressing hierarchical organization.
The second, often (uninformatively) referred to as "plist" format, is in XML
and is used by Mac OS X. The tools described here are utilities for
manipulating the various persistent property list representations as files.
.IP "\fBpldes\fR \fIfilename(s)\fR" 4
Converts a binary serialised property list (class instance) to a text
representation.
.IP "\fBplser\fR \fIfilename(s)\fR" 4
Converts a text representation of a property list to a binary serialized
representation.
.IP "\fBplmerge\fR [ \fIdestination-file\fR ] [ \fIinput-file(s)\fR ]" 4
Merges text property lists into a single property list
.IP "\fBplparse\fR \fIfilename(s)\fR" 4
Checks that each file contains a valid text representation of a property list.
.IP "\fBpl2link\fR \fIinput-file\fR [ \fIdestination-file\fR ]" 4
Produces a desktop link file for KDE and Gnome for the given text
representation of a property list.
.PP
.SH SEE ALSO
defaults(1)
.SH HISTORY
Written 1999-2000.
.PP
This manual page first appeared in gnustep-base 1.9.2 (March 2004).
.P
.SH AUTHORS
.B pldes, plparse, plser
were written by Richard Frith-McDonald <rfm@gnu.org>.
.PP
.B plmerge
was written by Jonathan Gapen <jagapen@whitewater.chem.wisc.edu>.
.PP
.B pl2link
was written by Fred Kiefer <FredKiefer@gmx.de>.

33
Tools/sfparse.1 Normal file
View file

@ -0,0 +1,33 @@
.TH SFPARSE "1" "February 2004" "GNUstep" "GNUstep System Manual"
.SH NAME
sfparse \- string file parse
.SH SYNOPSIS
.B sfparse
[ \fI--utf8\fR | \fI--unicode\fR ] \fIfilename\fR
.SH DESCRIPTION
.P
This tool has two different functions. When invoked with just a filename as
argument, it checks that a file is a valid strings-file, which basically
amounts to seeing whether the file is in proper serialized NSDictionary format
(type "\fIdefaults plist\fR" for info on this).
.P
On the other hand, if one of the two options is given, no such checking is
performed, but the file IS converted into the named encoding.
.SH OPTIONS
.P
\fB\-\-unicode\fR - convert an ASCII or UTF8 file to Unicode
.P
\fB\-\-utf8\fR - convert an ASCII or Unicode to UTF8
.SH HISTORY
.RS 0
Written in 1999.
.P
This manual page first appeared in gnustep-base 1.9.2 (March 2004).
.P
.SH AUTHORS
.B sfparse
was written by Richard Frith-McDonald <rfm@gnu.org>

23
Tools/xmlparse.1 Normal file
View file

@ -0,0 +1,23 @@
.TH XMLPARSE "1" "February 2004" "GNUstep" "GNUstep System Manual"
.SH NAME
xmlparse \- error-check and validate XML documents
.SH SYNOPSIS
.B xmlparse
\fIfilename\fR
.SH DESCRIPTION
.P
Parses the given file, validating it against its DTD if found. Prints
messages about any errors, otherwise returns silently. (Value 0 is always
returned in any case.) The parse of the file is discarded.
.SH HISTORY
.RS 0
Written in 2003.
.P
This manual page first appeared in gnustep-base 1.9.2 (March 2004).
.P
.SH AUTHORS
.B xmlparse
was written by Richard Frith-McDonald <rfm@gnu.org>