[Allegro] Vb.256 : Verbesserung bei Lokalen Ersetzungen im Export
Bernhard Eversberg
ev at biblio.tu-bs.de
Mo Dez 2 08:43:40 CET 2013
Verlautbarung 256 der Entw.Abt. 2013-12-02
-------------------------------
Der $ in lokalen Ersetzungen der Exportparameter
================================================
In der Vb255 wurde, wegen Termindrucks ohne vorherige Diskussion und
Ankündigung, eine u.U. wichtige Änderung beschrieben. Auf Gründe und
mögliche Auswirkungen wurde noch nicht eingegangen. Das wird hiermit
nachgeholt, mit der notwendigen erschöpfenden Gründlichkeit.
(Es mochte wie eine klammheimliche Nachbesserung aussehen, was
natürlich grober Unfug wäre.)
Der Kern ist: Auch das $-Zeichen ist nun ersetzbar, aber existierende
Parameter arbeiten ohne Änderung, außer in unlogischen Fällen. Dies
erzwingt leider eine eigenwillige Syntax, sollen bestehende Parameter
nicht entwertet werden. Abhilfe könnte evtl. ein neuer Befehl bringen.
ACHTUNG:
Standard-Anwender, die nicht selber parametrieren, brauchen nicht
weiterzulesen, sie sind nicht betroffen.
**********************************************************************
Vor allem ist wichtig: Die geänderte Wirkung ist vorerst nur in
a99/alcarta und acon eingebaut, noch nicht in srch, import und index.
Letzteres soll noch kommen. Sollte sich aber massiver und begründeter
Widerstand regen, dann nicht. Eigentlich hätte man dies vor der Fest-
schreibung der V33.5 tun sollen, nur war dafür keine Zeit.
Hinzuweisen ist ferner auf die Möglichkeiten der FLEX-Sprache,
die im "Trick 74" ausführlich behandelt sind:
http://www.allegro-c.de/tricks.htm#74
Außerdem gibt es schon beim Import eine eigene Möglichkeit, mit
dem $ umzugehen, siehe dazu den Fall 3. unten und in a99: h ac11-3
NUN ZUR SACHE SELBST, und zwar in zwei Fassungen:
(Vorausgesetzt werden Kenntnisse der Exportparametrierung.
Alle Beispiele wurden mit V33.4 und V33.5 verifiziert.)
***********************************************************************
A. Kurzfassung der neuen Möglichkeiten
--------------------------------------
Regel: Der $ am Anfang, also ,"_$..._..._" hatte bisher gar keine
Wirkung, jetzt schaltet er die bekannte Wirkung ab.
I.
Ersetzung des $ durch X: ,"_$$_X_" (X = beliebige Zeichenfolge)
Sonderfall X = ▼ Unterfeld-Dreieck (DOS-Code 31 / Win 178):
,"_$$_▼_"
Einzelfall: $x durch ▼x: ,"_$$x_▼x_"
II.
Ersetzung von $x durch $y: ,"_$$x_$y_"
III.
Ersetzung von A$B durch AXB: ,"_$A$B_AXB_"
mit beliebigen Zeichenfolgen A, X und B
Hinweis:
Was im Export, anders als mit FLEX, (noch) nicht geht, ist die
Schreibweise ^031 statt des Dreiecks.
***********************************************************************
B. Langfassung, falls jemand *alles ganz genau* wissen will
-----------------------------------------------------------
(incl. womöglich nie aufgetretener Fälle)
Vorrede
-------
In einem Manipulationsbefehl ,"_abc_XYZ_" war und bleibt das $-Zeichen
in XYZ ohne Sonderwirkung, in abc dagegegen hatte es eine Funktion,
aber NUR an der Position c, also z.B. ,"_ab$_XYZ_" Dann wurde "ab"
und alles, was noch folgte, durch XYZ ersetzt, d.h. der Rest des
Feldes wurde abgezwackt, im Beispiel also incl. "ab".
Ein $ an anderer Stelle innerhalb abc war schlicht nicht vorgesehen,
die Wirkung war zwar nicht undefiniert, aber unlogisch.
Zur der Zeit, als das Unterprogramm entstand, kam der $ innerhalb von
Datensätzen wohl kaum vor, wie auch immer. Daraus ergab sich:
Stand hinter dem $ noch etwas, also ,"_abc$d_XYZ_", dann hatte der $
keine funktionale Wirkung, sondern der Befehl änderte am Text nichts.
Insbes. konnte man leider mit der lokalen Ersetzung den $ als solchen
nicht ersetzen (s. dazu unten Fall 3. und oben Fall I.).
Desiderat war deshalb, das Zeichen $ auch als solches mittels lokaler
Ersetzung wie jedes andere Zeichen ersetzen zu können. Jedoch sollte
sich das Verhalten älterer Parameter nicht ändern.
Viel besser als das hier beschriebene Verfahren wäre es natürlich,
das ist zuzugeben, man hätte z.B. ein exakt dem Vorbild der regulären
Ausdrücke entsprechendes Paradigma. Dies könnte in die Exportparameter
leider kaum eingebaut werden, sondern allenfalls in FLEX. Vorerst
wird man mit dem nicht für jeden befriedigenden status quo noch eine
unbestimmte Weile leben müssen. SOLLTE sich eine Änderung realisieren
lassen, dann sicher nicht so, daß die bisherigen Befehle geändert
würden, denn dadurch wären dann bestehende Parameter entwertet, die
Kontinuität also gebrochen. Nur ein *neuer* Befehl könnte hier
*theoretisch* Abilfe schaffen. Und warum wurde nicht von vornherein
mit regulären Ausdrücken gearbeitet? Nun, wir kannten das damals nur
unter UNIX existierende Konzept gar nicht, als der Export 1986 in der
ersten und noch heute kompatiblen Fassung unter MS-DOS programmiert
wurde. Ein vollkalibriges grep ist u.U. gar nicht notwendig. Es gibt
eine sehr knappe, äußerst gute Implementierung der für uns wichtigen
Teilfunktionen [1], die als Neuerung begrüßenswert wäre. Darüber
kann man noch diskutieren, und eigentlich könnte das auch mal, die
Quellen sind ja offen, jemand anders machen.
Wie sieht es nun also aus ab V33.5?
-----------------------------------
Als Beispiel nehmen wir dieses Datenfeld:
#81 Text$Hinweis$ENDE
und wollen das $-Zeichen ändern und evtl. auch noch, was davor und
dahinter steht.
Was ist dabei zu beachten?
Wir schauen uns 7 verschiedene Fälle an, die alles umfassen, was in
den Parametern erwünscht sein könnte. In einigen Fällen war bisher
das Ergebnis unerwartet oder so gut wie sinnlos, und die Änderung
des $ selbst war, wie gesagt, nicht möglich. Das sollte sich ändern.
In den Beispielen ist /// statt XYZ gesetzt, denn es spielt ja keine
Rolle, was da steht, und so wird die Wirkung besser sichtbar.
Parameter bis V33.4 V33.5
-----------------------------------------------------------------------
1.
#81 ,"_t$_///_" Tex/// Tex///
Ersetzt t und den ganzen Rest des Feldinhalts durch ///
Diese Hauptfunktion des $ am Ende von abc ändert sich nicht.
2.
#81 ,"_$_///_" Text///E Text$Hinweis$ENDE
Bis V33.4 unlogische Wirkung / Ab V33.5 Keine Aktion
Hier könnte man erwarten, daß der Feldinhalt insgesamt nicht
ausgegeben wird, sondern ///.
Das jedoch erreicht man leichter mit #81 p"///" y0 e3
Bis V33.4 wurde nach dem $ gesucht und dieser mitsamt dem Rest
des Feldes beseitigt, nur das letzte Zeichen nicht. Das war
unlogisch und nicht sinnvoll. Wenn diese spezielle Variante
bisher vorkam, hatte sie also eine unerwünschte Wirkung. Das
*einzige* Beispiel fand sich in pica3a.ppt, eingebunden nur in
d-1.ppr, die Anzeigeparameter für Pica-Daten in PRESTO. Und
in diesem Fall ist es nun wohl besser als vorher, wenngleich
ebenfalls unrichtig.
Tip für Parametrierer: Wenn Sie das Hilfsprogramm grep haben,
können Sie mit grep _\$ *.?p? Ihre Parameter nach solchen
Fehlern absuchen. Siehe auch 7a.
3.
#81 ,"_$$_///_" Text/// Text///Hinweis///ENDE
Unlogische Wirkung / Ersetzt jedes $ durch ///
Hier passiert also ab V33.5, was man im Fall 2. eigentlich wollte:
Die Wirkung bis V33.4 war wohl kaum sinnvoll.
Dies ist ein Spezialfall des neuen Falles 7., s.u., insbes. 7b.
Aus bisheriger Sicht ist dies der interessanteste Fall, weil
man mit lokaler Ersetzung den $ als solchen nicht ersetzen konnte,
z.B. durch das Unterfeld-Dreieck. Nun kann man das leicht machen,
indem man nur _$$_^031_ setzt statt _$_?_
(Mit p- oder q-Befehl konnte man das hilfsweise meistens lösen:
p $ "///" bzw. q $ "///") Oder auch, wenn es sich um Import
handelte, mit y $ 31, um schon beim Einlesen den $ durch Code 31
zu ersetzen. Die lokale Ersetzung in den *Importparametern*
klappte dagegen schon immer, der $ hatte dabei keine Sonder-
funktion. (Für Programmierer: Funktion cfind() in import.c)
4.
#81 ,"_t$$_///_" Text$Hinweis$ENDE Text$Hinweis$ENDE
Nach wie vor ohne Wirkung, aber auch entbehrlich!
Die Erwartung, die Zeichenfolge t$ samt Rest würde ersetzt durch
///, erfüllte und erfüllt sich nicht! Nur mit exakt *einem* $
am Ende klappt das. Es gibt andere Möglichkeiten:
Um die Zeichenfolge t$$ samt Rest zu ersetzen durch /// :
z.B. ,"_$t$$_///%%%_" e"%%%" aber NUR ab V33.5, siehe 7.
Oder aber: e"t$$" P"///" was auch bis V33.4 schon ging.
5.
#81 ,"_t$$H_///_" Text$Hinweis$ENDE Text$Hinweis$ENDE
Nach wie vor ohne wirkung, aber ebenfalls entbehrlich!
Eine Ersetzung der Zeichenfolge t$$H war vorher unmöglich,
jetzt aber geht es mit
,"_$t$$H_///_" (Spezialfall von 7.)
6.
#81 ,"_t$H_///_" Text$Hinweis$ENDE Text$Hinweis$ENDE
Nach wie vor ohne wirkung. Aber ab V33.5 s. 7.!
Bis V33.4 hätte man denken können, daß nach t gesucht wird, wie
ersten Fall, und dieses samt Rest verschwände, ohne Wirkung des H.
So war's aber nicht, und das hat sich nicht geändert. Diesen
Fall könnte man immer noch etwas unglücklich finden, er wird aber
entschärft durch 7, mit dem man eine definierte und bisher
nicht vorgesehene Wirkung erreicht:
7.
#81 ,"_$t$H_///_" Text$Hinweis$ENDE Tex///inweis$ENDE
Wirkungslos / ersetzt t$H durch ///
Bis V33.4 hatte ein $ am Anfang von "abc" keine Wirkung,
d.h. der Ersetzungsbefehl tat einfach nichts.
Das sollte nicht so bleiben.
Nun hat der $ an der ersten Position die Bedeutung:
Suche nach der Zeichenfolge t$H und ersetze diese durch ///.
Soll der Rest hinter t$H verschwinden, muß man ergänzen:
,"_$t$H_///_" e"///"
Bisher hatte dies gar keine Wirkung, es sei denn, im Text
des Feldes kam schon /// vor.
7a.
#81 ,"_$t_///_" Text$Hinweis$ENDE Tex///$Hinweis$ENDE
Bis V33.4 keine Wirkung, weil $ am Anfang nicht vorgesehen.
Ab V33.5 wird jedes t durch /// ersetzt; der $ am Anfang ist
wirkungslos!
Falls in alten Parametern so eine Kombination auftritt, ergibt
sich jetzt eine Wirkung, wo vorher keine war. Solche Fälle
sind aber gerade deswegen äußerst unwahrscheinlich und hätten
von der Sache her erst gar nicht vorkommen dürfen, d.h. sie
waren längst und sind jetzt definitiv korrekturbedürftig.
7b.
#81 ,"_$$H_$x_" Text$Hinweis$ENDE Text$xinweis$ENDE
Unterfeldcode $H wird durch $x ersetzt
Neben 3. ist dies die zweithäufigst erwünschte Wirkung, die
bisher nicht möglich war.
-----------------------------------------------------------------------
[1] Brian Kernighan: A regular expression matcher.
In: Beautiful Code / Ed. by Andy Oram and Greg Wilson. -
O'Reilly, 2007, S. 1-9.
Online:
http://www.cs.princeton.edu/courses/archive/spr09/cos333/beautiful.html
Mehr Informationen über die Mailingliste Allegro