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