[Allegro] acon: update.job statt update.exe (16bit)

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

> Und es kommt ganz genau dasselbe raus. Wie es ja auch soll und wie wir
> schon vor der ersten Verabschiedung von  update.job  in längeren Test-
> reihen erreicht hatten.
> 
> Aber ok, die Differenz zwischen update.exe und update.job hinsichtlich
> der Optionen -b und -d ist störend. Wir werden das noch so verbessern,
> daß man wahlweise -d und -b genau wie bei update.exe angeben kann.
> Damit wird dann  acon -jupdate ...  zum drop-in-replacement für
> update.
> (update.job kümmert sich übrigens nicht um  -d und -b , die
> wertet acon selber aus! Deshalb müssen wir acon verbessern, nicht
> update.job. Aber in der oben gezeigten Form geht es schon jetzt.)

Klar ist, dass -b zentral fuer acon ist (bei SRCH war die Angabe einer
Datenbank optional: manchmal implizit, manchmal unnoetig; acon hingegen
benoetigt stets eine funktionsfaehige Datenbank um zu starten, da sind
dann die Grenzen des Schematischen Umzugs von SRCH- zu acon-Aufrufen).

Jedenfalls: Der *Schalter* -b von acon ist - wie bei SRCH - die volle
Angabe der Datenbank, also Pfad und Name. Die *Umgebungsvariable* -b
ist hingegen traditionell nur der Name (entsprechend der traditionellen
Nutzung des Schalters -b bei UPDATE; wegen der Diskrepanz hat das
Handbuch im Kapitel 12.1 auch zwei Eintraege fuer -b).

Beim *Schalter* -d gibt es eine aehnliche Schere, er bezeichnet ein
Verzeichnis oder ein Namensmuster (fuer Dateien in einem konkreten
Verzeichnis), die Umgebungsvariable -d spezifiziert hingegen stets ein
Verzeichnis.

Die acon-Verbesserungen der letzten Monate haben m.E. folgendes Resultat
gebracht, das sich eigentlich als Satz von Regeln zur Konstruktion eines
funktionsfaehigen Schalters -b formulieren lassen sollte:

1. Gibt Schalter -b *Pfad und Namen* einer bestehenden Datenbank (Test
 auf .tbl?) (relative Pfade beziehen sich auf das Arbeitsverzeichnis oder
 werden bei diesem Test nur Pfad mit Laufwerksbuchstaben beruecksichtigt??)
 an, dann wird diese genommen => Fertig

2. Laesst sich aus Schalter -d Pfad und Name einer Datenbank ableiten
 (traditionell fehlerbehaftet, da .alg-Dateien als Quelle ohne Extension
  angegeben wurden), nimm diesen. (Was sind genau die Ableitungsregeln:
  "_" in der letzten Pfadkomponente? Was ist [und war], wenn der Schalter -b
  einen Namen angibt, der dazu im Widerspruch steht??)

3. Ist Schalter -d ein Verzeichnis (evtl. relativ zum Arbeitsverzeichnis?),
  und
 a) Schalter -b gegeben
  oder hilfsweise
 b) Umgebungsvariable -b gesetzt
  so nimm -d und -b zusammengefasst

4. Ist Schalter -d nicht gegeben, stelle die Betrachtungen bei 3. fuer
  die Umgebungsvariable -d an.

[3. und 4. laesst sich wohl aequivalent zusammenfassen, indem unabhaengig
zunaechst -d und -b bei Bedarf aus dem Environment ergaenzt werden und
der Test auf die Zusammenfassung der Resultate angewandt wird]

Waere das ein Algorithmus, der moeglichst viele existierende sowohl SRCH-
als auch UPDATE-Aufrufe fuer acon behaltbar macht?

Wie muessten die durch "?" gekennzeichneten Kriterien konkretisiert werden?

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAkxhBWYACgkQYhMlmJ6W47MetAP+NzOaWZW+msPq1mUPKHJh0LeC
pkextpfo/T+/5OzykmwPaYJadV9A91f3F2t4aY5UMMoq6Q9p9Lq413lRCQTluFiD
W6nj4ZPX5HUdYFvR6VdabtzUF9IwIyZf5Ai+fhcYYhcuxR+/vIMkVUJKm1puTw2I
za+yN/7iieJRw7BOAk8=
=CE0Q
-----END PGP SIGNATURE-----