[Allegro] fehler in d-wrtf.apr?

Mi Jul 16 09:47:44 CEST 2014

Guten Tag Herr Eversberg,
danke für Ihre Nachricht.
Am Mittwoch, 16. Juli 2014 um 08:40 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Am 15.07.2014 17:11, schrieb Klaus Lehmann:
>> als mir das (unangenehm) aufgefallen war, hatte ich sofort ein
>> beispiel parat.
....
> Aber zur Beruhigung zunächst:
> Die jetzt vorliegenden Parameter und ALLE vor V34.2 erstellten sind
> völlig frei von solchen Problemfällen! Normalanwender müssen also nicht
> befürchten, wegen dieser Sache irgendwo Probleme mit der V34.3 zu
> kriegen. Kein Grund, V34.3 wieder rauszuschmeißen!

naja. in meinen parameterdateien wimmelt es nur so von 
decimal-ausdrücken. ich war so "glücklich", endlich das ungeliebte 
umgekehrte_dreieck NICHT mehr eingeben zu müssen, WEIL ich mit 
unterschiedlichen editoren arbeite. jeder edi hat seine eigene 
artundweise, wie er mit "nichtnormalen" zeichen umgeht. das decimal031 
war ein sehr "pikantes" zeichen! es war ein hasszeichen! ;-)
jetzt \31. 
aaaah, welch ein forschritt. UND ich darf zukünftig \031 sogar schreiben. noch besser. 

> Zur Sache:
> Alle Freunde sauberer Programmierung werden Ihnen vollumfänglich recht
> geben, das steht außer Frage. Daß der Problemfall äußerst selten
> vorkommen dürfte, ist kein akzeptabler Grund für Nichtstun.
die "normalos" müssen nichts tun. höchstens auf schreibfehler achten. 
wie ich zufällig derer zweien gestern gefunden habe.. ,-)

> Vorerst erlauben's die Umstände aber nicht, stante pede ans Werk zu
> gehen. Wir müssen das vertagen und vorerst zu Umgehungslösungen raten,
> die es ja durchaus gibt.
> Es ist nicht getan damit, die Programme zu ändern, sondern auch +
> diejenigen Parameterdateien, die wir schon entsprechend bearbeitet
> haben, sind nochmals durchzuackern. Wenn jemand diesen Part übernähme,
> wäre schon was gewonnen. Zu denken ist auch an die lokalen
ich würde ja gerne. aber erstmal sind "meine" dateien dran. da bin ich 
zu egoistisch.

