🚀 go-pugleaf

Im Artikel <H.ns4imHWBT5M@atab.cpr.sub.org> schreibt joscha@atab.cpr.sub.org (Joerg Schaefer):
> 
> Hin und wieder faellt der Begriff 'Hamburger Standart' ueber mich her.
> 
> Nun aber meine Fragen:
>     1) Wo bekomme ich die 'SPECxx.TXT' her, welche in versch. Dokus

 Ich poste den Text einfach mal..

 Gruss,
 Lutz

#---- Hamburger Standard-Beisskante -----------------------------------|


            Versuch, die Mercury- und andere Programmierer unter
            einen Hut zu bekommen.
            Revision 1.4 - Tue, 13 Nov 90 15:44:08 (bkr)
            Revision 1.5 - Tue, 01 Jan 91 21:20:30 (bkr)
            Revision 1.6 - Wed, 16 Jan 91 16:13:22 (bkr)

            Aenderungen bzgl. Revision 1.5:


            Aenderungen bzgl. Revision 1.4:
            01.31)  Delimiter in der passwd


            Aenderungen bzgl. Revision 1.3:
            01.10)  Signature-Datei

            01.21)  $PATH jetzt Pflichtvariable
                    $HOME neu aufgenommen

            01.31)  passwd Pflichteintraege
                    Bedeutung des 'homedir' Feldes

            01.50)  In eigener Sache

----------------------------------------------------------------------------

01.00)  KURZE KLARSTELLUNG DER SITUATION
----------------------------------------

Jan Willamowius und ich haben uns eine Art Standard fuer zukuenftige UUCP
Software auf dem ST definiert. Die Definition ist so gehalten, dass Module,
die danach entwickelt sind, auch mit Mercury Modulen zusammen einsetzbar
sind.

Ein Grundgedanke war, in Zukunft ohne die CONFIG.SYS oder andere feste
Configfiles auszukommen und die Programme und deren Directorystruktur
stattdessen flexibler ueber das Environment konfigurieren zu koennen.
Weiterhin soll, soweit wie mit TOS moeglich, an Unix Standards
herangegangen werden.

Fuer etwaige Frechheiten / Unstimmigkeiten / grobe Dummheiten im Text
bin ich verantwortlich. Faule Kompromisse gehen auf unser beider Konto.
Flame on.

Kommentare bitte an uudef@drdhh.hanse.de, das ist ein lokaler Mailverteiler,
der die Leute bedient, die hier an diesem Papier mitgedacht haben.
Wir werden die Vorschlaege gleich einarbeiten oder als Summary in
mercury.allgemein posten und diskutieren.

Groessere Aenderungen an dieser Definition sind im Prinzip nicht
erwuenscht, da grosse Teile davon schon implementiert sind.
Wichtig ist fuer Jan und mich aber auch, zu wissen, wie gross die
Akzeptanz / Bereitschaft bei den Usern und bei den Co-Programmierern
des Mercury Systems ist, sich an diesen 'Standard' anzupassen und
ihn zu unterstuetzen.

Here we go:

----------------------------------------------------------------------------

01.10)  DIRECTORYSTRUKTUR
-------------------------

Die Directorystruktur ist so aufgebaut, dass die Hauptdirectorys,
womit ich hier ETC, USR und NEWS meine, ueber Environment-Variablen
plaziert werden koennen, aber nicht muessen. Sind die entsprechenden
Variablen $ETC, $USR nicht gesetzt, dann werden diese Directories
jeweils im Rootdirectory des aktuellen Laufwerks erwartet.
(NEWS wird dann als \USR\SPOOL\NEWS angenommen)
Somit kann der recht speicher- und fragmentierungsintensive Spool/
Newsverkehr auf ein anderes Laufwerk abgewaelzt werden.

Unterhalb von $USR bzw. \USR ist folgende Struktur vorgeschrieben:

USR----+----SPOOL---+----MAIL                     Mailfiles / Mailerdaten
       |            |
       |            +----MQUEUE                   Eingehende Daten
       |            |
       |            +----UUCP-----+-----SITE_1    Ausgehende Daten
       |                          |
       |                          +-----SITE_2
       |                           ....
       |
       +----LIB-----+----NEWS                     active.ix sys
       |            |
       |            +----MAIL                     paths / aliases / bsmpt
       |            |
       |            +----UUCP                     commands [systems]
       |
       |
       +----ADM                                   logfiles
       |
       +----DOC                                   dokumentation


ETC----+----PASSWD
       |
       +----TERMCAP
       |
       +----HOSTS

Im ETC Directory befinden sich die PASSWD, das HOSTS-File im
Mercury-Format und (im Bedarfsfalle) die TERMCAP sowie weitere Infofiles.

