[Allegro] Index- und andere Probleme

[Fischer, Thomas]

Hallo Herr Eversberg,

>> Das sollte dringend vereinheitlicht werden (und möglichst keine undurchsichtigen Konsequenzen haben).


> Nachsicht, Kollege Fischer, Nachsicht. Die Wurzeln unserer Altlasten
> reichen tief, man kriegt sie schwerlich noch raus. Dringlichkeitsstufe
> und tadelnde Parenthetik bewegen da womöglich weniger als nichts.
> Ohne Frage kennen wir aber die Frustration, die sich solcherart entlädt.

vielleicht ließe sich dagegen etwas tun, ich bin ja gerne bereit, dabei mitzumachen.
Zum einen wäre eine (Presto-unabhängige) Erklärung der Parameter von Indexiere hilfreich, seit ich mit Allegro arbeite stolpere ich da über das buch/buecher, das mir nur erlaubt, ein Unterverzeichnis buecher von C:\allegro anzugeben.
Also eine Erklärung der Parameter mit Hinweisen darauf, wo (relative?) Pfade erlaubt und wo sie verboten sind.

> Kap. 7.1 im Handbuch (S. 155) listet alle einschlägigen Programmaufrufe.
> Bei Option  -e  kann ferner auch unter Windows = statt / benutzt werden:
>   -e parameter=ordnername
> 
> Und ein wenig Geduld noch: Neue Systeme sind in Arbeit, in globalen
> Communities, und die lassen hergebrachte Kryptiken und Archaismen
> weit hinter sich. Hinfort, heißt es da, mit den Werken der Finsternis
> und herbei mit den Waffen des Lichts. Normkonform, im Mainstream
> schwimmend, und der Zukunft zugewandt. Zeitgenössische Admins schmunzeln
> doch bereits, "allegro? Das gibt's noch?"
>> Zunächst sieht es aber so aus, dass mein Skript jetzt durchläuft!

Mein Wunsch wäre da eher, Allegro fit für die nächste Zukunft zu machen, indem solche Widrigkeiten beseitigt werden.
Mir ist nicht ganz klar, warum in Parametern übergebene Pfade in Index anders als in Qrix behandelt werden, da würde mir ein Unterprogramm in allen Quadrigaprogrammen vorschweben, das absolute und relative Pfade einheitlich auswertet, in welchem Parameter sie auch immer übergeben sind.
Ist das wirklich so schwierig?

> Na wer sagt's denn! Unabweisbarer Handlungsbedarf ist doch gar nicht gegeben.

Wie gesagt, wenn Allegro eine Zukunft haben soll, sind solche Widrigkeiten Stolpersteine auf dem Weg dahin.

Und wo wir gerade dabei sind:

Von meinen diversen Versuchen der letzten Zeit sind noch die Fragen offen:

1. Warum bleibt acon unter bestimmten Umständen bei
set tbl fre
hängen? ("Löschprobleme" vom  12.10.2015 um 09:36)

2. Wie schließt man mit acon eine zum Export geöffnete Datei, so dass sie danach vollständig zum Lesen bereitsteht?
(Re: [Allegro] Upload vom 04.10.2015 um 15:14 und 05.10.2015 um 15:41)

3. Warum liefert bei dem Feld
#40 #Shakespeare# William
x var #40\mes
als Ergebnis Shakespeare# William, wird das erste "#" also verschluckt? (Beispiel aus Demodatenbank)
(Re: [Allegro] Exportparameter vom 29.09.2015 um 12:01)

Wie erwähnt, wäre ich zur Unterstützung bereit, wünsche mir dazu aber zusätzlich ein zugängliches Subversion-System:

A. Warum bekomme ich mit
fischer$ svn list https://svn.allegro-c.de/svn/a99/
die Antwort
svn: E175013: Unable to connect to a repository at URL 'https://svn.allegro-c.de/svn/a99'
svn: E175013: Access to 'https://svn.allegro-c.de/svn/a99' forbidden
(mit acon geht's) ?

B. Warum bekomme ich mit
fischer$ svn list https://svn.allegro-c.de/svn/
die Antwort
svn: E175002: Unable to connect to a repository at URL 'https://svn.allegro-c.de/svn'
svn: E175002: The OPTIONS request returned invalid XML in the response: XML parse error at line 1: no element found (https://svn.allegro-c.de/svn)

Könnte das nicht mal so aufgesetzt werden, dass man mit einem normalen SVN-Client (und nicht nur einem Browser) effektiv darauf zugreifen kann?

Mit freundlichen Grüßen
Thomas Fischer

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 842 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20151015/c4228264/attachment.sig>