Short: MM_AmiHatch v0.59 Hatch Mirrorfiles via MM Author: McB@Fido.de ( Ulrich Lammers PmnS BBs ) Uploader: aliberti mbox vol it (Pino Aliberti) Type: comm/mmgr Version: 0.59 Replaces: comm/mmgr/MM_Amihatch.lha Architecture: m68k-amigaos 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.0@FidoNet 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 [ ...] ------------------------------------------------- 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 /A ---------------------------- Dieses ist die Absende-Adresse des Systems für die TIC-Files. Bsp.: #HATCHNODE 39:178/1.0@AmiNet 5.8 #GROUP ------------------------ 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 --------------------- 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 ------------------------------------- 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 ---------------------------------- 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 ---------------------------------- 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 [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 --------------------------- 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 ----------------------------- 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 ,,[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.Footer #ANNOUNCEFILELIST PmnS.Newfiles,Aminet Newfiles der PmnS,All,, [....] 5.21 #TICKCOMMAND ------------------------------------------------------------------- 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