Proposed samples cleanup

The Hermit Hacker scrappy at hub.org
Wed Oct 27 13:59:49 UTC 1999


Oh thank you thank you thank you ...

Enough support from me? :)




On 27 Oct 1999, Russ Allbery wrote:

> 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/>
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy at hub.org           secondary: scrappy@{freebsd|postgresql}.org 



More information about the inn-workers mailing list