INN commit: trunk/doc/pod (10 files)
INN Commit
rra at isc.org
Sun Jul 31 20:16:08 UTC 2016
Date: Sunday, July 31, 2016 @ 13:16:07
Author: iulius
Revision: 10041
Enforce the "double space" rule after a final dot
Modified:
trunk/doc/pod/hook-perl.pod
trunk/doc/pod/hook-python.pod
trunk/doc/pod/inn.conf.pod
trunk/doc/pod/innfeed.pod
trunk/doc/pod/innxmit.pod
trunk/doc/pod/libinnhist.pod
trunk/doc/pod/list.pod
trunk/doc/pod/ovdb.pod
trunk/doc/pod/storage.conf.pod
trunk/doc/pod/tst.pod
------------------+
hook-perl.pod | 28 ++++++++++++++--------------
hook-python.pod | 2 +-
inn.conf.pod | 6 +++---
innfeed.pod | 2 +-
innxmit.pod | 2 +-
libinnhist.pod | 44 ++++++++++++++++++++++----------------------
list.pod | 4 ++--
ovdb.pod | 6 +++---
storage.conf.pod | 2 +-
tst.pod | 18 +++++++++---------
10 files changed, 57 insertions(+), 57 deletions(-)
Modified: hook-perl.pod
===================================================================
--- hook-perl.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ hook-perl.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -418,18 +418,18 @@
perl_auth: "/path/to/script/auth1.pl"
The file given as argument to perl_auth should contain the same
-procedures as before. The global hash %attributes remains the same,
+procedures as before. The global hash %attributes remains the same,
except for the removal of the "type" entry which is no longer needed
in this modification and the addition of several new entries (port,
-intipaddr, intport) described below. The return array now only
+intipaddr, intport) described below. The return array now only
contains either two or three elements, the first of which is the NNTP
-return code. The second is an error string which is passed to the
+return code. The second is an error string which is passed to the
client if the error code indicates that the authentication attempt has
-failed. This allows a specific error message to be generated by the
-perl script in place of "Authentication failed". An optional third
+failed. This allows a specific error message to be generated by the
+perl script in place of "Authentication failed". An optional third
return element if present will be used to match the connection with
the users: parameter in access groups and will also be the username
-logged. If this element is absent, the username supplied by the client
+logged. If this element is absent, the username supplied by the client
during authentication will be used as was the previous behavior.
The perl_access parameter (described below) is also new; it allows the
@@ -469,7 +469,7 @@
If the processing of readers.conf requires that a perl_auth: statement
be used for authentication, Perl is loaded (if it has yet to be) and
the file given as argument to the perl_auth: parameter is loaded as
-well. If a Perl function auth_init() is defined by that file, it is called
+well. If a Perl function auth_init() is defined by that file, it is called
immediately after the file is loaded. It takes no arguments and returns
nothing.
@@ -515,15 +515,15 @@
=head1 Dynamic Generation of Access Groups
A Perl script may be used to dynamically generate an access group
-which is then used to determine the access rights of the client. This
+which is then used to determine the access rights of the client. This
occurs whenever the perl_access: is specified in an auth group which
-has successfully matched the client. Only one perl_access:
-statement is allowed in an auth group. This parameter should not be
+has successfully matched the client. Only one perl_access:
+statement is allowed in an auth group. This parameter should not be
mixed with a python_access: statement in the same auth group.
When a perl_access: parameter is encountered, Perl is loaded (if it
has yet to be) and the file given as argument is loaded as
-well. Provided the file loads without errors, and a Perl function
+well. Provided the file loads without errors, and a Perl function
access() is defined, access() will then be called. access() takes no
arguments, but it has access to a global hash %attributes which
contains information about the connection as follows:
@@ -563,8 +563,8 @@
return %return_hash;
}
-Note that both the keys and values are quoted strings. These values
-are to be returned to a C program and must be quoted strings. For
+Note that both the keys and values are quoted strings. These values
+are to be returned to a C program and must be quoted strings. For
values containing one or more spaces, it is not necessary to include
extra quotes inside the string.
@@ -573,7 +573,7 @@
* which is equivalent to leaving the parameter out). The group created
with the values returned from the Perl script is the only one
considered when nnrpd attempts to find an access group matching the
-connection. If a users: parameter is included and it doesn't match the
+connection. If a users: parameter is included and it doesn't match the
connection, then the client will be denied access since there are no
other access groups which could match the connection.
Modified: hook-python.pod
===================================================================
--- hook-python.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ hook-python.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -663,7 +663,7 @@
it, to ensure there are no obvious errors. One typo can ruin your whole
filter. A dummy F<nnrpd.py> module is provided to facilitate testing outside
the server. It is not actually used by B<nnrpd> but provides the same set
-of functions as built-in B<nnrpd> module. This stub module may be used
+of functions as built-in B<nnrpd> module. This stub module may be used
when debugging your own module. To test, change into your filter directory
and use a command like:
Modified: inn.conf.pod
===================================================================
--- inn.conf.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ inn.conf.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -163,10 +163,10 @@
=item I<bindaddress6>
-Like I<bindaddress> but for IPv6 sockets. If only one of the I<bindaddress>
+Like I<bindaddress> but for IPv6 sockets. If only one of the I<bindaddress>
and I<bindaddress6> parameters is used, then only the socket for the
-corresponding address family is created. If both parameters are used
-then two sockets are created. If neither of them is used, the list of
+corresponding address family is created. If both parameters are used
+then two sockets are created. If neither of them is used, the list of
sockets to listen on will be determined by the system library
I<getaddrinfo(3)> function. The value of the INND_BIND_ADDRESS6, if set,
overrides this setting. The default value is unset.
Modified: innfeed.pod
===================================================================
--- innfeed.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ innfeed.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -152,7 +152,7 @@
by one; receipt of a SIGUSR2 will decrement it by one. The debugging
level starts at zero (unless the B<-d> option it used), in which case no
debugging information is emitted. A larger value for the level means more
-debugging information. Numbers up to 5 are currently useful.
+debugging information. Numbers up to 5 are currently useful.
=head1 SYSLOG ENTRIES
Modified: innxmit.pod
===================================================================
--- innxmit.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ innxmit.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -123,7 +123,7 @@
=head1 HISTORY
-Written by Rich $alz <rsalz at uunet.uu.net> for InterNetNews. Converted to POD
+Written by Rich $alz <rsalz at uunet.uu.net> for InterNetNews. Converted to POD
by Julien Elie.
$Id$
Modified: libinnhist.pod
===================================================================
--- libinnhist.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ libinnhist.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -71,7 +71,7 @@
The B<HISopen> function opens the history file designated by I<path>
using the mode I<flags> using the specified I<method>. I<flags> may be
B<HIS_RDONLY> to indicate that read-only access to the history
-database is desired, or B<HIS_RDWR> for read/write access. History
+database is desired, or B<HIS_RDWR> for read/write access. History
methods are defined at build time; the history method currently
available is "hisv6". On success a newly initialised history handle is
returned, or B<NULL> on failure.
@@ -82,7 +82,7 @@
the caller would like as much of the data to be kept on disk (and out
of memory), B<HIS_INCORE> indicates that the data files should be kept
in main memory where possible and B<HIS_MMAP> that the files should be
-mmap()ed into the processes address space. B<HIS_INCORE> is typically
+mmap()ed into the processes address space. B<HIS_INCORE> is typically
used where a mass rebuild of the history database is being performed;
the underlying history manager may assume that the caller will call
B<HISsync>() to sync the data files to disk.
@@ -95,7 +95,7 @@
B<HISCTLS_PATH>.
The B<HISclose> function closes the handle I<history> and deallocates
-any resources associated with it. It returns B<false> on failure or
+any resources associated with it. It returns B<false> on failure or
B<true> on success.
The B<HISsync> function synchronises any outstanding transactions
@@ -123,9 +123,9 @@
with I<key>. I<arrived>, I<posted>, and I<expired> specify the arrival,
posting, and expiry time respectively; I<posted> and I<expired> may be
specifed as <= 0 in which case that component shall be treated as
-absent in the database. I<token> is associated with the specified
+absent in the database. I<token> is associated with the specified
I<key>. B<HISwrite> returns B<true> on success, or B<false> on
-failure. The behaviour when I<key> is not unique with respect to the
+failure. The behaviour when I<key> is not unique with respect to the
existing entries in I<history> is unspecified.
B<HISremember> writes a new entry to the database I<history>
@@ -140,10 +140,10 @@
associated with I<key>. I<arrived>, I<posted>, I<expired> specify the
arrival, posting and expiry time respectively; I<posted> and
I<expired> may be specifed as <= 0 in which case that component shall
-be treated as absent in the database. I<token> is associated with the
+be treated as absent in the database. I<token> is associated with the
specified I<key>; if B<NULL> then the history database merely
remembers that this I<key> has been seen, together with its arrival
-time. B<HISreplace> returns B<true> on success, or B<false> on
+time. B<HISreplace> returns B<true> on success, or B<false> on
failure.
B<HISexpire> expires the history database associated with I<history>,
@@ -150,7 +150,7 @@
creating a new, replacement, database in the same location if I<path>
is B<NULL>, or in I<path> if not B<NULL>; if I<path> is not B<NULL>
then the replacement of the old history database with the new one is
-assumed to be performed out of band by the caller. The I<writing> flag
+assumed to be performed out of band by the caller. The I<writing> flag
is normally passed as B<true>, if you wish to inhibit writing of the
new database (and so merely see the callbacks), I<writing> may be set
B<false>.
@@ -159,7 +159,7 @@
I<reason> string is used as the argument to the `ctlinnd pause'
command, and as such the server should be reserved by the caller prior
to calling B<HISexpire>; if the caller wishes to inhibit pausing of
-the server, passing B<NULL> will achieve this. If I<reason> is not
+the server, passing B<NULL> will achieve this. If I<reason> is not
B<NULL>, then on successful return from B<HISexpire> the server will
be left paused and the caller should unpause it.
@@ -169,11 +169,11 @@
If I<exists>() returns B<false> it indicates that stored entity
associated with token is no longer available (or no longer required),
and therefore the associated history entry may be expired once it
-meets the I<threshold> constraint. If I<exists>() returns B<true> the
+meets the I<threshold> constraint. If I<exists>() returns B<true> the
entry is kept as-is in the newly expired history database.
The I<exists> function is passed the arrival, posting and expiry
-times, in addition to the token associated with the entry. Note that
+times, in addition to the token associated with the entry. Note that
posting and/or expiry may be zero, but that the token will never be
B<NULL> (such entries are handled solely via the threshold
mechanism). The storage token passed to the discrimination function
@@ -192,15 +192,15 @@
unspecified.
B<HISwalk> provides an iteration function for the specified I<history>
-database. For every entry in the history database, I<callback> is
+database. For every entry in the history database, I<callback> is
invoked, passing the I<cookie>, arrival, posting, and expiry times, in
-addition to the token associated with the entry. If the I<callback>()
+addition to the token associated with the entry. If the I<callback>()
returns B<false> the iteration is aborted and B<HISwalk> returns
B<false> to the caller.
To process the entire database in the presence of a running server,
I<reason> may be passed; if this argument is not B<NULL>, it is used
-as an an argument to the `ctlinnd (reserve|pause|go)' commands. If
+as an an argument to the `ctlinnd (reserve|pause|go)' commands. If
I<reason> is B<NULL> and the server is running, the behaviour of
B<HISwalk> is undefined.
@@ -242,18 +242,18 @@
B<HISerror> returns a string describing the most recent error
associated with I<history>; the format and content of these strings is
-history manager dependent. Note that on setting an error, the history
+history manager dependent. Note that on setting an error, the history
API will call the B<warn> function from libinn(3).
B<HISctl> provides a control interface to the underlying history
-manager. The I<request> argument determines the type of the request
-and the meaning of the I<val> argument. The values for I<request> are:
+manager. The I<request> argument determines the type of the request
+and the meaning of the I<val> argument. The values for I<request> are:
=over 4
=item C<HISCTLG_PATH> (const char **)
-Get the base file path which the history handle represents. I<val>
+Get the base file path which the history handle represents. I<val>
should be a pointer to a location of type B<const char *>. The
result must not later be passed to free(3).
@@ -269,7 +269,7 @@
Set an upper bound on how many history operations may be pending in
core before being synced to permanent storage; B<0> indicates
-unlimited. I<val> should be a pointer to a value of type B<size_t> and
+unlimited. I<val> should be a pointer to a value of type B<size_t> and
will not be modified by the call.
=item C<HISCTLS_NPAIRS> (size_t *)
@@ -276,7 +276,7 @@
Set a hint to the to the underlying history manager as to how many
entries there are expected to be in the history database; B<0>
-indicates that an automatic or default sizing should be made. I<val>
+indicates that an automatic or default sizing should be made. I<val>
should be a pointer to a value of type B<size_t> and will not be
modified by the call.
@@ -285,7 +285,7 @@
Instruct the underlying history manager to ignore existing database
when creating new ones; typically this option may be set to B<true> if
the administrator believes that the existing history database is
-corrupt and that ignoring it may help. I<val> should be a pointer to a
+corrupt and that ignoring it may help. I<val> should be a pointer to a
value of type B<bool> and will not be modified by the call.
=item C<HISCTLS_STATINTERVAL> (time_t *)
@@ -293,7 +293,7 @@
For the history v6 and tagged hash managers, set the interval, in
seconds, between stat(2)s of the history files checking for replaced
files (as happens during expire); this option is typically used by
-nnrpd(8) like applications. I<val> should be a pointer to a value of
+nnrpd(8) like applications. I<val> should be a pointer to a value of
type B<time_t> and will not be modified by the call.
=back
Modified: list.pod
===================================================================
--- list.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ list.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -65,10 +65,10 @@
I<node> or B<NULL> if I<node> was the first node.
B<list_remhead> removes the first node from I<list> and returns it to
-the caller. If the list is empty B<NULL> is returned.
+the caller. If the list is empty B<NULL> is returned.
B<list_remtail> removes the last node from I<list> and returns it to
-the caller. If the list is empty B<NULL> is returned.
+the caller. If the list is empty B<NULL> is returned.
B<list_remove> removes I<node> from the list it is on and returns it
to the caller.
Modified: ovdb.pod
===================================================================
--- ovdb.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ ovdb.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -39,7 +39,7 @@
The ovdb database may take up more disk space for a given spool than the
other overview methods. Plan on needing at least S<1.1 KB> for every article
in your spool (not counting crossposts). So, if you have 5 million
-articles, you'll need at least S<5.5 GB> of disk space for ovdb. With compression
+articles, you'll need at least S<5.5 GB> of disk space for ovdb. With compression
enabled, this estimate changes to S<0.7 KB> per article. See the L<COMPRESSION>
section below.
Plus, you'll need additional space for transaction logs: at least S<100 MB>.
@@ -75,7 +75,7 @@
=item compress
If INN was compiled with zlib, and this compress parameter is true, OVDB
-will compress overview records that are longer than 600 bytes. See
+will compress overview records that are longer than 600 bytes. See
the L<COMPRESSION> section below.
=item numdbfiles
@@ -192,7 +192,7 @@
space, compression keeps the average size of the database keys smaller.
This in turn increases the average number of keys per page, which can
significantly improve performance and also helps keep the database more
-compact. This feature requires that INN be built with zlib. Only records
+compact. This feature requires that INN be built with zlib. Only records
larger than 600 bytes get compressed, because that is the point at which
compression starts to become significant.
Modified: storage.conf.pod
===================================================================
--- storage.conf.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ storage.conf.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -167,7 +167,7 @@
The C<cnfs> storage method stores articles in large cyclic buffers (CNFS
stands for Cyclic News File System). Articles are stored in CNFS buffers
in arrival order, and when the buffer fills, it wraps around to the beginning
-and stores new articles over the top of the oldest articles in the buffer. The
+and stores new articles over the top of the oldest articles in the buffer. The
expire time of articles stored in CNFS buffers is therefore entirely
determined by how long it takes the buffer to wrap around, which depends
on how quickly data is being stored in it. (This method is therefore said
Modified: tst.pod
===================================================================
--- tst.pod 2016-07-31 20:01:43 UTC (rev 10040)
+++ tst.pod 2016-07-31 20:16:07 UTC (rev 10041)
@@ -21,20 +21,20 @@
=head1 DESCRIPTION
B<tst_init> allocates memory for members of I<struct tst>, and
-allocates the first I<node_line_width> nodes. A NULL pointer is
-returned by B<tst_init> if any part of the memory allocation fails. On
+allocates the first I<node_line_width> nodes. A NULL pointer is
+returned by B<tst_init> if any part of the memory allocation fails. On
success, a pointer to a I<struct tst> is returned.
-The value for I<node_line_width> must be chosen very carefully. One
-node is required for every character in the tree. If you choose a
+The value for I<node_line_width> must be chosen very carefully. One
+node is required for every character in the tree. If you choose a
value that is too small, your application will spend too much time
-calling malloc(3) and your node space will be too spread out. Too large
+calling malloc(3) and your node space will be too spread out. Too large
a value is just a waste of space.
B<tst_cleanup> frees all memory allocated to nodes, internal structures,
as well as I<tst> itself.
-B<tst_insert> inserts the string I<key> into the tree. Behavior when a
+B<tst_insert> inserts the string I<key> into the tree. Behavior when a
duplicate key is inserted is controlled by I<option>. If I<key> is
already in the tree then B<TST_DUPLICATE_KEY> is returned, and the
data pointer for the existing key is placed in I<exist_ptr>. If
@@ -43,8 +43,8 @@
pointer will still be placed in I<exist_ptr>.
If a duplicate key is encountered and I<option> is not set to
-B<TST_REPLACE> then B<TST_DUPLICATE_KEY> is returned. If I<key> is
-zero length then B<TST_NULL_KEY> is returned. A successful insert or
+B<TST_REPLACE> then B<TST_DUPLICATE_KEY> is returned. If I<key> is
+zero length then B<TST_NULL_KEY> is returned. A successful insert or
replace returns B<TST_OK>. A return value of B<TST_ERROR> indicates
that a memory allocation error occurred while trying to grow the node
free.
@@ -51,7 +51,7 @@
Note that the I<data> argument must never be B<NULL>. If it is, then
calls to B<tst_search> will fail for a key that exists because the
-data value was set to B<NULL>, which is what B<tst_search> returns. If
+data value was set to B<NULL>, which is what B<tst_search> returns. If
you just want a simple existence tree, use the B<tst> pointer as the
data pointer.
More information about the inn-committers
mailing list