Das HOSTS File enthaelt die Maschinendefinitionen nach Mercury-Art.
Es wird spaeter durch ein 'systems' File in $USR\lib\uucp ersetzt,
das dem HDB Format entspricht. Dieses File wird allerdings erst dann
wichtig wenn es einen 'vernuenftigen' uucico gibt.

Das Standard-Signature (betrifft Mailer und Postnews) liegt in
der Datei 'SIGNATUR' im Homedirectory, wobei Homedirectory nicht
die Angabe in der passwd sondern $HOME meint.

----------------------------------------------------------------------------

01.20)  ENVIRONMENT
-------------------

  01.21)  Unbedingt notwendige Variablen
  --------------------------------------

          $USER       LoginName des momentan aktiven Users
          $SITENAME   Name der Maschine, OHNE Anhaengsel
          $HOME       Users Homedirectory, unabhaengig von
                      der Angabe in der Passwd

          $TMP        Eine von diesen vieren muss gesetzt
          $TEMP       sein und den Pfad des Temporaerdirectory
          $TMPDIR     enthalten.
          $TEMPDIR

          $PATH       Pfad, in dem nach ausfuehrbaren Programmen gesucht
                      wird. Die Liste der Directories darf entweder durch
                      Komma, durch Semikolon oder durch Space getrennt sein,
                      z.B.: D:\TC;D:\BIN;E: - damit sollten die Anforderun-
                      gen der verschiedenen Shells abgedeckt sein.
                      Programme, die weitere Programme nachstarten,
                      muessen diese via $PATH suchen.
                      Die Standardextensions sind TOS, TTP, PRG und APP.
                      Programmen, die auf .PRG oder .APP enden, muss
                      die passende Umgebung (Maus, Hintergrund) zur
                      Verfuegung gestellt werden.

                      Programmstarts und andere Shell-Angelegenheiten
                      duerfen nicht per system() ausgefuehrt werden, da
                      es an einigen Stellen (Behandlung von GEM-Prgs,
                      Quoting von ! und @) doch erhebliche Unterschiede
                      zwischen den Shells gibt. Ausserdem laesst diese
                      Einschraenkung es zu, seinen Mailer mal eben vom
                      Desktop zu starten.

                      Die exec Routinen MUESSEN den Atari Standard fuer
                      Extended Arguments unterstuetzen.
                      Der Startupcode standardgemaesser Programme muss,
                      wenn er die ARGV Methode schon nicht benutzt,
                      zumindest die ARGV Variable aus dem Environment
                      loeschen, damit nachfolgende Programme keinen
                      Muell vorfinden.

                      Entsprechende Routinen (exec, startup) habe ich
                      fuer Turbo C schon fertig - wird es dann auch in
                      Source geben.

                      Meine Routinen arbeiten mit einer weiteren Variablen,
                      um den Atari Standard auch mit Shells benutzen zu
                      koennen, die den Magic-Wert in der Basepage (127
                      als c_tail Laenge) nicht richtig setzen:
                      if(getenv("N127"))  /* gesetzt ? */
                        <ARGV auf jeden Fall benutzen>
                      else
                        <Voll nach Atari-Konvention>


  01.22)  Optionale Variablen
  ---------------------------

      Diese Variablen koennen gesetzt werden und MUESSEN von Pro-
      grammen, die sich an diese Vorgaben halten, auch ausgewertet
      werden. Bei jeder Variablen ist der Defaultwert angegeben,
      der benutzt wird, wenn sie nicht gesetzt ist.

      $ETC          Siehe 01.10), Default \ETC

      $USR                "          "    \USR

      $NEWS               "          "    $USR\SPOOL\NEWS


      $DOMAIN       Die Domain, in der sich die Maschine befindet,
                    und zwar mit fuehrendem Punkt
                    Beispiel: '.hanse.de'
                    Default: .UUCP

      $TZ           Zeitzone, in der die Maschine sich befindet.
                    Default: MEZ

      $ORGANIZATION nun ja... wie der Name halt sagt...
                    Default: Leerstring
                    Programme muessen auf den Leerstring testen und
                    gegebenenfalls das Feld aus dem Header streichen.


      $EDITOR       Der hier gegebene String wird in $PATH mit den
                    oben angegebenen Extensions gesucht, wenn in einem
                    Programm ein Editor nachgestartet werden soll.
                    GEM - Programme werden korrekt gestartet.
                    Default: tempus

      $PAGER        Siehe oben, wenn ein Text gelesen werden soll
                    Default: guck
                    PAGER muss nicht immer ausgewertet werden, an
                    einigen Stellen, z.B. vn ist es fast unmoeglich,
                    einen anderwen als den eingebauten zu verwenden.


  01.23)  Variablen, deren Auswertung optional ist
  ------------------------------------------------

  Bei Programmen, die diese Variablen benutzen, sollte jenes
  in der Dokumentation erwaehnt sein.
  Ist besonders fuer Unix Portierungen interessant, ich wuerde mich
  aber freuen, wenn viele Leute diese Funktionen auch in ihren eigenen
  Programmen benutzen, da ich meine News / Mail ganz gerne morgens vor
  dem Aufstehen per HP-Terminal am Bett lese. Die Dekadenz greift um sich.
  Ausserdem kann dann mit Termcap-Routinen, die demnext noch von mir
  gepostet werden, ein Programm ohne jede Aenderung in Gemini-Fenstern
  laufen, indem man $TERM=gemini setzt, die termcap-Routinen lesen dann
  das Environment der Gemini aus, um die Windowgroesse zu erhalten.

      $TERMCAP      Mit dieser Variablen kann festgelegt werden, welche
                    termcap von Programmen, die nicht nur auf der Console
                    laufen, benutzt wird.
                    Default: ETC\termcap

      $TERM         Hier kann der Terminaltyp eingestellt werden.
                    Default: st

