[Allegro] Etwas zum Testen: "acon -j update.job" als Ersatz fuer UPDATE.EXE

[Bernhard Eversberg]

Am 30.05.2011 19:02, schrieb Thomas Berger:
> mit 11 Monaten Abstand habe ich nach srch.job nun auch update.job
> so ueberarbeitet, dass es nun (vorbehaltlich der in den letzten
> Tagen gemeldeten Detailprobleme) UPDATE.EXE ersetzen kann.
Verdienstvolle, dankenswerte Tat, ganz ohne Zweifel. Jedoch,
hat ja länger gedauert als jede Schwangerschaft. Wenn wir so
arbeiten würden ...

> [Nachricht an Herrn Eversberg: Durch konsequentes Auslagern von
> Code ist es gelungen, update.job auf knapp unter 1000 Zeilen
> zu begrenzen, damit ist er nur 3mal so aufgeblaeht gegenueber
> dem "Original", bei srch.job letztes Jahr war ja ein Monitum,
> dass es viermal mehr Zeilen als urspruenglich hatte]
Das ist natürlich reine Vergackeierung, denn ohne den
ausgelagerten Code geht's ja nicht. Außerdem sieht die
Dokumentation von  getopts.jnc  zwar üppig aus, läßt einen
aber doch im Stich, wenn man wissen will, was man wie
aufrufen kann und was man dabei rauskriegt. Der wahre
Gesamtumfang sagt also denn immer noch nicht so viel,
wiewohl er unsere Version enorm übersteigt.
Die Verbosität der Namen steht weiterhin in schlechtem
Verhältnis zum Umfang des Kommentars; sog. "sprechende"
Namen sprechen ja meistens wenig mehr als die Sprache
des jeweiligen Programmierers, die sich dem externen
Leser eben durchaus nicht von selber erschließt,
von der Funktionalität zu schweigen, zu der wenig
Worte verloren werden. Aber das ist in der ganz normalen
(ja auch nicht eben wortkargen) Java-Praxis z.B. auch nicht besser.
Warum man zusätzlich zur Variablen $ARGV:k noch eine
Kopie unter dem Namen  $OPTS.Konfiguration  brauchen sollte,
bleibt mir unerfindlich, um nicht zu sagen extrem betulich.
Und der eine Name mit :, der andere mit . als Trenner, was
ist denn damit gewonnen?
Ist doch alles nur für die (i.d.R. kurze) Laufzeit des Jobs,
nicht für den Kontext eines viel größeren Ganzen. Man wünscht
sich etwas mehr Augenmaß für die Verhältnismäßigkeit.
> Ich habe allerhand Tests zur Funktionsweise und zu Aufrufarten
> vorgenommen, aber leider beileibe noch nicht systematisch
> die Kompatibilitaet zu UPDATE.EXE durchgetestet. Vor dem
> Einsatz im Produktivbetrieb wird daher ausdruecklich gewarnt,
> allerdings bin ich dankbar fuer Hinweise auf Fehler und/oder
> Abweichungen solcher Art, dass etwa das Ausgabeformat so stark
> abweicht, dass vorhandene (insbbesondere automatische) Auswertungen
> nicht mehr funktionieren.
Lassen wir also im nächsten Release mal noch unsere
unzulänglichen und viel zu mageren Versionen drin. Für den
Normalanwender tun sie's wenigstens.

> Bekannte Abweichungen zu UPDATE.EXE
>
> * acon-Gemaess ist auch das Update von .adt-Dateien moeglich
Das ist natürlich gut.
> * Die Statistik am Ende von UPRO liefert konsistente Ergebnisse
> * Die Statistik am Ende von UPRO sagt konstant: 0000 Schluessel
>    geaendert
> * Schalter --help, --debug, --verbose und --quiet
> * Nicht vorgesehene Schalter gelten als Fehler
Mit der Konsequenz des Abbruchs?
> * Animation nach STDERR anders
Animation?
   ---------------------------------------------------

Nicht klappen kann übrigens dieser dem Kenner gleich
ins Auge stechende Kommentar

   // hier z.B. die Kombination -fm00 mit #u1  @@@@@ abzufangen

weil die Zeichenkombination  @ Spatium  als Beginn einer
den Job abschließenden Datenbankanwahl betrachtet wird.
Klar, da sind eigentlich wir gefordert, denn besser
wär's, das wäre nicht so.
(Wahrscheinlich hat er das aber reingeschrieben, um zu
schauen, ob überhaupt jemand das Ding ausprobiert...)
B.E.