Proposed samples cleanup

Russ Allbery rra at stanford.edu
Wed Oct 27 09:32:58 UTC 1999


Okay, time to tackle this, since it should really be done before a 2.3
release.  :)

I propose the following breakup/reorganization of the samples directory,
so that make update will update things that probably have not been locally
modified ("INN-maintained" things).  The following files stay in samples:

INN.py             filter_innd.pl     newgroup.pl.in    sendme.pl.in
actsync.cfg.in     filter_innd.py     news2mail.cf      sendsys.in
actsync.ign        filter_nnrpd.pl    newsfeeds.in      sendsys.pl.in
buffindexed.conf   ihave.in           nnrpd.track       senduuname.in
checkgroups.in     ihave.pl.in        nnrpd_auth.pl.in  senduuname.pl.in
checkgroups.pl.in  incoming.conf      nntpsend.ctl      startup.tcl.in
control.ctl        inn.conf.in        overview.fmt      startup_innd.pl
cycbuff.conf       innfeed.conf       parsecontrol.in   storage.conf
default.in         innreport.conf.in  passwd.nntp       version.in
distrib.pats       innwatch.ctl.in    readers.conf      version.pl.in
docheckgroups.in   moderators         rmgroup.in
expire.ctl         motd.news          rmgroup.pl.in
filter.tcl         newgroup.in        sendme.in

All of the various control message parsing scripts are still there pending
Greg's controlchan rewrite that will hopefully make them all obsolete (so
it's probably not worth bothering moving them).  All of the configuration
files are obviously still there, as are all the filter scripts.  This is
stuff we really do expect people to change, plus the control message
handling mess.

The following would move into backends:

controlbatch.in  mod-active.in  nntpsend.in   send-ihave.in  send-uucp.in
controlchan.in   news2mail.in   pgpverify.in  send-nntp.in   sendbatch.in

This is anything INN would be running as a feed, or anything invoked by
something INN is running as a feed, or anything that is used in sending
news to remote sites.  mod-active.in is here because actsync is in
backends as well.

The following would move into doc:

sample.control

The following would move into expire:

expirerm.in

The following would move into frontends:

cnfsheadconf.in  mailpost.in  scanspool.in
cnfsstat.in      pullnews.in  signcontrol.in

Things that feed articles into INN, or that are used (like sm) to retrieve
from or search through the news spool, plus signcontrol.in which is used
to prepare control messages for injection.

The following are obsolete and can be removed (I'll do that right away):

innreport.in.orig  nnrp.access  storage.ctl

Finally, I propose creating a new directory named scripts whose contents
would also be installed as part of make update, containing:

inncheck.in       innshellvars.in      innwatch.in    simpleftp.in
innmail.in        innshellvars.pl.in   news.daily.in  tally.control.in
innreport.in      innshellvars.tcl.in  rc.news.in     writelog.in
innreport_inn.pm  innstat.in           scanlogs.in

This is the stuff I didn't have any better place for.

I can do this in the CVS repository if people think it's a good idea and
agree with my placement of things.  I can either copy the RCS files
directly inside the CVS repository, then cvs remove them from their old
location on the tip and cvs remove them from their new location on the
STABLE branch (which creates some repository clutter, but means that the
full change history is available with cvs log) or just cvs add them in
their new location and cvs remove them in their old location (cleaner and
cuts down on repository bloat, but means that you have to go back to
samples and do a cvs log there to get older revision history), whichever
is considered best.

At the same time, as part of this, I'd like to add a new directory called
support, which eventually will get all the various libtool and configure
cruft currently at the top level migrated into it, and stick the following
script (fixscript.in) in it.  Then we can modify all shell and Perl
scripts that require no configure substitution beyond the path to
innshellvars and the path to the interpretor to have the inclusion of
innshellvars on the second line of the script and then use this script
rather than configure to do the substitution (which will be *way* faster
and can be done at build time).

Opinions?

#! @_PATH_SH@

##  $Id$
##
##  Fix interpretor paths and INN variable load paths.
##
##  Scripts shipped with INN always have the invocation path for the
##  interpretor on the first line and the command to load INN variable
##  settings into the script on the second line.  For example, for a Bourne
##  shell script:
##
##      #!/bin/sh
##      . /var/news/lib/innshellvars
##
##  This script takes as input such a script and outputs the same script
##  with the first two lines replaced to have the correct path to the
##  interpretor and to the INN variable library, as determined by configure.

PERLPATH='@_PATH_PERL@'
SHPATH='@_PATH_SH@'
LIBDIR='@LIBDIR@'

input="$1"
if [ -z "$input" ] ; then
    echo "No input file specified" >&2
    exit 1
fi

output="$2"
if [ -z "$output" ] ; then
    output=`echo "$input" | sed 's/\.in$//'`
fi
if [ x"$input" = x"$output" ] ; then
    echo "No output file specified and input file doesn't end in .in" >&2
    exit 1
fi

interpretor=`head -1 "$input"`
case "$interpretor" in
*/sh)
    path="$SHPATH"
    lib=". $LIBDIR/innshellvars"
    ;;
*/perl)
    path="$PERLPATH"
    lib="require '$LIBDIR/innshellvars.pl';"
    ;;
*)
    echo "Unknown interpretor $interpretor" >&2
    exit 1
    ;;
esac

echo "#! $path"   >  "$output"
echo "$lib"       >> "$output"
sed 1,2d "$input" >> "$output"
chmod 755 "$output"

-- 
Russ Allbery (rra at stanford.edu)         <URL:http://www.eyrie.org/~eagle/>


More information about the inn-workers mailing list