----------------------------------------------------------------------------

01.30)  FILEFORMATE
-------------------

  01.31)  passwd Format

          username:crypted password:uid:gid:realname:homedir:loginshell

          Die Scan-Routine muss bei dem homedir-Feld eine Sonderbe-
          handlung durchfuehren (name:D:\dir:).
          Die Entscheidung zu Gunsten der Doppelpunkte statt Kommata
          ist auf dem CCC'90 zwecks Kompatibilitaet gefallen.

          Das password ist mit dem standard Unix Crypt verschluesselt.
          uid und gid sind aus Gruenden der IX-Kompatibilitaet und
          fuer Mailboxbetrieb vorgesehen. Die einzigen ID's, bei denen
          man Annahmen taetigen kann, sind die Nullen.
          (Rootuser / Rootgroup)

          Das Feld Realname kann noch mehr Felder beinhalten, diese
          sind dann durch | abgetrennt.

          Das hier angegebene Home-Directory gilt fuer Login-Prozeduren
          oder aehnlich, fuer Referenzen auf Files sollte $HOME benutzt
          werden.

          Die Loginshell wird in $PATH gesucht.

          passwd Routinen werden ebenfalls im Source zur Verfuegung
          gestellt.

          Die passwd MUSS folgende Eintraege enthalten:
          uucp,<password>,<uid>,<gid>,uucp@site,...\usr\spool\uucp,<loginshell>
          postmaster,<password>,<uid>,<gid>,PostHuhn,<homedir>,<loginshell>

          Der uucp Account dient dem Verschicken von Systemmails,
          er wird von DI Programmen gebraucht.
          Postmaster fungiert allgemein als Verwalter fuer Mail und
          News.

  01.32)  TERMCAP - voll Unix, siehe dortige Doku

  01.33)  LOGFILES

          Jede Zeile eines Logfiles sollte mit einer solchen Sequenz
          anfangen: 02 Aug 90 04:13:00
          Damit wird automatische Auswertung der letzten drei Tage
          bzw. automatisches Expiren der Logfiles moeglich.
          was nach der Uhrzeit kommt ist vollkommen egal, nett waere
          es, wenn dort noch irgendwo der Wochentag staende, damit
          die Files auch Human-Readable sind :-).

          >>>> set language english <<<< d.h Oct/Thu, nicht Okt/Do

          Eine weitere gute Idee waere es, Zeilen, die Fehler oder
          Warnungen signalisieren mit einem ! anfangen zu lassen.

          z.B:
          02 Aug 90 04:13:02 voellig normale aktion
          02 Aug 90 04:13:02 ! Warning: blahblah

          Dann kann Mensch sich auch automatisch ueber evtl. Probleme
          informieren lassen.

          Ein lfprintf, der vor jede Ausgabe obiges Format setzt ist
          fuer Turbo-C vorhanden.

  01.34)  ACTIVE.IX

          Das Fileformat des Unix-Style active-Files ist folgendes:
          <newsgroup> <last> <first> <mflag>
          last und first sind die jeweils letzte bzw. erste Artikel-
          nummer, ausgedrueckt als fuenfstellige Zahl mit fuehrenden
          Nullen. mflag ist entweder 'y' wenn in einer Gruppe ohne
          Einschraenkung von allen Usertn gepostet werden darf,
          'n' wenn lokale User nicht in dieser Gruppe posten duerfen
          (Unix-Soft: im News ist FASCIST gesetzt) oder 'm' wenn die
          Gruppe moderated ist.

  01.35)  MAILFILES

          Mails werden nicht mehr als Einzelfiles gehalten (das ist
          nicht artgerecht) sondern a la Unix in einem File in
          USR\SPOOL\MAIL.
          Die Trennmarke ist die From_ Zeile, also jeweils die erste
          Zeile in einer Mail. Bei eingehenden Mails, die im Mailbody
          solche Zeilen enthalten, werden diese mit einem '>' escaped.

  01.36)  SIGNATUR

          Die Signature wird einfach drangehangt, es werden keine
          \n--\n generiert, wer die haben will -> ins SIGNATUR rein-
          schreiben.

