L L L L
LL LL LL LL
L L L L L L
L L L L
L L L L
LLL L L LLL L L LLL LLLLL LLL L L
L L LL LL L L L L L L L L L L
LLLLL L L L L LLLLL LLLLL L L LLLLL
L L L L L L L L L L L L L L
L L L L LLL L L L L L LLL L L
L L LL LLLL LLLL
L L L L L L L
L L L L LLL LLLL
L L L L L L
L LL L LLL LLLL
(C) 1996 ULRICH LAMMERS
Alle Rechte vorbehalten
Dieses Arexx-Script benötigt den MailManager von Pino Alberti
------------------------------------------------------------------------------
1. Einführung
=============
1.1 Rechtliches
---------------
MM_AmiHatch ist ein Utility für den Mail Manager von Pino Aliberti um die
AMINet-Archive aus dem InterNet mit ihren RENAMING-Files besser handeln zu
können.
Für diejenigen, die Ihr System als AmiNet-Mirror nutzen, ist das eine
enorme Arbeitserleichterung, das die gesamte Verarbeitung der
aminet_xxxxx_xxxxx.lha sowie der ___RENAMING_xxxxx_xxxxx von dem Script
übernommen wird.
Die Programme und Dateien dieses Archives sind frei kopierbar, das Copyright
liegt allerdings bei © Ulrich Lammers. Das Archiv darf frei weitergegeben
und verbreitet werden, solange dafür nicht mehr Geld verlangt wird, als für
das Kopieren notwendig ist.
Eine kommerzielle Nutzung ist ohne die schriftliche, vorherige Erlaubnis des
Autors verboten. Dieses Archiv und alle seine Einzeldateien müssen
unverändert bleiben, es dürfen keine Veränderungen oder Erweiterungen
vorgenommen werden.
MM_AmiHatch ist Mailware :-). Das bedeutet, wenn Du dieses Programm länger
als dreißig Tage nutzt, schicke dem Programmierer bitte eine kurze Mail,
dass Du dieses Programm nutzt. In dieser dürfen auch kritische Anmerkungen
und Feature-Requests enthalten sein... es ist frustrierend Programme zu
schreiben von denen man nicht weiß ob sie jemand nutzt, ob sie Sinn machen
oder nicht.
Die einzige Bedingung um MM_AmiHatch zu nutzen, ist die Beachtung dieser
wenigen Auflagen.
==============================================================================
Der Autor ist für irgendwelche aus der Nutzung dieses Programms
resultierenden Probleme oder Datenverluste NICHT verantwortlich.
==============================================================================
1.2 Generelles
--------------
Dieses ist mein erstes veröffentlichtes ARexx-Programm für den MailManager.
Sicherlich können noch einige Optimierungen, neue Features etc. Einzug
finden. Also seid bitte nicht zu hart in Eurer Beurteilung. Seinen Zweck
erfüllt es allemal und das sogar sehr gut. (auf meinem System zumindest..)
1.3 Autor
---------
Wenn Du irgendwelche Verbesserungsvorschläge oder Probleme mit diesem
Programm hast, vielleicht sogar einen nicht existenten Bug gefunden hast, so
lasse es mich wissen.
Zu erreichen bin ich folgendermassen:
Ulrich Lammers
Alter Pferdemarkt 3 39:178/0.0 AmigaNet
49808 Lingen 2:2426/4065.0FidoNet
Telefon 0591/9150115
2. Features
===========
MM_AmiHatch...
... zerlegt die aminet.xxxxx.xxxxx.lha Files in Ihre Komponenten,
führt ein automatisches Renaming durch und kopiert die Files in Ihr
passendes Zielverzeichnis.
... hatched alle neuankommenden Files für angeschlossene Nodes/Points nach
Massgabe des MM_Config Files
... erstellt nicht existente TickAreas nach Vorgabe
... erstellt AutoLinks für neue TickAreas
... erstellt Zielverzeichnis in Baumstruktur oder flach, was von einigen
BBS-Systemen (Excelsior!) gefordert wird.
... erstellt NewArea-Announces in beliebig vielen Areas
... kann Einträge von neuen Areas in die FFRS-Konfiguration vornehmen
3. Installation
===============
1. Kopiere die Dateien in die entsprechenden MM: Verzeichnisse
2. Verändere die .CFG nach Deinem Gusto.
3. Füge ein rx MM:Rexx/MM_AmiHatch bei Deinem TIC-Import ein. Ich empfehle
die
Nutzung von MM_ImportPlus (© Robert Hofmann) "#TICKCMD..."
4. Benutzung
============
[RX] MM_AmiHatch[.rexx]
Wie dem geneigten Nutzer vielleicht aufgefallen ist, befindet sich ein
weiteres Script in der Distribution, nämlich "MM_AmiHatch". Das ist ein
Ausführbares Programm, das mit CompressRexx2.1 erstellt wurde. Es lässt sich
wie ein normales Programm starten, BENÖTIGT ABER TROTZDEM AREXXMAST zur
Funktion.
5. Konfiguration
================
Im folgenden sind alle Konfigurationsparameter einzeln erläutert. Schau Dir
bitte die Beispiel-Konfiguration genau an!!
5.1 #INBOUND DIR/A
---------------------
Pfad zu Deinem Verzeichnis, in dem die aminet_xxxxx_xxxxxx.lha und
___RENAMING.xxxxx.xxxxx Dateien liegen.
Bsp.: #INBOUND Work:Aminet_Hold/
5.2 #WORKDIR DIR/A
---------------------
Das Arbeitsverzeichnis für MM_AmiHatch, in dem die Archive ausgepackt
werden.
Bsp.: #WORKDIR UNARC:
5.3 #DESTINATIONPFAD DIR/A
-----------------------------
Hier werden die (neuanzulegenden) TickAreas erstellt.
Bsp.: #DESTINATIONPFAD Aminet:
5.4 #ARCHIVEPREFIX NAME/A
------------------------------
Das ist der Namensprefix der zu bearbeitenden AmiNet-Archive.
Bsp.: #ARCHIVEPREFIX aminet_
5.5 #BACKUPDIR DIR/A
-------------------------
Der Pfad zum BackUp-Directory, wo verarbeitete Archive und ___RENAMING-Files
abgelegt werden. Ohne Namensangabe werden die Files einfach gelöscht.
Bsp.: #BACKUPDIR AminetBCK:
5.6 #AUTOLINKNODE <Node>[<Node> <Node> <Node>...]
-------------------------------------------------
Hier werden alle Nodes/Points, also Systeme eingetragen, welche die NEU
ERSTELLTEN Areas als Autolink sofort erhalten sollen (z.B. Downlinks die
ebenfalls AmiNet-Mirror sind)
Bsp.: #AUTOLINKNODE 39:170/1 110 178/111 .1 .12
Hierbei würden die Nodes 39:170/1, 39:170/110, 39:178/111 sowie die Points
.1 und .12
von 39:178/111 die neuen Areas erhalten.
5.7 #HATCHNODE <Node>/A
----------------------------
Dieses ist die Absende-Adresse des Systems für die TIC-Files.
Bsp.: #HATCHNODE 39:178/1.0AmiNet
5.8 #GROUP <gruppe>
------------------------
Die Gruppe, die in dem neuen TickArea Eintrag im MM_CFG eingetragen
werden soll. Muß eine gültige Gruppe der MM_CFG sein.
Bsp.: #GROUP AMINET
5.9 #LEVEL <num>
---------------------
Der Level, der in dem neuen TickArea Eintrag im MM_CFG eingetragen werden
soll.
Bsp.: #LEVEL 50
5.10 #NEWAREA [Tree|NoTree]
-----------------------------
Hiermit wird festgelegt, wie die Verzeichnisstruktur der neuen TIC-Areas
auszusehen hat. Es gibt zwei Möglichkeiten:
TREE - Die Verzeichnisse werden wie im AmiNet üblich mit
Unterverzeichnissen angelegt. Also z.B.: AmiNet:COMM/BBS/
Das ist wohl die Standardeinstellung.
NOTREE - Die Verzeichnisse werden OHNE Unterverschachtelungen im
Zielverzeichniss angelegt. Das ist für die Verwendung mit
einigen
BBS-Paketen (z.B. Excelsior!) erforderlich, da diese keine
verschachtelten FileBase-Verzeichnisse unterstützen.
Also z.B. : AmiNet:COMM_BBS/
Bsp.: #NEWAREA TREE
5.11 #KUTTAREAWITH <Trenner>
-------------------------------------
Wenn bei #NEWAREA NoTree angegeben wurde, kann hier ein Trennzeichen für
die
Betitelung der Area-Directories angegeben werden.
Bsp.: #KUTTAREAWITH _ 'ist gleich --> AMINET:COMM_BBS/'
#KUTTAREAWITH . 'ist gleich --> AMINET:COMM.BBS/'
5.12 #ANNOUNCEAREA <AreaName>
----------------------------------
Hiermit kann man angeben, in welche Area die Announcements für die
Erstellung einer neuen Area geleitet werden sollen. es muß eine
existierende Area vom MailManager sein.
Bsp.: #ANNOUNCEAREA PmnS.Info
#ANNOUNCEAREA Amy_Newfiles.Ger
#ANNOUNCEAREA AMYREQ.Ger
[....]
5.12.1 '%' Befehle in (Report.txt) | (Area.HDR)
-----------------------------------------------
Mit den '%' Befehlen kann der Report-text und Area-Header
fuer neue AREAS und Newfiles an deine Beduerfnisse angepasst werden.
Moegliche Befehle :
%AR Name der neuen AREA
%LE Level der neuen AREA
%GR Group der neuen AREA
5.13 #FILEREQUESTSERVER [FFRS|NONE]
---------------------------------------
Hiermit können neue Areas gleich dem FileRequestserver FFRS mitgeteilt
und freigeschaltet werden. Die .CFG von FFRS wird, sofern der Pfad bei
#REQUESTSERVERCFG angegeben ist automatisch geändert.
Es existieren zwei Schlüsselworte, die sich gegenseitig ausschliessen:
FFRS - Neue Areas werden FFRS mitgeteilt und eingebunden
NONE - FFRS wird nicht beeinflusst.
Bsp.: #FILEREQUESTSERVER FFRS
5.14 #REQUESTSERVERCFG <Pfad>
----------------------------------
Wenn bei #FILEREQUESTSERVER FFRS eingetragen wurde, kann man jetzt den Pfad
zu der .CFG von FFRS angeben. Ansonsten hat dieser Eintrag keine Funktion.
Bsp.: #REQUESTSERVERCFG FFRS:FFrs_1.Cfg
5.15 #UNARC <Endung> <Packer> [Parameter]
--------------------
Packer um eingehende Mirrrorfiles zu entpacken.
Bsp.: #UNARC LHA C:Lha x -E
5.16 #LONGDESC [DESC]
---------------------
Beschreibung fuer Readme-files
Bsp.: #LONGDESC Long Description for
5.17 #AREAMODE <LONG|SHORT>
---------------------------
AreaMode ist ein Schalter, um neue Areas in zwei Versionen zu generieren.
SHORT = COMM.BBS
LONG = AMINET.COMM.BBS
Bsp.: #AREAMODE LONG
5.18 #CREATEFILELIST <YES|NO>
-----------------------------
Die Funktion ist der Schalter,fuer das Posten der Newfiles nach dem Hatchen
Bsp.: #CREATEFILELIST YES
5.19 #FROMSYSOP [Name]
----------------------
Die Funktion fuegt einen Absender zum Newfiles-Announce
Bsp.: #FROMSYSOP MM_Amihatch
5.20 #ANNOUNCEFILELIST <Area><Betr>,<Empf>,[Header],[Footer]
-------------------------------------------------------------------
Announcen der Newfiles in den angegeben Areas.
Area = Area, in die, die Newfiles gepostet werden sollen
Betr = Betreffzeile fuer die Newfiles
Empf = Empfaenger der Newfiles z.b. (All, Alle...)
Header = Path zum Header der Newfiles
Footer = Path zum Footer der Newfiles
(Jeder Befehl MUSS durch ein komma ',' getrennt werden)
Bsp.: #ANNOUNCEFILELIST Amy_Newfiles.Ger,Aminet
Newfiles,All,MM:Config/MM_Amihatch/Aminet.Header,MM:Config/MM_Amihatch/Aminet.Fo
oter
#ANNOUNCEFILELIST PmnS.Newfiles,Aminet Newfiles der PmnS,All,,
[....]
5.21 #TICKCOMMAND <Befehl>
-------------------------------------------------------------------
Diese Funtion bindet automatisch einen TickCommand fuer neue Areas in MM
ein.
Bsp.: #TICKCOMMAND AMINET
6. Ackknowledgements
====================
Hier der Dank an die, die dieses Script ermöglicht haben :
Pino Alberti - Für seinen superben MailManager...
Robert Hofmann - Für seine pionierhaften Leistungen in der MM
ARexx-Programmierung und den damit verbundenen Inneren
Antrieb und guten Tips für das Programm ...
Cord Moeller - Für das Tippen der Docs und das Beta-Testing (auch
für die
lästigen Feature-Requests ?!)
Erich Weidner - Für seine Feature-Requests und Beta-Testing
Andreas Netscher - Für seine Feature-Requests und Beta-Testing
Sven Matthias - Für seine Feature-Requests und Beta-Testing
|
