[Allegro] acon: include und relative Pfade

[Thomas Berger]

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

Lieber Herr Eger, liebe Liste,

> - Wie wäre es, wenn include die CSTRING- Pfadangaben berücksichtigen 
>   würde?
> 
>   Beispiel: include {D}flex.inc 
>   oder:     include D flex.inc  // dann dürften aber keine Leerzeichen
>                                 // in Dateinamen zugelassen werden

wir hatten das hier letzten Juni oberflaechlich andiskutiert, es
war nicht klar, ob datenbankspezifische Includedateien unbedingt
benoetigt werden (man kann im Job ja alles moegliche an *Daten*
aus dort liegenden Dateien zur Laufzeit einlesen), aber es war
auch nicht klar, ob man a priori darauf verzichten koennen will.

Die Argumentation von Herrn Eversberg war wohl, dass zuerst die
Jobdatei eingelesen und dann die Datenbank anhand der Kommando-
zeilenschalter ermittelt und geoeffnet wird. Das sind m.E. Zwaenge,
die aus der Zeit der Avanti-Jobs stammen, wo ueberhaupt erst die
allerletzte Zeile des Jobs eine Aussage zur Datenbank gemacht
hat. Stellt man sich zukuenftige Flexibilisierungen vor, bei denen
der Job das ob und wie des Datenbank-oeffnens staerker steuern kann,
so waere es allerdings auch ganz sympatisch, weiterhin zuerst den
Job und dann die Datenbank zu oeffnen.


> - bei Wahl der Dateinamenserweiterungen fände ich es gut, wenn
>   auch bezüglich des Inhaltes unterschieden würde:
>   * Bibliotheken (enthalten nur Unterprogramme)
>     Beispiel:
>     ...
>     perform Fn_XX
>     ...
>     end
>     include fn_XX.???
>  
>   * "Code-Schnipsel": Code wird an der include-Position eingefügt
>     und genau dort abgearbeitet.
>     Beispiel:
>     ...
>     include drei_zeilen_flex.inc
>     ...

und die acon-Variante mit gleicher Funktion und leicht abgewandelter
Syntax dieser drei Zeilen heisst dann wie?

Es gibt (etwa winstart.flx) auch Dual-use-code, der als Unterprogramm
eingebunden werden kann, aber auch per exec fuer sich ausgeloest.
Und es gibt Fragmente, die so geschrieben sind, dass sie als Unterprogramm
einkapselbar sind:

var "123"
perform meinlabel
...

var "abc"
  // falle in den naechsten Block

:meinlabel
include fragment.xyz
return

  // weiter im Text, was hat das Fragment gebracht?
ins $

Auch bei a99 ist es manchmal etwas willkuerlich, ob eine Datei .flx oder
.inc heisst, weitere Differenzierung wuerde es aber wohl noch komplizierter
machen und waehrenddessen kein Problem loesen.




> - Momentan muss man, wenn includes unter LINUX unterhalb des acon-
>   Verzeichnisses funktionieren sollen, avanti ohne Pfadangabe
>   in seinem eigenen Verzeichnis starten. (-> Start- / Stop-Scripte)
>   Ließe es sich irgendwie einrichten, dass auch bei avanti-Start
>   mit Pfadangabe aus einen unbekannten Verzeichnis heraus
>   auf den Programmpfad (oder einen anderen) referenziert werden kann?
> 
>   Eventuell über '& {P}' oder ähnlich im acon-Job?
> 
>   (Alternative zum ersten Anstrich)

Wenn ich mich recht entsinne, wird bereits beim Start von Avanti
nach allen moeglichen Dateien in "." und "../etc" gesucht: Das
toleriert eine gewisse Unschaerfe im Startverzeichnis. Die Praeferenz
scheint in Richtung "das Verzeichnis, wo avanti liegt" zu gehen,
mein Vorschlag gestern war, "das Verzeichnis, wo die Konfigurations-
datei liegt" auszuzeichnen, in der Praxis ist das eine "bin" und
das andere "etc" und im inst-all-Kontext ist beides das bekannte
Programmverzeichnis...


> - Absolute Pfade in der &-Zeile der Jobdatei sind in Client-
>   Server-Umgebungen nicht verwendbar.

Herr Fischer ist da glaube ich anderer Meinung...
Auch das hatten wir m.E. letzten Sommer hier diskutiert, weil ich
die "&"-Zeile nie genutzt habe weiss ich nicht, ob hier absolute
Pfade inzwischen technisch unterbunden werden oder ob sich nur
der Konsens darueber verbreitert hat, dass dort absolute
Pfadangaben wenig tragfaehig sind.

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

iJwEAQECAAYFAk3iwZQACgkQYhMlmJ6W47Pa7QP+Ku/dD+K5Qw9KrBe5e+eIYvSC
UhbnnSUYEwfuWwuUAmlGMTYsglvsN2YtYRrJH6xDpgiMENZH0UrPFbUUYCFv+Z5l
trF6cx/LvxX0zS3NS2BVyeElJF1vec0bvhB/F6VN9i85rWLMXs52iosN+ShViDll
PqPpWL2/hzNVVOMidmQ=
=+qRZ
-----END PGP SIGNATURE-----