[Allegro] acon und srch.job im SVN erneuert

[Thomas Berger]

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

Lieber Herr Eversberg,

>> Ich versuche momentan srch.job so zu optimieren, dass geloeschte
>> Saetze fruehzeitig als solche erkannt und uebersprungen werden.
> Machen Sie es so:
> 
> fetch rec
> if %u1    @@@@@% jump ...
> 
> Das geht (gerade getestet).

Das setzt aber voraus, dass es in den Daten keine Kategorien
gibt, die Mehrfachleerzeichen erlauben und diesen Inhalt haben.

Ausserdem sind mir die vier Spatien zu sehr Vodoo als dass
ich mich drauf verlassen moechte, dass das immer so bleibt.

viele Gruesse
Thomas Berger



>> Kann denn uebrigens nicht bei "fetch rec" die Form in der iV
>> entstehen, wie
>> sie auch nach "ins" und "var kn" erreicht wird, also .adt-Format mit ^J
>> als Trenner zwischen (Roh-)Kategorien: Das wuerde alles einheitlicher
>> machen
>> und auch die oft diskutierte Spezialbehandlung von ";#" vermeiden helfen.
>>
> Die kam nur zustande, weil Sie bemerkt hatten, daß die Form mit
> Zeilentrennern, die wir zuerst hatten, die Gefahr der "Code injection"
> berge.

Tja, und spaeter dann haben Sie ";" neben ^J als weiteren Befehlstrenner
eingefuehrt so dass das Spiel von vorne losgeht...

Ich erinnere mich allerdings nicht mehr ganz genau an die Zusammenhaenge.
Tatsache ist, dass acwww25 "schon immer" Blaetterprobleme im
Serienregister hatte, die auf unbeabsichtigte Code-Injection (das Ende
des Suchbegriffs wurde als neue Anweisung interpretiert) zurueckfuehrbar
waren, d.h. ";" als Befehlstrenner in acon/avanti gab es praktisch
schon immer. Sie haben darauf moeglicherweise irgendwann dergestalt
reagiert, dass ";" nur noch dann Befehlstrenner ist, wenn es nicht
von Spatien umschlossen ist (denn man kann ja voraussetzen, dass im
Serienregister stets ein Spatium das ";" begleitet ;-)

Jedenfalls ist die ins-Problematik davon unabhaengig bzw. sollte es
sein: Bei "ins" sollen Inhalte in den Speicher eingeordnet werden
und nicht (a la "eval") irgendwelche Befehle ausgefuehrt. D.h.
der Fall

var "#00 mir egal" 10 "read file /etc/passwd" 10 "#81 harmlos"
ins

sollte (egal ob mit ";" oder ^J) sogar wesentlich einfacher sauber
hinzubekommen sein als die in den Job "eingebettete" Situation

#00 mir egal
read file /etc/passwd
#81 harmlos


gegen die man gar nichts ausrichten kann (ausser eben Jobs nicht
aus ungeprueften Benutzereingaben zu generieren)

viele Gruesse
Thomas Berger


>> In vom Job ausgeloesten Exporten ist allerdings #nr in allen Faellen
>> konstant "0", hier scheint also die Initialisierung aus der acon
>> bekannten
>> internen Satznummer nicht zu funktionieren.
>>
> Ja, denn das Einlesen eines Satzes darf nicht die interne Nummer des
> aktuellen Satzes überschreiben. Ein solches Einlesen kann ja (zumindest
> theoretisch) auch geschehen, während man einen wichtigen aktuellen Satz
> in Arbeit hat, der anschließend noch zu speichern ist. Und ein
> "new"-Satz hat eben die Nummer 0, die darf dann nicht durch eine
> positive Nummer ersetzt werden, weil er dann nicht mehr als "new"
> erkennbar ist.

Hier haben Sie mich missverstanden:

In srch.job passiert zunaechst ein "new", danach sollte iR den Wert 0
haben (nicht ueberprueft). Dann wird "fetch rec" ausgefuehrt und mit
Magie wird iR auf die aus der .ald-Datei ausgelesene Satznummer
gesetzt. Das finde ich positiv. Nach "ins" ist dieser Wert von iR
erhalten geblieben, die Parameterdatei, die anschliessend mit
"export" darauf losgelassen wird, sieht aber #nr als "0". Ich sehe
keinen Grund, warum sie nicht den aktuellen Wert des CString iR
mitgeteilt bekommen duerfen sollte bzw. einen Datensatzzaehler
im Fall von .alg-Dateien: So war das Verhalten von SRCH.EXE.

viele Gruesse
Thomas Berger




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

iJwEAQECAAYFAkwXav4ACgkQYhMlmJ6W47NV7wQArjF0CnjM4cNuyR/E3DMu9BzG
LuaCdnofVZ3Rma5fvbjXOQBiZtyQEcvZuZRqDKoZIIgGW6YdgBK1nRA8TjSXgXQg
mtAdc6dBgimdksc/hPUbzYlCn59yW5rc5LJGstOEX7JU7O0K9puNNFKN3gSrw48S
sBok4515f2RK7YO6Be0=
=+Jv1
-----END PGP SIGNATURE-----