[Allegro] acon: include und relative Pfade

[Anando Eger]

Lieber Herr Berger, Herr Eversberg und alle, die mitlesen:

zum Thema 'include':

- 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

- 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
    ...

- 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)

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

Viele Grüße
Anando Eger


On 28 May 2011 at 17:45, Thomas Berger wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Lieber Herr Eversberg,
> 
> das include-Makro (eine Anweisung ist es strenggenommen ja nicht) von acon
> berechnet Pfade relativ zum aktuellen Arbeitsverzeichnis, insbesondere
> wird eine ohne Pfad angegebene include-Datei nur im aktuellen Verzeichnis
> gesucht.
> 
> Dokumentiert ist in xinclude.rtf "Für avanti  muß  dateiname  auf dem
> Arbeitsverzeichnis von  acon  oder darunter liegen.", zu konstatieren
> ist allerdings, dass relative Pfade mit "../" auch funktionieren:
> Sicherheit ade.
> 
> Bei der Einfuehrung des Features schrieben Sie am 14.6.2010 (es dauert
> halt immer zu lang, bis das dann ernsthaft umzusetzen versucht wird):
> >>>
> OK, ist jetzt drin. Berücksichtigt werden kann nur der Startpfad von
> acon, denn beim Einlesen des Jobs, wenn eine include-Zeile kommt, weiß
> ja acon noch nicht, wo der Datenpfad ist!
> <<<
> 
> Dass damit das Datenverzeichnis nicht als Ort fuer Include-Dateien
> infrage kommt, leuchtet ein. Das Avanti-Arbeitsverzeichnis in
> Web-Umgebungen ist ein eher unbekanntes Wesen, das haengt davon
> ab, wie der Systemdienst installiert wurde und dafuer gibt es
> keine Eroerterungen oder Dokumentation...
> 
> Im Licht einer acon-Nutzung als Ersatz fuer SRCH und UPDATE ist das
> Arbeitsverzeichnis traditionell moeglichst kein Verzeichnis, in dem
> Programmdateien vorgehalten werden, sondern eher eines, wo Ergebnisse
> abgelegt werden. In dieser Situation speziell ist auch, dass der Job nicht
> ueber STDIN hereinkommt, sondern ueber -j als Datei auf der Kommandozeile
> angegeben ist.
> 
> Es waere zwar ein ziemlicher Bruch mit der bisherigen Tradition von
> Programm-, Arbeits- und Datenverzeichnis, aber bei CSS, XSLT und HTTP
> habe ich gute Erfahrungen mit dem dort durchgaengigen Mechanismus
> gemacht, dass sich relative Pfade stets auf die Adresse der aktuellen
> (einbindenden) Datei beziehen: Ihr Ersteller weiss zwar nie im
> Voraus, wohin irgendjemand sie ablegen wird, es kann allerdings
> erwartet werden, dass zusammengehoerende Dateien in einem bestimmten,
> vom Ersteller vorgegebenen Layout (etwa: alle zusammen in ein
> Verzeichnis) abgelegt wurden. (In Java ist es m.E. auch aehnlich,
> da gibt es den "ClassPath").
> 
> Wenn der einbindende Job ueber STDIN hereinkommt, waere sein Speicherort
> dann ganz zwanglos das aktuelle Arbeitsverzeichnis von acon...
> Man koennte allerdings auch noch einmal darueber nachdenken, was eigentlich
> mit dem "etc"-Verzeichnis der avanti-Installationen intendiert gewesen
> ist bzw. ob nicht das Verzeichnis, indem die genutzte avanti.con[f]
> liegt, einen konzeptionell guenstigeren Ausgangspunkt fuer relative Pfade
> darstellt.
> 
> Ein zukuenftiges Problem wird dann die Einbindung von Standard-Includes
> sein, ein Job setzt ihre Existenz voraus, sie werden aber separat
> installiert / gehoeren zu anderen "Paketen": Hier erfolgt dann normalerweise
> absolute Adressierung (als URI), und im Fall von XSLT und anderen gibt
> es dann optional den XCatalog-Mechanismus, der diese URIs auf lokale
> Speicherorte zurueckbiegen kann. Fuer allegro waere dies alles eher
> uebertrieben, man koennte aber ueberlegen, ob absolute Pfade der Form
> include /paket/helper.inc
> sich nicht auf ein Zentrales Ausgangsverzeichnis (Programmverzeichnis?,
> Ort von avanti.con[f]?, ...) beziehen koennten. Ich fuerchte allerdings,
> dass Herr Fischer Wert darauf legt, echt absolute Adressierung zu
> bekommen, wie in
> include //server99/C$/avanti/test.inc
> 
> Ich habe den Eindruck, Includes fuer acon-Jobs koennen ein sehr maechtiges
> Werkzeug werden und es gibt noch nicht besonders viele davon im produktiven
> Einsatz: Die Gelegenheit waere also guenstig, hier einen fuer die Zukunft
> tragfaehigen Mechanismus auszudenken.
> 
> viele Gruesse
> Thomas Berger
> 
> P.S.: Wie heissen die Dinger eigentlich: Fuer Flex-Dateien hat sich .inc
> als Extension etabliert, Aber Job-Includes sind ja nicht a priori kompatibel
> und sollten m.E. etwas abweichend benannt werden: .inj, .jnc, .jinc, .jbinc,
> .jobinc, .job.inc, .inc.job ?
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iJwEAQECAAYFAk3hGJ0ACgkQYhMlmJ6W47N6DwQAjH3dfJSKf/U3b1IZk0mC8y1k
> IWeRjwmRko6oK4jEu8EHJDufW+B3kFqoODWxL5UWVGlE3esHKmwf4InU7iEYT2uR
> VmcOSfFgkUOGzvFMfnVZ4KDmkZZEsV7Ik7naaEwsfHP+CT4XpbKeMi3VCJ8B6QLc
> WAzcHm3J2CYG+rqKWhs=
> =8+aD
> -----END PGP SIGNATURE-----
>