Log Message:
-----------
Remove the .pl extentions on the admin scripts to reflect chnages as made previously

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        adminscripts.sgml (r1.18 -> r1.19)
        listenpaths.sgml (r1.13 -> r1.14)
        maintenance.sgml (r1.12 -> r1.13)
        monitoring.sgml (r1.14 -> r1.15)
        reshape.sgml (r1.13 -> r1.14)
        startslons.sgml (r1.10 -> r1.11)

-------------- next part --------------
Index: startslons.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/startslons.sgml,v
retrieving revision 1.10
retrieving revision 1.11
diff -Ldoc/adminguide/startslons.sgml -Ldoc/adminguide/startslons.sgml -u -w -r1.10 -r1.11
--- doc/adminguide/startslons.sgml
+++ doc/adminguide/startslons.sgml
@@ -43,13 +43,13 @@
 
 <itemizedlist>
 
-<listitem><para> <filename>tools/altperl/slon_watchdog.pl</filename> -
+<listitem><para> <filename>tools/altperl/slon_watchdog</filename> -
 an <quote>early</quote> version that basically wraps a loop around the
 invocation of <xref linkend="slon">, restarting any time it falls
 over</para>
 </listitem>
 
-<listitem><para> <filename>tools/altperl/slon_watchdog2.pl</filename>
+<listitem><para> <filename>tools/altperl/slon_watchdog2</filename>
 - a somewhat more intelligent version that periodically polls the
 database, checking to see if a <command>SYNC</command> has taken place
 recently.  We have had VPN connections that occasionally fall over
@@ -59,7 +59,7 @@
 
 </itemizedlist></para>
 
-<para>The <filename>slon_watchdog2.pl</filename> script is probably
+<para>The <filename>slon_watchdog2</filename> script is probably
 <emphasis>usually</emphasis> the preferable thing to run.  It was at
 one point not preferable to run it whilst subscribing a very large
 replication set where it is expected to take many hours to do the
Index: monitoring.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/monitoring.sgml,v
retrieving revision 1.14
retrieving revision 1.15
diff -Ldoc/adminguide/monitoring.sgml -Ldoc/adminguide/monitoring.sgml -u -w -r1.14 -r1.15
--- doc/adminguide/monitoring.sgml
+++ doc/adminguide/monitoring.sgml
@@ -62,7 +62,7 @@
 </para>
 </sect2>
 
-<sect2 id="testslonystate"> <title> test_slony_state.pl </title>
+<sect2 id="testslonystate"> <title> test_slony_state</title>
 
 <para> This script is in preliminary stages, and may be used to do
 some analysis of the state of a <productname>Slony-I</productname>
Index: maintenance.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/maintenance.sgml,v
retrieving revision 1.12
retrieving revision 1.13
diff -Ldoc/adminguide/maintenance.sgml -Ldoc/adminguide/maintenance.sgml -u -w -r1.12 -r1.13
--- doc/adminguide/maintenance.sgml
+++ doc/adminguide/maintenance.sgml
@@ -81,7 +81,7 @@
 
 <itemizedlist>
 
-<listitem><para> <command>test_slony_replication.pl</command> is a
+<listitem><para> <command>test_slony_replication</command> is a
 Perl script to which you can pass connection information to get to a
 &slony1; node.  It then queries <envar>sl_path</envar> and other
 information on that node in order to determine the shape of the
@@ -114,13 +114,13 @@
 for the Perl scripts.</para></listitem>
 
 <listitem><para><command>run_rep_tests.sh</command> is a <quote>wrapper</quote> script
-that runs <command>test_slony_replication.pl</command>.</para>
+that runs <command>test_slony_replication</command>.</para>
 
 <para> If you have several &slony1; clusters, you might set up
 configuration in this file to connect to all those
 clusters.</para></listitem>
 
-<listitem><para><command>nagios_slony_test.pl</command> is a script
+<listitem><para><command>nagios_slony_test</command> is a script
 that was constructed to query the log files so that you might run the
 replication tests every so often (we run them every 6 minutes), and
 then a system monitoring tool such as <ulink