----------------------------------------------------------------------------

01.40)  AUFRUFKONVENTIONEN
--------------------------

  01.41)  ANGABE VON OPTIONEN


      Es waere schoen, wenn jedes Programm bei verkehrtem Aufruf eine
      ausfuehrliche Usage von sich geben wuerde - nicht nur Unix-like:
      usage: blabla -qfjopguiwfhr1234567 files ...

  01.42)  AUFRUF VON REMOTE EXECUTION COMMANDS DURCH DEN UUXQT

    Kommandos, die von einer anderen Maschine im X-File angefordert
    wurden, werden (sofern sie im commands File zugelassen sind)
    folgendermassen aufgerufen:

    <progname> -z <stdinput> [parameter aus dem X-File ...]

    Fuer <stdinput> (Konvertierter Filename aus der I-Zeile)
    haben wir uns entschieden weil auch TOS 1.4 noch Probleme
    mit der Redirection hat.
    Programme, die die -z option erlauben, muessen jedoch von stdin
    lesen, falls -z nicht in der Kommandozeile auftaucht.
    Daraus folgt, dass ein Programm seine Eingabe immer nur einmal
    lesen darf. -> TMP-Files nehmen.

    Beim Aufruf werden vom uuxqt $UU_USER und $UU_MACHINE auf die Daten
    des Requesters gesetzt. Spart die Uebergabe per Kommandozeile und laeuft
    zumindest unter BNU genauso.

----------------------------------------------------------------------------

01.50)  IN EIGENER SACHE
--------------------------

    Vorweg:
    Wir wollen uns mit Sicherheit nicht wie der Software-TUeV oder wie
    die DIN-Ueberwacher auffuehren, wir haben lediglich Interesse an der
    Glaubwuerdigkeit dieser Definition.

    Programme, bei denen angegeben ist, dass sie diesem Standard folgen,
    sollten dieses dann auch durchgaengig tun.
    Wenn die Vorgaben nicht komplett eingehalten werden, dann schreibt
    bitte in die Doku einen kurzen Vermerk dazu.
    Es ist auch zu empfehlen, bevor ein Programm veroeffentlicht wird,
    nochmal dieses Textfile komplett zu lesen und die einzelnen Punkte
    abzuhaken, fuehrt auch beim Autor dieser Zeilen (bkr) immer wieder
    zu Aha-Erlebnissen :-). Jan schliesst sich bedingungslos an. :-)

    Es ist teilweise recht viel Arbeit, aber unsere Bemuehungen und
    unsere gemeinsame Entwicklung haben gezeigt, das dieser Aufwand sich
    letztlich in einer sehr angenehmen Modularitaet auszahlt, so dass
    das Baukastensystem, bei dem man sich seine favorisierten Steinchen
    zusammenstecken kann immer naeher rueckt.

    Weiterhin bitten wir darum, dass jeder, der vorhat, sich mit seinen
    Programmen an diese Konventionen zu halten, einmal eine kurze Mail
    an uudef@drdhh.hanse.de schickt, damit wir ueberhaupt mal wissen,
    wie hoch eigentlich die Akzeptanz ist.
    Auch (konstruktive) Kritik an der Form des Standards (zu restriktiv/
    zu schwammig) oder aehnlich ist gern gesehen. Ein Standard, an den
    sich nur drei Leute halten nuetzt recht wenig...

    Es waere auch nett, mal zu erfahren, was dann auf dieser Basis so
    programmiert wird. (Wir wollen keinen Softwarekatalog sondern einen
    Ueberblick) Auf dieser Basis koennte man auch eine Source-Boerse
    hochziehen, es existiert z.B. fuer Turbo-C ein komplettes Set aus
    Startup-Code und Library, das den Standard unterstuetzt und dem
    Programmierer eigentlich keinerlei zusaetzlichen Aufwand bringt,
    dafuer aber eine Menge Komfort (Hilfe, ich muss Doku schreiben).


    Gruss, Jan & Bjoern


Unix is a trademark of <you know who>