config-datei auswerten
Jörg Sommer
es gibt ja die allgemein bekannte Methode getopt und deren Namensfetter
zum Auswerten der Programmparameter. Gibt es aber auch ein Pendant für
config-Dateien, sprich rc-files, in den Standardbibliotheken ? Oder
sollte jedes Programm seine eigene config-Auswertung mitbringen ?
Jörg.
--
Ein halbleeres Glas Wein ist zugleich ein halbvolles,
aber eine halbe Lüge mit nichten die halbe Wahrheit.
Jean Cocteau
Anselm Lingnau
> es gibt ja die allgemein bekannte Methode getopt und deren Namensfetter
> zum Auswerten der Programmparameter. Gibt es aber auch ein Pendant für
> config-Dateien, sprich rc-files, in den Standardbibliotheken ? Oder
> sollte jedes Programm seine eigene config-Auswertung mitbringen ?
Also etwas, das annähernd so populär und verbreitet wäre, gibt es
leider nicht -- die Anforderungen verschiedener Programme gehen auch
etwas weiter auseinander als bei »getopt()«. Man vergleiche etwa
/bin/passwd, Sendmail und Emacs.
Die verschiedenen Möglichkeiten sind etwa diese:
1. Selbermachen. Man kann ganz simpel (mit fgets(), sscanf() & Co.)
anfangen oder gleich mit lex und yacc draufhauen (wenn man sowas
mag und die Syntax kompliziert genug ist). Hierbei ist das
Problem, daß man irgendwann über das Simple hinauswächst und sich
dabei ertappt, eine eigene kleine Programmiersprache definieren
und warten zu müssen. In dem Fall ist Option 4 wahrscheinlich
mit weniger Zahnschmerzen verbunden.
2. KDE und GNOME haben jeweils Bibliotheken, die Windows-artige
»INI-Dateien« auseinanderpflücken können. Ich weiß nicht, ob man
diese auch außerhalb von KDE bzw. GNOME benutzen kann, und nur
deswegen ein Programm von einer der beiden Desktop-Umgebungen
abhängig zu machen ist vielleicht auch etwas übertrieben.
3. Noch mehr aus der Overkill-Ecke: Man könnte die
Konfigurationsdateien in XML formulieren und einen der
verbreiteten XML-Parser verwenden, um sie zu lesen. Dies
ermöglicht gut strukturierte Konfigurationsdateien mit wenig
Aufwand (vorausgesetzt, man hat sich mal mit XML angefreundet)
und irgendwann in Zukunft bekommt man vielleicht einen schönen
Editor dafür geschenkt.
4. (Mußte ja kommen.) Man verwendet Tcl. Das ist auch anderswo im
Programm sehr nützlich.
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
The architecture, interface, and functionality of the Windows API make it
difficult to master and use effectively, and contribute negatively to the
safety, robustness, and portability of the applications developed under it.
-- Diomidis Spinellis, RISKS Digest 20.36
Friedrich Dominicus
> 4. (Mußte ja kommen.) Man verwendet Tcl. Das ist auch anderswo im
> Programm sehr nützlich.
5 Man nimmt ein Scheme und /oder Common Lisp und freut sich das man
ein Problem weniger hat, da schon ein vollständiger Parser vorhanden ist.
Bis dann
Friedrich
Rainer Weikusat
> Jörg Sommer <jo...@alea.gnuu.de> schrieb:
[config files lesen]
>
> 1. Selbermachen. Man kann ganz simpel (mit fgets(), sscanf() & Co.)
> anfangen oder gleich mit lex und yacc draufhauen (wenn man sowas
> mag und die Syntax kompliziert genug ist).
Der Vollständigkeit halber: Für name=value Paare lassen sich wunderbar
Shellskripte verwenden, die entsprechende Umgebungsvariablen setzten
(über einen Shell-Wrapper, der die Konfiguration sourcet, bevor er das
eigentlich Programm ausführt).
--
stone me
Andreas Krennmair
> zum Auswerten der Programmparameter. Gibt es aber auch ein Pendant für
> config-Dateien, sprich rc-files, in den Standardbibliotheken ? Oder
Unterstuetzung fuer apache-style Konfigurationsdateien ins eigene
Programm einbauen (z.B. kontextabhaengige Optionen).
hth, ak
[0]: http://www.azzit.de/dotconf/
--
chmod a+x /bin/laden
Andreas Ferber
>
> Der Vollständigkeit halber: Für name=value Paare lassen sich wunderbar
> Shellskripte verwenden, die entsprechende Umgebungsvariablen setzten
> (über einen Shell-Wrapper, der die Konfiguration sourcet, bevor er das
> eigentlich Programm ausführt).
Oder man macht es wie viele DJB-Programme: für jede Option eine Datei,
der Inhalt ist jeweils der Optionswert, der Dateiname die Option.
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - a...@devcon.net - www.devcon.net
Jörg Sommer
Ich glaube, den Weg würde ich auch bevorzugen.
It eigentlich mal sowas angedacht wurden ? Es gibt doch schon so einige
einheitliche Dinge :
'#' ist Kommentar
leeren Zeilen werden ignoriert
schlüsselwort wert -- ist eine oft gebrauchte Zuweisung
[Untersektion] -- Definiert eine Untergruppe
...
Hat GNU oder von wem auch immer die Standardlib stammt mal sowas
angedacht ?
Jens Dittmar
> 2. KDE und GNOME haben jeweils Bibliotheken, die Windows-artige
> »INI-Dateien« auseinanderpflücken können. Ich weiß nicht, ob man
> diese auch außerhalb von KDE bzw. GNOME benutzen kann, und nur
> deswegen ein Programm von einer der beiden Desktop-Umgebungen
> abhängig zu machen ist vielleicht auch etwas übertrieben.
Und dann Punkt 4?
> 3. Noch mehr aus der Overkill-Ecke: Man könnte die
> Konfigurationsdateien in XML formulieren und einen der
> verbreiteten XML-Parser verwenden, um sie zu lesen. Dies
> ermöglicht gut strukturierte Konfigurationsdateien mit wenig
> Aufwand (vorausgesetzt, man hat sich mal mit XML angefreundet)
> und irgendwann in Zukunft bekommt man vielleicht einen schönen
> Editor dafür geschenkt.
Ich denke tatsächlich schon mehr als nur leicht über SGML für sowas
nach (Ich mag XML irgendwie nicht, man verzeihe mir!), der Bedarf ist
aber derzeit nicht akut.
> 4. (Mußte ja kommen.) Man verwendet Tcl. Das ist auch anderswo im
> Programm sehr nützlich.
Das geht in Lisp auch ganz herzallerliebst, und ich habe mich dabei
erwischt, daß ich in Scheme gern ziemlich nativ schreibe und lese -
ebenso wie in Tcl. Eine solche Verbindung sollte man IMHO aber
vermeiden, oder willst Du Lispeleien auseinander-Tcl-n bzw. umgekehrt?
Siehe auch Punkt 2.
Kleine Illustration: Wir haben hier eine kommerzielle Software, bei
der ein Kristallmodell im nativen Dateiformat so aussieht:
(1 Model
(A I PeriodicType 100)
(A D A3 (5.8687500000000004 0 0))
(A D B3 (0 5.8687500000000004 0))
(A D C3 (0 0 5.8687500000000004))
(A C SpaceGroup "216 1")
(A I Id 1)
(A C Label "InP bulk cell")
(A I CRY/APPLYSPEC 1)
(A I CRY/BONDING 16)
(A I CRY/DISPLAY (64 256))
(A D CRY/TOLERANCE 0.050000000000000003)
(A C "Save-comment 1" "Wird das noch mal was?")
(2 Atom
(A C ACL "49 In")
[ ... ]
Der Kommentar kommt vom Frust durch den graphischen Modelleditor. :)
Die wirklich wichtigen Teile des Pakets sind aber in Fortran
geschrieben, und für Scripting wird Tcl verwendet.
It's a mixed up world ...
Jens
--
Sometimes you wonder where's the end
Where you're going, where you've been
Happiness seems so hard to win
Friedrich Dominicus
>
> Ich glaube, den Weg würde ich auch bevorzugen.
>
> It eigentlich mal sowas angedacht wurden ? Es gibt doch schon so einige
> einheitliche Dinge :
> '#' ist Kommentar
> leeren Zeilen werden ignoriert
> schlüsselwort wert -- ist eine oft gebrauchte Zuweisung
> [Untersektion] -- Definiert eine Untergruppe
> ...
>
> Hat GNU oder von wem auch immer die Standardlib stammt mal sowas
> angedacht ?
Hm soweit ich mich erinnere soll doch Scheme die Erweiterungsprache
für alle GNU Software werden und Guile ist doch gerade (auch) dafür
entwickelt worden um "eingebettet" zu werden. Es gibt eine Reihe von
Lisp Implementierungen bei denen gerade das das Design Ziel war. Nun
was es definitiv wohl auch geben wird ist irgendeine C library für das
einlesen von solchen ".ini" Dateien geben.
Bis dann
Friedrich
Anselm Lingnau
> Ich denke tatsächlich schon mehr als nur leicht über SGML für sowas
> nach (Ich mag XML irgendwie nicht, man verzeihe mir!), der Bedarf ist
> aber derzeit nicht akut.
Der Vorteil von XML gegenüber SGML ist, daß die Parser einfacher sind,
jedenfalls wenn man DTD-mäßig an allem interessiert ist, was die
Sprache erlaubt. (Man könnte natürlich hingehen und einen
Beinahe-SGML-Parser schreiben, wenn man sicher weiß, daß man nur
Beinahe-SGML parsen möchte.) Es gibt auch mehr brauchbare vorgekochte
Parser für XML als für SGML, was mit daran liegen mag, daß sich dieser
Tage alles in allem mehr Leute für XML interessieren als für SGML. Aus
gutem Grund, wie ich persönlich finde.
> Das geht in Lisp auch ganz herzallerliebst,
Ja, dasselbe in Grün ...
> Die wirklich wichtigen Teile des Pakets sind aber in Fortran
> geschrieben, und für Scripting wird Tcl verwendet.
> It's a mixed up world ...
Genau, so ist aber der Lauf der Welt. Wer glaubt, daß man alles in
einer einzigen Sprache x, x aus {Java, Ada, C++}, schreiben kann
bzw. sollte, der macht sich IMHO das Leben unnötig schwer. Gerade
unter Unix gab es ja schon (fast) immer die Shell zum Zusammenknüpfen
verschiedener Programme, und Tcl ist von der Idee her ja nichts
anderes als die Shell, mit vernünftiger Semantik und feinkörnigeren
Knüpfungsmöglichkeiten als »das hier ist die Ausgabe von A und die
schicken wir auf dem Umweg über einen ASCII-codierten Datenstrom als
Eingabe an B« und daher effizienter.
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
Computers are supposed to serve man, not vice versa, the experience of the
last 40 years notwithstanding. -- Larry Wall
Jens Dittmar
> Jens Dittmar <dit...@sonne.tachemie.uni-leipzig.de> schrieb:
>> Ich denke tatsächlich schon mehr als nur leicht über SGML für
>> sowas nach (Ich mag XML irgendwie nicht, man verzeihe mir!), der
>> Bedarf ist aber derzeit nicht akut.
>
> Der Vorteil von XML gegenüber SGML ist, daß die Parser einfacher sind,
Weil die Sprache insgesamt einfacher ist, das sehe ich schon ein.
Anselm Lingnau
> > Der Vorteil von XML gegenüber SGML ist, daß die Parser einfacher sind,
>
> Weil die Sprache insgesamt einfacher ist, das sehe ich schon ein.
SGML ist in vieler Beziehung darauf optimiert, von Leuten geschrieben
zu werden. Darum ist es in SGML zum Beispiel möglich, zu erlauben, daß
der Parser selbsttätig Endtags ergänzt, wenn diese nicht im Text
stehen, aber dem Kontext nach vorhanden sein müßten (ein HTML-basiertes
Beispiel dafür wäre etwas wie
<TABLE><TR><TH>Bla<TH>Fasel
<TR><TD>Blubb<TD>Bla</TABLE>
); was das Eintippen von solchen Dokumenten doch erheblich
erleichtert, die Parser dagegen nicht unerheblich verkompliziert.
Tatsächlich ist diese syntaktische Laxheit mit einer der Hauptgründe
für die babylonische Sprachverwirrung unter WWW-Browsern.
XML dagegen ist dafür gedacht, von Programmen geschrieben und gelesen
zu werden. Denen macht es nichts aus, zu allen öffnenden Tags auch die
schließenden zu schreiben, und Plattenplatz ist auch nicht mehr so
teuer wie zur Zeit der Erfindung von SGML. Darum sieht XML gerne mal
etwas geschwätziger aus als SGML, ist aber in sehr vielen Punkten
»entschlackt« und deshalb konzeptuell -- und implementierungstechnisch
-- einfacher. Implementierungstechnisch einfachere Sachen werden in
der Regel schneller fertig und haben weniger Fehler als
kompliziertere.
Dazu kommt als weitere Vereinfachung, daß SGML im Prinzip zwei
Sprachen in einer sind, nämlich die DTD-Sprache und die Sprache, in
der »Anwendungen« von SGML, also Sachen wie HTML, geschrieben sind
(»Sprache« ist hier natürlich ein etwas unpassender Begriff, aber die
»Syntaxen« der SGML-Anwendungen sind doch zumindest verwandt). In der
XML-Welt sind die wesentlichen Sprachen, die sich mit XML befassen,
selber auf XML basiert -- zum Beispiel XSLT, XSL-FO, XML Schema -- und
das ist auch konzeptuell eine nette Sache.
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
Quitting vi is the most important command of that editor, and should be bound
to something easy to type and available in all modes, for example the space
bar. -- Per Abrahamsen
Felix von Leitner
> SGML ist in vieler Beziehung darauf optimiert, von Leuten geschrieben
> zu werden. Darum ist es in SGML zum Beispiel möglich, zu erlauben, daß
> der Parser selbsttätig Endtags ergänzt, wenn diese nicht im Text
> stehen, aber dem Kontext nach vorhanden sein müßten (ein HTML-basiertes
> Beispiel dafür wäre etwas wie
> <TABLE><TR><TH>Bla<TH>Fasel
> <TR><TD>Blubb<TD>Bla</TABLE>
> ); was das Eintippen von solchen Dokumenten doch erheblich
> erleichtert, die Parser dagegen nicht unerheblich verkompliziert.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Wo kommt dieses renitente Gerücht eigentlich her?
Wer bekennt sich schuldig?
Wo soll ich den Mega-LART hinschicken?
Felix