Index: adminscripts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/adminscripts.sgml,v
retrieving revision 1.18
retrieving revision 1.19
diff -Ldoc/adminguide/adminscripts.sgml -Ldoc/adminguide/adminscripts.sgml -u -w -r1.18 -r1.19
--- doc/adminguide/adminscripts.sgml
+++ doc/adminguide/adminscripts.sgml
@@ -69,7 +69,7 @@
 <para>Unlike <envar>SLONYNODES</envar>, which is essential for
 <emphasis>all</emphasis> of the <xref linkend="slonik">-generating
 scripts, this only needs to be set when running
-<filename>create_set.pl</filename>, as that is the only script used to
+<filename>create_set</filename>, as that is the only script used to
 control what tables will be in a particular replication set.</para>
 
 <para>What variables are set up.</para>
@@ -102,7 +102,7 @@
 </listitem>
 </itemizedlist>
 </sect2>
-<sect2><title>build_env.pl</title>
+<sect2><title>build_env</title>
 
 <para>Queries a database, generating output hopefully suitable for
 <filename>slon_tools.conf</filename> consisting of:</para>
@@ -113,82 +113,82 @@
 <envar>nvar>@SERIALT</envar>nvar>, and <envar>@SEQUENCES</envar></para></listitem>
 </itemizedlist>
 </sect2>
-<sect2><title>create_set.pl</title>
+<sect2><title>create_set</title>
 
 <para>This requires <envar>SLONYSET</envar> to be set as well as
 <envar>SLONYNODES</envar>; it is used to generate the <command>slonik</command> script to set up
 a replication set consisting of a set of tables and sequences that are
 to be replicated.</para>
 </sect2>
-<sect2><title>drop_node.pl</title>
+<sect2><title>drop_node</title>
 
 <para>Generates Slonik script to drop a node from a &slony1; cluster.</para>
 </sect2>
-<sect2><title>drop_set.pl</title>
+<sect2><title>drop_set</title>
 
 <para>Generates Slonik script to drop a replication set
 (<emphasis>e.g.</emphasis> - set of tables and sequences) from a
 &slony1; cluster.</para>
 </sect2>
-<sect2><title>failover.pl</title>
+<sect2><title>failover</title>
 
 <para>Generates Slonik script to request failover from a dead node to some new origin</para>
 </sect2>
-<sect2><title>init_cluster.pl</title>
+<sect2><title>init_cluster</title>
 
 <para>Generates Slonik script to initialize a whole &slony1; cluster,
 including setting up the nodes, communications paths, and the listener
 routing.</para>
 </sect2>
-<sect2><title>merge_sets.pl</title>
+<sect2><title>merge_sets</title>
 
 <para>Generates Slonik script to merge two replication sets together.</para>
 </sect2>
-<sect2><title>move_set.pl</title>
+<sect2><title>move_set</title>
 
 <para>Generates Slonik script to move the origin of a particular set to a different node.</para>
 </sect2>
-<sect2><title>replication_test.pl</title>
+<sect2><title>replication_test</title>
 
 <para>Script to test whether &slony1; is successfully replicating
 data.</para>
 </sect2>
-<sect2><title>restart_node.pl</title>
+<sect2><title>restart_node</title>
 
 <para>Generates Slonik script to request the restart of a node.  This was
 particularly useful pre-1.0.5 when nodes could get snarled up when
 slon daemons died.</para>
 </sect2>
-<sect2><title>restart_nodes.pl</title>
+<sect2><title>restart_nodes</title>
 
 <para>Generates Slonik script to restart all nodes in the cluster.  Not
 particularly useful.</para>
 </sect2>
-<sect2><title>show_configuration.pl</title>
+<sect2><title>show_configuration</title>
 
 <para>Displays an overview of how the environment (e.g. - <envar>SLONYNODES</envar>) is set
 to configure things.</para>
 </sect2>