allerdings gebe ich gerne noch mal mein regelwerk hier bekannt, wie 
ich vorgehe:

  bestimmte so-zeichen wie SUB(US), CR; ª  werden durch \031  \020 und \170 ersetzt
 alle diese subfelder suchen und ersetzen: nach der unten notierten methode!
 ABDDEGHIJLMNORSTVWYZ  (fehlende Buchstaben sicherheitshalber mitsuchen!)
 abcdefgjklmnopqrstuvwz   (  "   )

 Für b, B, c, C, e, E, p, P gelten:  (vermutlich AUCH für den i-Befehl wie i4,$  für das subfieldzeichen!)
 Nicht eingebbare Zeichen in X mit \nnn codieren, z.B. b"\031" .
 Kurzschreibweise: Statt b"$x" ist auch b$x möglich, statt b"$" auch b$ . 
 ODER eben b"\031"x oder b\031x

 Hinweis: das $ für das umgekehrte Dreieck IST unglücklich! \031 ist eindeutiger!

 zu schreiben ist so:                    WEGEN unlogik: nicht $ nutzen!
 bei o.g. manipul.befehlen (NICHT c)     LIEBER     so: b"\031"
 b$d               NICHT: b"$d"          für $ als trenner dann so: b"\036"
 NICHT: b"SUBFIELDZEICHENd"  
 NICHT: b\031d  SONDERN b"\031d"
 Subfelder können sie angesprochen werden: #89Z $u    usw usw

 ACHTUNG: AUSNAHME: der Befehl : "_"
 Neues korrektes Beispiel             !ch +# b$L ,"_\031s_ _" e"\031" p"|8"

 Achtung: bei Indexauslagerungen, wie z.b. !u1 p"~f7"   IMMER SO schreiben !u1 p{ "~f7" }   2014/6 
 achtung: bei vielen p"irgendwas"-konstruktionen, MUSS ergänzt werden 
 auf p{ "irgendwas" } !!!

 ich frage: steht da oben in meiner für mich geschriebenen einleitung 
 etwas FALSCHES drin?

 EINE weite Frage ist offen:
 ==========================
 Kurzschreibweise: Statt b"$x" ist auch b$x möglich, statt b"$" auch b$ . 
 ODER eben b"\031"x oder b\031x

 MUSS das sein mit den klammern?
 ist b\031s nicht eindeutig genug?
 oder e\031
 wozu steht denn die klammer?

> Ersetzungenan sowie an die ak-Befehle, in denen z.B. steht
> ak=8.."[;\20]"+L. Das wäre zu ändern in
> ak=8.."[;\020]"+L

> Funktionieren würde das alles sofort, noch vor einer Programmänderung.
also darf man \020 schreiben. prima. prima. oberprima!

grüße
k.l.

> B.E.

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda, zuständige Kammer: IHK Dresden
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg, USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow
* Yes we can. Only with allegro. Yes we do. Always with allegro.
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 with VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: allegronet ist ein eingetragenes Warenzeichen

Am Mittwoch, 16. Juli 2014 um 08:40 schrieben Sie:
> Am 15.07.2014 17:11, schrieb Klaus Lehmann:
>>
>>> Was wäre der konkrete Nutzen? 2stellig funktioniert an diesen Stellen
>>> genausogut.
>>
>> als mir das (unangenehm) aufgefallen war, hatte ich sofort ein
>> beispiel parat.
>>
>> aber vielleicht geht es so:
>> nehmen wir an, es geht um inhalte, die aus ziffern bestehen.
>> dann könnte sowas so aussehen:
>>
>>>> #60 e"[_\31123456789]" F" " E60 P": "
>> KEIN problem, hier weiss das programm, es geht um decimal 31,
>> denn eine decimal 311 gibt es nicht.
>>
> Da irren Sie, das Programm "weiß" das nicht sondern es kommt zu einer
> Fehlfunktion. Die Sache ist also noch schlimmer als Sie denken.

> Aber zur Beruhigung zunächst:
> Die jetzt vorliegenden Parameter und ALLE vor V34.2 erstellten sind
> völlig frei von solchen Problemfällen! Normalanwender müssen also nicht
> befürchten, wegen dieser Sache irgendwo Probleme mit der V34.3 zu
> kriegen. Kein Grund, V34.3 wieder rauszuschmeißen!

> Zur Sache:
> Alle Freunde sauberer Programmierung werden Ihnen vollumfänglich recht
> geben, das steht außer Frage. Daß der Problemfall äußerst selten
> vorkommen dürfte, ist kein akzeptabler Grund für Nichtstun.

> Vorerst erlauben's die Umstände aber nicht, stante pede ans Werk zu
> gehen. Wir müssen das vertagen und vorerst zu Umgehungslösungen raten,
> die es ja durchaus gibt.
> Es ist nicht getan damit, die Programme zu ändern, sondern auch +
> diejenigen Parameterdateien, die wir schon entsprechend bearbeitet
> haben, sind nochmals durchzuackern. Wenn jemand diesen Part übernähme,
> wäre schon was gewonnen. Zu denken ist auch an die lokalen
> Ersetzungenan sowie an die ak-Befehle, in denen z.B. steht
> ak=8.."[;\20]"+L. Das wäre zu ändern in
> ak=8.."[;\020]"+L

> Funktionieren würde das alles sofort, noch vor einer Programmänderung.

> B.E.

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro