Forum: PC-Programmierung Tippfehler in config-Dateien finden?


von Bauform B. (bauformb)


Lesenswert?

Guten Morgen,

ein Linux-Programm benutzt eine Art ini-Datei für die Einstellungen, 
also key=value, ASCII-Text. Die wird hauptsächlich vom Benutzer per 
Editor geändert. Also muss das Programm mit Tippfehlern klar kommen. 
Syntax-Fehler sind eher kein Problem, Fehler im value sieht der Benutzer 
selber wenn es Text ist, für Integer gibt es jeweils natürliche 
Grenzwerte.

Aber wie behandelt man bei Updates einen unbekannten key?
* Eine neue Programmversion findet in einer alten config einen neu 
eingeführten key nicht - dann sollte es gefälligst einen vernünftigen 
Default geben.
* Ein altes Programm findet in einer neuen config einen unbekannten key 
- den darf es ignorieren; auch kein Problem.
* Aber: Ein Programm findet einen unbekannten key und gleichzeitig fehlt 
einer - darf es jetzt Regel 1 und 2 anwenden oder ist das ein 
Tippfehler?

Könnte man da mit dieser Levenshtein-Distanz etwas anfangen? Man bekommt 
doch nur eine Wahrscheinlichkeit, Tippfehler oder zwei gültige keys. Wie 
macht man das etwas benutzerfreundlicher? Und wieso finde ich keine 
fertige lib ;)


Bisher gibt es ca. 5 Programme und 100++ verschiedene Konfigurationen 
aus den letzten 15 Jahren. Nur, falls jemand sagen möchte, mach' das 
einfach ganz anders ;)

von (prx) A. K. (prx)


Lesenswert?

Bauform B. schrieb:
> * Aber: Ein Programm findet einen unbekannten key und gleichzeitig fehlt
> einer - darf es jetzt Regel 1 und 2 anwenden oder ist das ein
> Tippfehler?

Sowas löst sich meist pragmatisch ganz von alleine ohne drüber 
nachzudenken. Der fehlende Key hat ein Default und der überschüssige Key 
wird ignoriert.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Kannste vielleicht jeweils eine Warnung bei beiden Faellen ausgeben? 
Dann muessen sich halt die User ggf. einen Reim drauf machen. Oder sind 
das Amoeben?

Gruss
WK

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> Könnte man da mit dieser Levenshtein-Distanz etwas anfangen?

Wenn dann nur als Warnung/Hinweis, bloß nicht einen "fast korrekten" Key 
"Autokorrigieren", das kann gehörig schief gehen.

Oder: Einen grafischen Editor bauen, der ein fixes Schema anzeigt, also 
ein Eingabefeld pro Key; so sind Tippfehler im Key ausgeschlossen. Die 
Werte kann man auch direkt prüfen.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Bauform B. schrieb:
> Und wieso finde ich keine
> fertige lib ;)

Weil die Implementierung der libglaskugel.so ziemlich schwierig ist.

Ein Programm kann nun mal nicht Hellsehen. Da helfen auch keine 
Heuristiken. Klar, kannst du machen. Von mir aus auch super-modern mit 
KI. Schlussendlich wird trotzdem nur geraten.

Bleib konservativ:

Grundsätzlich in allen Fällen Logeinträge. Immer, auch für die 
problemlos genommenen Parameter. Auch wenn zusätzlich irgendwo Warnungen 
oder Fehler angezeigt werden. Es ist zum Kotzen wenn man bei der 
Fehlersuche im Dunklen stehen gelassen wird und nur durch herumprobieren 
heraus finden muss was passiert ist.

Die Fälle:

* Was bekannt ist wird genommen.

* Was unbekannt ist gibt einen Fehler oder wird ignoriert 
(gegebenenfalls mit einer Warnung). Ich selber bin ein großer Fan von 
Fehler aber viele Leute finden ignorieren ganz toll. Nur kommt daher 
dein Problem.

* Was fehlt gibt einen Fehler oder hat eine Voreinstellung mit oder ohne 
Warnung.

> Bisher gibt es ca. 5 Programme und 100++ verschiedene Konfigurationen
> aus den letzten 15 Jahren. Nur, falls jemand sagen möchte, mach' das
> einfach ganz anders ;)

Spring wenigstens über deinen Schatten und führe eine Versionierung des 
Formates ein. Zum Beispiel ein Parameter wie

configFormat=3.7

Dann kannst du auch so Dinge regeln wie geänderte Voreinstellunge, 
Parameter die weggefallen sind oder gar nicht mehr angegeben werden 
dürfen, Änderungen in der Semantik von Parametern usw.

von Frank D. (Firma: LAPD) (frank_s634)


Lesenswert?

Bauform B. schrieb:

> ein Linux-Programm benutzt eine Art ini-Datei für die Einstellungen,
> also key=value, ASCII-Text.
Mach ein GUI-Tool zur Konfiguration, das Unsinn schon vorher abfängt.
Anwender lässt man nicht .inis rumpfuschen.

von Matthias S. (dachs)


Lesenswert?

Frank D. schrieb:
> Mach ein GUI-Tool zur Konfiguration, das Unsinn schon vorher abfängt.
Richtig, allerdings muss man dann auch das durchsetzen:
> Anwender lässt man nicht .inis rumpfuschen.

Und das wird schwierig, wenn die Anwender das seit 15 Jahren so machen.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Matthias S. schrieb:
> Und das wird schwierig, wenn die Anwender das seit 15 Jahren so machen.

Bei cleveren UI-Design sieht der Editor fast so aus wie der normale 
Texteditor, nur eben dass die Feldnamen fix sind. Das könnte man sogar 
als Expertenmodus implementieren, und für neue Nutzer gibt es einen 
einfacheren Editor "davorgeschnallt"

Und in jeder Fehlermeldung bewirbt man die Vorzüge des Editors ("das 
wäre damit nicht passiert"), der natürlich auch beim Programm 
mitgeliefert wird

von Alexander (alecxs)


Lesenswert?

Was ich empfehle ist Labels case-insensitiv abzufragen. Außerdem sollte 
es eine klare Regel geben bei doppelten Einträgen. Zu empfehlen ist, 
immer der letzte gilt.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Alexander schrieb:
> Zu empfehlen ist, immer der letzte gilt.

Und dann fragt man sich warum der vorherige Eintrag nicht geht... Lieber 
eine Fehlermeldung bei doppelten Einträgen! Case Sensitive kann auch 
sinnvoll sein, um z.B. eine CamelCase Schreibweise zu erzwingen, welche 
u.U. besser verständlich ist.

Bei solchen Inputs ist strenger oft besser. Zu versuchen, alles auf 
Biegen und Brechen zu akzeptieren, führt gern zu Chaos

von M. M. (blackcow)


Lesenswert?

Einfach readout an AI anbinden. ChatGPT hat da so eine API. Einfach 
promt geben: "Korrigiere das config file. Hier einige Beispiele: 
Beispiele.... Gib mir nur die nach bestem Wissen und Gewissen das 
hochgeskillte Config file in Textformat"

von Alexander (alecxs)


Lesenswert?

Das ist gelinde gesagt verrückt! Warum KI Abhängigkeiten einführen wo 
sie nicht notwendig sind?

von M. M. (blackcow)


Lesenswert?

Ease of use!

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Alexander schrieb:
> Warum KI Abhängigkeiten einführen wo sie nicht notwendig sind?

Damit man damit werben kann und ggf. Fördergelder bekommt.

von Alexander (alecxs)


Lesenswert?

Der Plan von OpenAI ist es, eine Generation heranwachsen zu lassen die 
von ChatGPT abhängig ist. Wenn dann nichts mehr ohne geht, werden die 
Preise erhöht.

von M. M. (blackcow)


Lesenswert?

Alexander schrieb:
> Der Plan von OpenAI ist es, eine Generation heranwachsen zu lassen die
> von ChatGPT abhängig ist. Wenn dann nichts mehr ohne geht, werden die
> Preise erhöht.

Der Plan von Bjarne Stroustrup war es eine Generation von C++ abhängig 
zu machen. Keiner kann mehr Assembler programmieren.

von Alexander (alecxs)


Lesenswert?

Moby, bist Du es?

: Bearbeitet durch User
von Ein T. (ein_typ)


Angehängte Dateien:

Lesenswert?

Bauform B. schrieb:
> Könnte man da mit dieser Levenshtein-Distanz etwas anfangen?

Für das Kernproblem eher nicht, aber für aussagekräftigere Fehler- oder 
Warnmeldungen.

Verschiedene Softwarepakete lösen das Problem durch einen Testmodus -- 
think "configtest" für apachectl(8) -- oder durch einen Wrapper zum 
Editieren der Konfiguration, der die editierte Konfiguration vor deren 
Installation auf syntaktische und, wo möglich, inhaltliche Korrektheit 
überprüft, bevor er sie endgültig installiert. Ein Beispiel für die 
letztgenannte Variante ist zum Beispiel visudo(8) zum Ändern der 
Konfiguration von sudo(1).

In beiden Fällen heißt das aber natürlich auch, daß jedliche Änderungen 
an der Konfiguration nicht nur im Programm selbst, sondern auch in 
seinem Testmodus oder dem Wrapper widergespiegelt werden müssen. Wenn 
das auseinander läuft, verkehrt sich die gute Idee schnell ins 
Gegenteil.

In den beiden beschriebenen Varianten hast Du dann vermutlich eine Liste 
von zulässigen Schlüsseln, und kannst so jeden gefundenen Schlüssel 
mit dem Levenshtein- oder Damerau-Levenshtein-Algorithmus gegen diese 
Liste prüfen. Wenn ein gefundener Schlüssel nicht in der Liste der 
zulässigen Schlüssel ist, die Levenshtein-Distanz aber lediglich 1 
oder 2 ist, könnte eine kluge Warn- oder Fehlermeldung so etwas 
schreiben wie
1
Unbekannte Direktive "ruebennase" (Zeile 11), meinten Sie "rübennase"?

Aus meiner Erfahrung weiß ich, daß sich Fehlermeldungen mit solchen 
Hinweisen nicht nur bei mir selbst großer Beliebtheit erfreuen. :-)

Mittlerweile bin ich im Übrigen dazu übergegangen, anstelle eigener 
Formate, JSON- oder INI-Dateien für Konfigurationsdateien nurmehr YAML 
zu verwenden. Das ermöglicht beliebig tief geschachtelte Datenstrukturen 
und Kommentare, und läßt sich schnell und effizient parsen.

Im typsicheren Golang werden die Typen bereits beim Einlesen (genauer: 
beim Aufruf von yaml.Unmarshal()) überprüft, mit dem Paket "validator" 
[1] können darüber hinaus weitere, fein granulierte Prüfungen erfolgen.

In Python gibt es zum Prüfen von Datenstrukturen und ihren Inhalten das 
Paket Pydantic [2], das mit Type Hints arbeitet.

Aus Spaß an der Freude habe ich ein wenig Code in Golang und Python 
angehängt. Wahrscheinlich nutzt Du andere Sprachen und kannst meine 
Beispiele deswegen nicht direkt nutzen. Trotzdem glaube ich, daß sich 
darin gute Ideen auch für andere Sprachen finden und sich übertragen 
lassen.


[1] https://github.com/go-playground/validator
[2] https://pydantic.dev/

von Ein T. (ein_typ)


Lesenswert?

Alexander schrieb:
> Was ich empfehle ist Labels case-insensitiv abzufragen. Außerdem sollte
> es eine klare Regel geben bei doppelten Einträgen. Zu empfehlen ist,
> immer der letzte gilt.

Das ist eine feine Sache, zum Beispiel PostgreSQL macht das so. Schick: 
man kann die ganze Konfigurationsdatei auf den Defaultsettings lassen 
und seine getunten Settings (pgtune, anyone?) schön übersichtlich 
zusammen ans Ende der Datei schreiben, die überstimmen dann die oben 
gesetzten Defaults.

von Oliver (imonbln)


Lesenswert?

Du solltest hier das Paradigma, "Garbage In, Garbage Out" verwenden, 
wenn der Typo schon in der alten Version war, hat die auch irgendwie 
Funktioniert, dann erwartet der Benutzer hier das Default verhalten. 
Einfach zu sagen passt schon ich weiß was du meinst, ist grundsätzlich 
gefährlich bei Konfigurationen.


Wenn du ein Benutzer helfen willst, mach eine Syntax Checker für die 
Konfiguration. Meine Programme haben meistens die Option die aktuelle 
Konfiguration in eine Datei oder nach Stdout zu schreiben, die kann dann 
der Benutzer sich ansehen und merkt sein Fehler hoffentlich.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Ein T. schrieb:
> , die überstimmen dann die oben gesetzten Defaults.

Welchen Zweck haben dann die da herumoxidierenden Defaults, außer 
Verwirrung zu stiften? Ich würde sie auskommentieren oder verschieben...

von Frank D. (Firma: LAPD) (frank_s634)


Lesenswert?

Matthias S. schrieb:
> Und das wird schwierig, wenn die Anwender das seit 15 Jahren so machen.
Dann ändert man das Format: keine inis mehr sondern serialisierte 
Objekte, verschwurbelte Binaerdaten,...

von Hmmm (hmmm)


Lesenswert?

Ein T. schrieb:
> Das ist eine feine Sache, zum Beispiel PostgreSQL macht das so. Schick:
> man kann die ganze Konfigurationsdatei auf den Defaultsettings lassen
> und seine getunten Settings (pgtune, anyone?) schön übersichtlich
> zusammen ans Ende der Datei schreiben, die überstimmen dann die oben
> gesetzten Defaults.

Wenn sich da nicht in den letzten Versionen etwas geändert hat, stehen 
die Defaults zwar drin, aber auskommentiert. Kombiniert den von Dir 
genannten Vorteil (hinten dranhängen) damit, dass es eben keine sich 
widersprechenden Config-Zeilen gibt, von denen die letzte gilt.

von Bauform B. (bauformb)


Lesenswert?

Faszinierend, mir fehlen die Worte, vielen Dank miteinander!

Hannes J. schrieb:
> Was unbekannt ist gibt einen Fehler oder wird ignoriert
> (gegebenenfalls mit einer Warnung). Ich selber bin ein großer Fan von
> Fehler aber viele Leute finden ignorieren ganz toll. Nur kommt daher
> dein Problem.

Niklas G. schrieb:
> bloß nicht einen "fast korrekten" Key
> "Autokorrigieren", das kann gehörig schief gehen.

Ein T. schrieb:
> Bauform B. schrieb:
>> Könnte man da mit dieser Levenshtein-Distanz etwas anfangen?
>
> Für das Kernproblem eher nicht, aber für aussagekräftigere Fehler- oder
> Warnmeldungen.

Das sind die lehrreichsten Aussagen für mich. Bisher sind die Programme 
gnadenlos, bei jeder kleinen Ungereimtheit wird ein Update verweigert. 
Natürlich sind die Benutzer davon nicht begeistert, aber ich sehe es 
ein, das Prinzip ist richtig. Nur eins war übertrieben: eine neue 
Programmversion muss gefälligst eine korrekte alte Config akzeptieren.

Ein Beispiel für eine misslungene Erweiterung: das Programm war 
2-sprachig, also gab es z.B. locale1 = fr_CH und locale2 = de_DE. Später 
waren mehr Sprachen möglich, also gibt es locales = "fr_CH de_DE". Für 
sowas muss man wohl individuelle Konverter-Funktionen bauen und locale1 
und locale2 bis in alle Ewigkeit akzeptieren.


Hannes J. schrieb:
> Grundsätzlich in allen Fällen Logeinträge. Immer, auch für die
> problemlos genommenen Parameter. Auch wenn zusätzlich irgendwo Warnungen
> oder Fehler angezeigt werden.

Das habe ich vielleicht schon übertrieben. Jetzt muss ich hoffen, dass 
logrotate immer funktioniert ;)

Frank D. schrieb:
> Anwender lässt man nicht .inis rumpfuschen.

Wenn es kein UI gibt, lässt sich das kaum vermeiden. Außerdem hat das 
Format den großen Vorteil, dass die Gebrauchsanweisung genau da steht, 
wo man sie braucht (ja, jemand muss sie schreiben, aber das machen 
Benutzer sogar selber).

Alexander schrieb:
> Was ich empfehle ist Labels case-insensitiv abzufragen. Außerdem sollte
> es eine klare Regel geben bei doppelten Einträgen.

Die klaren Regeln sind ganz klar: case-sensitive und doppelte sind 
verboten. Je eindeutiger desto eindeutig (oder so).

Ein T. schrieb:
> Schick:
> man kann die ganze Konfigurationsdatei auf den Defaultsettings lassen
> und seine getunten Settings (pgtune, anyone?) schön übersichtlich
> zusammen ans Ende der Datei schreiben

Bei über 1500 Zeilen kann "am Ende" ganz schön weit weg sein; lieber 
nicht.

Niklas G. schrieb:
> Bei cleveren UI-Design sieht der Editor fast so aus wie der normale
> Texteditor, nur eben dass die Feldnamen fix sind.

Erst dachte ich, jetzt ist er ganz falsch abgebogen, völlig utopisch 
das. Aber geany z.B. kennt C-Syntax, C-Keywords und ini-Syntax. Wenn man 
dem meine Keywords beibringen könnte... Naja, was für lange Winterabende 
;)

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> Natürlich sind die Benutzer davon nicht begeistert

Die Nutzer und der Support wären noch weniger begeistert wenn die 
Software ständig irgendwas unerwartetes tut weil die Konfig falsch 
interpretiert wurde.

Bauform B. schrieb:
> Für
> sowas muss man wohl individuelle Konverter-Funktionen bauen und locale1
> und locale2 bis in alle Ewigkeit akzeptieren.

Oder erst eine Warnung ausgeben "altes Format wird nur bis Version X 
unterstützt" und ab da wird der Support rausgenommen.

Bauform B. schrieb:
> Wenn es kein UI gibt, lässt sich das kaum vermeiden.

Auch wenn das Programm selber keine GUI hat, kann man die Datei trotzdem 
mit einem GUI-Programm erzeugen. Die meisten Computer haben heutzutage 
die Möglichkeit eine GUI darzustellen...

Bauform B. schrieb:
> Erst dachte ich, jetzt ist er ganz falsch abgebogen, völlig utopisch
> das. Aber geany z.B. kennt C-Syntax, C-Keywords und ini-Syntax.

Ich meinte nicht als Texteditor mit Highlighting, sondern eher eine GUI 
welche z.B. eine 2-Spaltige Tabelle darstellt: Linke Spalte ist der Key, 
rechte der Value. Die linke Spalte ist read-only. Die rechte Spalte wird 
immer auf Konsistenz geprüft. Dann noch Zwischenüberschriften dazu, ein 
automatisch eingeblendeter Hilfstext zur aktuell ausgewählten Zeile, 
Dropbox-Felder oder Datums-Auswahlboxen bei entsprechenden Zeilen, und 
schon kann kaum noch was schief gehen.

Das kann man sich ziemlich simpel in allen gängigen GUI-Frameworks 
zusammenbauen, sogar auch als Web-Interface mit JavaScript oder 
Mobil-App...

: Bearbeitet durch User
von Re D. (re_d272)


Lesenswert?

Bauform B. schrieb:
> Bei über 1500 Zeilen kann "am Ende" ganz schön weit weg sein; lieber
> nicht.

In was für einem masochstischen Laden läuft Software die über ein 1500 
Zeilen langes config-file konfiguriert wird? Das ist ja gruselig!
Ein komplettes redesign wäre die einzig sinnvolle Lösung, statt 1500 
Zeilen Spaghetti.

von Nemopuk (nemopuk)


Lesenswert?

Frank D. schrieb:
>> wenn die Anwender das seit 15 Jahren so machen
> Dann ändert man das Format

Du hast wohl nicht begriffen, das die Anwender kein anderes Dateiformat 
wollen.

von Bauform B. (bauformb)


Lesenswert?

Nemopuk schrieb:
> Frank D. schrieb:
>>> wenn die Anwender das seit 15 Jahren so machen
>> Dann ändert man das Format
>
> Du hast wohl nicht begriffen, das die Anwender kein anderes Dateiformat
> wollen.

Naja, damals wurden sie nicht gefragt und Änderungen mag ja niemand ;)

Re D. schrieb:
> In was für einem masochstischen Laden läuft Software die über ein 1500
> Zeilen langes config-file konfiguriert wird? Das ist ja gruselig!

Ganz so schlimm ist es nicht, das sind hauptsächlich Texte für 3 
Sprachen. Die interessanten Einstellungen stehen natürlich am Anfang und 
Ein T. wollte die aktuellen Werte doppelt ans Ende schreiben.

Niklas G. schrieb:
> Ich meinte nicht als Texteditor mit Highlighting, sondern eher eine GUI
> welche z.B. eine 2-Spaltige Tabelle darstellt: Linke Spalte ist der Key,
> rechte der Value.

Man müsste noch die Kommentare vor jeder Zeile ändern können - nicht, 
aber ergänzen. Genau, read-only Text von mir und Kommentar vom Benutzer. 
Einerseits lohnt es sich umso besser, je genauer es alle Parameter 
prüfen kann, andererseits wäre es eigenständiges Programm, 
wahrscheinlich sogar für Windows. Könnte ich auf Debian eine DLL mit den 
Prüf-Funktionen erzeugen? Ich glaube, ich sollte jetzt sofort etwas ganz 
anderes machen ;)

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Bauform B. schrieb:
> Könnte ich auf Debian eine DLL mit den Prüf-Funktionen erzeugen? Ich
> glaube, ich sollte jetzt sofort etwas ganz anderes machen ;)

Mach's in Python oder Java, dann spielt das OS keine Rolle...

Bauform B. schrieb:
> Genau, read-only Text von mir und Kommentar vom Benutzer

Keine schlechte Idee, der fixe Text ist im Editor fix und landet nicht 
in der Datei, der User Kommentar kommt in die Datei.

von Nemopuk (nemopuk)


Lesenswert?

Schade, dass es keinen Script-Interpreter gibt, der aus nur einer Datei 
besteht und auf allen gängigen Betriebssystemen läuft.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Nemopuk schrieb:
> Schade, dass es keinen Script-Interpreter gibt, der aus nur einer Datei
> besteht und auf allen gängigen Betriebssystemen läuft.

ZIP macht aus allem eine einzelne Datei.

von Ein T. (ein_typ)


Lesenswert?

Niklas G. schrieb:
> Ein T. schrieb:
>> , die überstimmen dann die oben gesetzten Defaults.
>
> Welchen Zweck haben dann die da herumoxidierenden Defaults,

Ihre Oxidation. Und morgen lernen wir, was ein Beispiel ist. :-)

von Ein T. (ein_typ)


Lesenswert?

Hmmm schrieb:
> Ein T. schrieb:
>> Das ist eine feine Sache, zum Beispiel PostgreSQL macht das so. Schick:
>> man kann die ganze Konfigurationsdatei auf den Defaultsettings lassen
>> und seine getunten Settings (pgtune, anyone?) schön übersichtlich
>> zusammen ans Ende der Datei schreiben, die überstimmen dann die oben
>> gesetzten Defaults.
>
> Wenn sich da nicht in den letzten Versionen etwas geändert hat, stehen
> die Defaults zwar drin, aber auskommentiert.

Das hängt vom Paketierer ab, beispielsweise das Paket von Ubuntu Linux 
setzt einige Werte -- warum auch immer, denn die gesetzten Werte stimmen 
meistens mit den Defaultwerten des Upstreams überein.

Wie dem auch sei, erscheint mir Dein Einwand hier leider nicht sehr 
relevant. Denn letztlich ist es gleichgültig, ob die am Ende eingefügten 
Werte bereits zuvor gesetzte Werte oder die eingebauten Defaultwerte 
überschreiben, oder?

von Ein T. (ein_typ)


Lesenswert?

Bauform B. schrieb:
> Das sind die lehrreichsten Aussagen für mich. Bisher sind die Programme
> gnadenlos, bei jeder kleinen Ungereimtheit wird ein Update verweigert.

Das würde ich auch weiterhin so halten, Konfigurationsdaten sind 
sensibel. Aber mit Levenshtein kannst Du immerhin aussagekräftigere 
Fehlermeldungen generieren und Deinen Benutzern helfen.

> Nur eins war übertrieben: eine neue
> Programmversion muss gefälligst eine korrekte alte Config akzeptieren.

Das würde ich nicht machen, denn sonst verbleiben einzelne Komponenten 
des Programms womöglich unkonfiguriert oder auf den Defaults. Aber es 
gibt ein probates Mittel, mit solchen Situationen umzugehen: 
Konvertierskripte oder -Programme, die zuerst ein Backup der alten Datei 
anlegen (think Downgrade), und die alten Konfigurationsdaten dann in das 
neue Format überführen. Diese Skripte werden einfach bei der 
Installation vom Paketmanager ausgeführt.

> Ein Beispiel für eine misslungene Erweiterung: das Programm war
> 2-sprachig, also gab es z.B. locale1 = fr_CH und locale2 = de_DE. Später
> waren mehr Sprachen möglich, also gibt es locales = "fr_CH de_DE". Für
> sowas muss man wohl individuelle Konverter-Funktionen bauen und locale1
> und locale2 bis in alle Ewigkeit akzeptieren.

Eine beliebte Methode für solche Updates ist, neben den 
Konvertierskripten oder -Programmen, die Deprecation. Das heißt: wenn Du 
die alten Direktiven hinauswerfen möchtest, wird eine "Deprecation 
Warning" ausgegeben, daß die Konfigurationsdirektive in der nächsten 
oder übernächsten Version wegfällt, stattdessen die neue(n) Direktive(n) 
benutzt werden sollen. Auch hier sind aussagekräftige Meldungen 
natürlich besonders komfortabel für die Benutzer.

Nachteil dieser Methode ist jedoch, daß die Software bis zur nächsten 
oder übernächsten Version -- wenn die alte Direktive entfernt wird -- 
zunächst beide Konfigurationsversionen unterstützen muß, was den Aufwand 
zumindest erhöht und manchmal sogar kaum möglich ist.

> Bei über 1500 Zeilen kann "am Ende" ganz schön weit weg sein; lieber
> nicht.

Naja, beim GNU Emacs sind das drei Tastendrücke, "ESC" und ">", und 
schon bin ich am Ende der Datei. ;-)

Bauform B. schrieb:
> Re D. schrieb:
>> In was für einem masochstischen Laden läuft Software die über ein 1500
>> Zeilen langes config-file konfiguriert wird? Das ist ja gruselig!
>
> Ganz so schlimm ist es nicht, das sind hauptsächlich Texte für 3
> Sprachen.

Verschiedene Locales -- das betrifft ja nicht nur Sprachen, sondern auch 
Dinge wie die Darstellung von Zahlen (1.234,56 vs 1,234.56) und 
kalendarischen Daten (DMY, YMD, MDY, YDM, was für ein Chaos) -- werden 
heute oft mit verschiedenen Dateien oder Verzeichnissen abgebildet, 
welche jeweils nach der betreffenden Locale benannt sind. Das erscheint 
mir eine ebenso gute wie übersichtliche Lösung zu sein, so daß Deine 
Konfigurationsdatei überschaubar, verständlich und kompakt bleibt.

Niklas G. schrieb:
> Bauform B. schrieb:
>> Könnte ich auf Debian eine DLL mit den Prüf-Funktionen erzeugen? Ich
>> glaube, ich sollte jetzt sofort etwas ganz anderes machen ;)
>
> Mach's in Python oder Java, dann spielt das OS keine Rolle...

Python, Java und Ähnliche erfordern die Installation eines Interpreters, 
und das gefällt nicht jedem Benutzer -- während andere das womöglich gar 
nicht dürfen, weil sie einen fremdverwalteten Computer benutzen müssen. 
:-)

Deswegen wäre mein Ratschlag eine Webapplikation in -- ja, 
möglicherweise nerve ich ein bisschen damit -- Golang. Das läßt sich 
ganz leicht durch das Setzen einiger Umgebungsvariablen und Pakete in 
nur eine einzelne, statisch gelinkte Datei mit eingebetteten Ressourcen 
crosskompilieren, und als Webapp nicht nur lokal, sondern auch auf einem 
Server betreiben. Noch komfortabler dürfte IMHO kaum möglich sein... :-)

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Ein T. schrieb:
> Python, Java und Ähnliche erfordern die Installation eines Interpreters,

Nö, da muss man nur ein ZIP herunterladen und entpacken.

Ein T. schrieb:
> während andere das womöglich gar
> nicht dürfen, weil sie einen fremdverwalteten Computer benutzen müssen.

Ein ZIP entpacken und die java.exe oder python.exe ausführen geht immer.

Ein T. schrieb:
> in
> nur eine einzelne, statisch gelinkte Datei mit eingebetteten Ressourcen
> crosskompilieren, und als Webapp nicht nur lokal, sondern auch auf einem
> Server betreiben.

Ist bei Java Web Apps schon seit Anbeginn der Zeit der Default

von Re D. (re_d272)


Lesenswert?

Bauform B. schrieb:
> Re D. schrieb:
>> In was für einem masochstischen Laden läuft Software die über ein 1500
>> Zeilen langes config-file konfiguriert wird? Das ist ja gruselig!
>
> Ganz so schlimm ist es nicht, das sind hauptsächlich Texte für 3
> Sprachen. Die interessanten Einstellungen stehen natürlich am Anfang

Doch es ist schlimm und gruselig. Sowas war in der 70er Jahren 
vielleicht state of the art, aber vor 15 Jahren sicher nicht mehr. Das 
ganze Konzept ist stümperhaft.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.