-<sect2><title>slon_kill.pl</title>
+<sect2><title>slon_kill</title>
 
 <para>Kills slony watchdog and all slon daemons for the specified set.  It
 only works if those processes are running on the local host, of
 course!</para>
 </sect2>
-<sect2><title>slon_pushsql.pl</title>
+<sect2><title>slon_pushsql</title>
 
 <para>Generates Slonik script to push DDL changes to a replication set.</para>
 </sect2>
-<sect2><title>slon_start.pl</title>
+<sect2><title>slon_start</title>
 
 <para>This starts a slon daemon for the specified cluster and node, and uses
-slon_watchdog.pl to keep it running.</para>
+slon_watchdog to keep it running.</para>
 </sect2>
-<sect2><title>slon_watchdog.pl</title>
+<sect2><title>slon_watchdog</title>
 
-<para>Used by <command>slon_start.pl</command>.</para>
+<para>Used by <command>slon_start</command>.</para>
 
-</sect2><sect2><title>slon_watchdog2.pl</title>
+</sect2><sect2><title>slon_watchdog2</title>
 
 <para>This is a somewhat smarter watchdog; it monitors a particular
 &slony1; node, and restarts the slon process if it hasn't seen updates
@@ -198,28 +198,28 @@
 the slon sometimes stops working without becoming aware of it.</para>
 
 </sect2>
-<sect2><title>subscribe_set.pl</title>
+<sect2><title>subscribe_set</title>
 
 <para>Generates Slonik script to subscribe a particular node to a particular replication set.</para>
 
-</sect2><sect2><title>uninstall_nodes.pl</title>
+</sect2><sect2><title>uninstall_nodes</title>
 
 <para>This goes through and drops the &slony1; schema from each node;
 use this if you want to destroy replication throughout a cluster.
 This is a <emphasis>VERY</emphasis> unsafe script!</para>
 
-</sect2><sect2><title>unsubscribe_set.pl</title>
+</sect2><sect2><title>unsubscribe_set</title>
 
 <para>Generates Slonik script to unsubscribe a node from a replication set.</para>
 
 </sect2>
-<sect2><title>update_nodes.pl</title>
+<sect2><title>update_nodes</title>
 
 <para>Generates Slonik script to tell all the nodes to update the
 &slony1; functions.  This will typically be needed when you upgrade
 from one version of &slony1; to another.</para>
 </sect2>
-<sect2 id="regenlisten"><title>regenerate-listens.pl</title>
+<sect2 id="regenlisten"><title>regenerate-listens</title>
 
 <para>This script connects to a &slony1; node, and queries various
 tables (sl_set, sl_node, sl_subscribe, sl_path) to compute what <xref
Index: listenpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/listenpaths.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -Ldoc/adminguide/listenpaths.sgml -Ldoc/adminguide/listenpaths.sgml -u -w -r1.13 -r1.14
--- doc/adminguide/listenpaths.sgml
+++ doc/adminguide/listenpaths.sgml
@@ -125,7 +125,7 @@
 <para>When on the <quote>receiver</quote> node, look to the <quote>provider</quote>
 node to provide events coming from the <quote>origin</quote> node.</para>
 
-<para>The tool <filename>init_cluster.pl</filename> in the
+<para>The tool <filename>init_cluster</filename> in the
 <filename>altperl</filename> scripts produces optimized listener
 networks in both the tabular form shown above as well as in the form
 of <xref linkend="slonik"> statements.</para>
Index: reshape.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/reshape.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -Ldoc/adminguide/reshape.sgml -Ldoc/adminguide/reshape.sgml -u -w -r1.13 -r1.14
--- doc/adminguide/reshape.sgml
+++ doc/adminguide/reshape.sgml
@@ -38,7 +38,7 @@
 </itemizedlist>
 </para>
 <para> The <filename>altperl</filename> toolset includes a
-<application>regenerate-listens.pl</application> script that is up to
+<application>regenerate-listens</application> script that is up to
 the task of creating the new <xref linkend="stmtstorelisten">
 commands; it isn't, however, smart enough to know what listener paths
 should be dropped.