Strukturierter Konfigurator und tr069-Umschalter

Braucht man den Strukturierten Konfigurator und den tr069-Umschalter in FREETZ?

  • Ja, beides kann man gut gebrauchen

    Stimmen: 17 70.8%
  • Den Konfigurator, aber nicht den Umschalter

    Stimmen: 3 12.5%
  • Den Umschalter, aber nicht den Konfigurator

    Stimmen: 3 12.5%
  • Man hätte Konfigurator in C schreiben sollen

    Stimmen: 1 4.2%
  • Nein, beides kann keiner gebrauchen

    Stimmen: 2 8.3%

  • Anzahl der Umfrageteilnehmer
    24
  • Umfrage geschlossen .

hermann72pb

IPPF-Promi
Mitglied seit
6 Nov 2005
Beiträge
3,724
Punkte für Reaktionen
16
Punkte
38
Hallo zusammen,

wie ich bereits irgendwo angekündigt hatte, war ich seit einigen Tagen am basteln, um einen tr069-De-/Aktivierungsschalter in FREETZ einzubauen. Mittlerweile habe ich eine Testversion bei mir im RAM der Box am Laufen, wie man in den Bildern auch sehen kann. Wann und ob es in FREETZ einfließen wird, kann ich momentan nicht sagen. Eine Testversion des GUIs habe ich momentan auch noch nicht zu vergeben.

Der Grund, warum ich mich hier bereits jetzt melde ist mein Strukturierter Konfigurator structcfg, den ich auf dem Wege zur Realisierung des oben beschriebenen Problems erstellt hatte. Die erste Version dieses Konfigurators will ich heute hier posten, damit es ein oder anderer anschauen und testen kann.

Der Konfigurator dient dazu, Variablen und Strukturen aus diversen AVM-Config-Dateien der Box auszulesen und die Variablen zu setzen. Bis jetzt hat es jeder mit eigenen Kräften gegrept, geawkt und gesedet. Nun soll es deutlich einfacher gehen:

Code:
Usage: structcfg COMMAND PARAMETERS VA.LUE.NAME [VALUE]
 
 COMMANDES:
 get           get value
 set           set value
 struct        show available substructures
 values        show available values
 full          show all informations about current structure
 errorcodes    show errorcodes of this script
 
 PARAMETERS:
 -s            slow speed (safe method using structured search)
 -c            decode passphrases (slow)
 
 VA.LUE.NAME   structured value name: e.g.
                  ar7.ar7cfg.dpconfig.accesslist
                  tr069 (not for get/set value)
                  tr069.enable = tr069.tr069cfg.enable
                  voip.ua1.register
 
 VALUE         value to be set: e.g. yes or "wlan" (with quotes!)
-----------------------------------------------------------------------

 ERRORCODES:
  0  no errors
  1  configuration file cannot be read (must exist and be character device)
  5  value is corrupt or not exist (check value name!)
 10  value name is not defined (only structure is defined)
 15  value can not be set (common error)
 33  merging problem with configuration file
 55  wrong parameters (show program help)
 66  show error codes
     list of values instead of value is displayed

Also im Falle von tr069 kann ich z.B. den Wert mit
Code:
structcfg get tr069.tr069cfg.enabled
auslesen und mit
Code:
structcfg set tr069.tr069cfg.enabled no
auf "no" setzen.

Ich bitte die Mutigen unter uns diesen Skript zu testen / durchzuschauen und ihre Meinungen dazu hier zu äußern.

Einige Warnungen und Einschränkungen:
1. Dieser Skript arbeitet direkt mit Konfigurationsdateien auf der Box (also quasi Operation am offenen Herzen). Daher nicht für Anfänger geeignet. Sichert bitte vorher eure Einstellungen!
2. Getestet ist es mit einfachen Variablen (vor allem einzeilig!). Ich hab zwar versucht einige Sonderfälle wenigstens im Lesemodus abzufangen, garantieren kann ich aber nichts.
3. Die Geschwindigkeit ist das Hauptproblem an der ganzen Geschichte. Deswegen gibt es die langsame und die schnelle Abfrage. Vor allem bei der ar7.cfg kommt es zu deutlichen Verzögerungen beim lesen. Als ich schon fast fertig damit war, ist mir aufgefallen, dass es wahrscheinlich mit C anstatt Shellskripting+sed besser gegangen wäre.

Viel Spass!
 

Anhänge

  • structcfg.gz
    2.5 KB · Aufrufe: 18
  • mod_extras.jpg
    mod_extras.jpg
    36.9 KB · Aufrufe: 69
  • tr069_aktiv.jpg
    tr069_aktiv.jpg
    34.2 KB · Aufrufe: 65
  • tr069_inaktiv.jpg
    tr069_inaktiv.jpg
    33.3 KB · Aufrufe: 61
Hei hermann,

ein tolles Stück arbeit, um das mal anzumerken. Das du dich an die verkrautete Config der avm-Kisten überhaupt Scriptgesteuert rangewagt hast, ist grossartig. Ich denke, die SH ist da das beste Stück Wahl, zwar nciht immer und sonderlich schnell, aber dennoch ausreichend, denn ein ordentlicher Teil der Laufzeit ist immer noch auch das Lesen/Schreiben des Flashs. Da kann C nichts beschleunigen.

Himmel, bei den sed's kann einem ja schwindelig werden ;)
 
Naja, wenn ich sed richtig vom Grund her verstanden hätte, würde ich wahrscheinlich eine oder andere Sache besser implementieren können. Ich will damit sagen, es sieht so wild aus, weil ich es nicht richtig kann. Würde ich es richtig können, würde es auch wahrscheinlich schneller durchlaufen. Versuch mal dieses Skript im "slow"-Modus über die ar7.cfg laufen zu lassen, dann wirst du sehen, dass es schon schön langsam ist. Und lass mal vergleichsweise "cat ar7.cfg" durchlaufen. Deswegen hatte ich dieses Quick-schnell-Modus da eingeführt, damit man auch die ar7.cfg in einer absehbaren Zeit auslesen kann.
Beim Zurückschreiben gehe ich nach der bekannten Methode von regedit aus Windows-Welt. Ich generiere zunächst eine umgeschleifte Struktur um die Variable herum und danach mache "merge" mit dem AVM-Tool.
Wie gesagt, während des Programmierens ist mir aufgefallen, dass diese ganzen { } könte man deutlich einfacher und schneller mit C zählen. Man hätte in C einfach einen Zähler aufbauen können und damit wäre alles deutlich einfacher. So machen es anscheinend die AVM-Entwickler. Wenn ich mir deren Binaries ansehe (meistens je so um 10kB Größe), kommt der Verdacht nah, dass sie zum größten Teil aus Standard-IO-Libraries bestehen Plus ein Paar Zeilen Code.
In diversen sed-Foren und Howtos kursieren Legenden, dass sed eigentlich eine Programmiersprache ist, und man kann angeblich damit sogar rechnen und nicht nur Texte durchsuchen. Das können aber nur die ganz wenigen.

MfG
 
Hallo Hermann,

super Sache. Ich habe bisher nur das Auslesen mit der ar7 getestet und das vielleicht noch etwas zu kurzfristig. Aber finde das schon ziemlich cool. Wenn ich das richtig verstehe, funktioniert das mit allen *.cfg die unter /var/flash/ liegen und wie ar7.cfg, tr069.cfg, wlan.cfg, usw... aufgebaut sind?

Den tr069 Umschalter benötige ich wahrscheinlich nicht, da die tr069.cfg bei mir leer ist:
Code:
cat: can't open '/var/flash/tr069.cfg': No such file or directory

Aber finde das für die ar7.cfg ganz interessant. Im "Slow-Modus" funktioniert das Auslesen wie es soll. Im schnellen Modus kann es schonmal zu doppelten Einträgen kommen:
Code:
# Fast:
./structcfg get ar7.ar7cfg.mode
dsldmode_router
serialmode_off

# Slow (ok):
./structcfg get -s ar7.ar7cfg.mode
dsldmode_router

Bzgl. der Geschwindigkeit könnte man überlegen, das Skript auch auf Java umzustellen und den Client rechnen zu lassen. Jedoch fehlt dann die Konsolenmöglichkeit :(
 
Die Hauptunterschiede zwischen dem schnellen und dem langsamen Modus sind Folgende:
1. Im schnellen Modus wird nach der klassisch-bekannter Methode gesucht:
a) Schlüsselname (ich nehme den allenletzten vor der Variablennamen)
b) Wenn Schlüssel gefunden wird, wird bis zum nächsten } gesucht, wobei es versucht wird, die zwischenstehenden {{}} "auszublenden". Ob es beim schnellen Modus vernünftig und zuverlässig geht, bezweifle ich.
c) Inhalt des Schlüssels wird ausgelesen
2. Beim langsamen Modus mache ich die Auswertung dagegen in zwei Schritten
a) Im ersten Schritt wird die ganze Datei ausgelesen, um die Hauptsektionen zu entdecken. Dies ist sehr wichtig für diese bescheuerte ar7.cfg, die neben der ar7cfg-Sektion noch Tausende andere Sektionen hat. Für andere Dateien wäre es nicht notwendig, weil sie nur eine hauptsektion haben
b) Nachdem die Sektionen ausgelesen sind und namen bekannt sind, wird in dieser Liste die Position der Sektion ermittelt, worin weiter gesucht werden sollte. Als Endmarker für die Suche dient dann der Name der nachfolgender Sektion. Dies erlaubt die Suche im zweiten Schritt nicht über die ganze Datei durchzuführen, sondern nur über den Abschnitt der betroffenden Sektion.
c) Nun kommt Schritt 2 zur eigentlichen Suche, ähnlich, wie in der schnellen Variante.
Ihr könnt fragen, warum so viel Aufwand und wozu es gut sein sollte. Die Hauptprobleme liegen daran, dass einige Variablen hinter den Subsektionen mit deren {{}} liegen können (schaut einfach in ar7.cfg oder in tr069.cfg rein!). Meiste Suchalgorithmen, die ich bis jetzt gesehen hatte suchten eben nach } als Endmarker und dies würde scheitern, wenn die Variable hinter der Subsektion liegen würde.

Aber zurück zu deinen Fragen, Marco. Wahrscheinlich sucht die schnelle Methode doch falscherweise in irgendeiner Subsektion und findet da die gleichnamige Variable. Ich schaue es mir auf jeden Fall an. Und ich bitte weitere Tester solche Fälle zu provozieren!

Zu den Configs: Ja, theoretisch sollte es mit allen AVM-configs gehen. Getestet mit ar7.cfg, voip.cfg und tr069.cfg. Wenn man Passwörter entschlüsselt oder den Wert schreibt, wird AVM tool da hinzugezogen. Dieses tool könnte die Dateinamen filtern. Ich mache aber zunächst mal einen Test, ob die Datei existiert und character device ist.

Marco, kannst du bitte den Konfigurator bei dir aufrufen und versuchen den Wert tr069.tr069cfg.enabled auszulesen? Und unmittelbar danach noch "echo $?" auszuführen. Dein Fall ist sehr typisch (character existiert, aber irgendwie nicht richtig). Ich kann es aber bei mir nicht mehr reproduzieren. Mich würde das Verhalten des Skriptes interessieren und ob der Fehler erkannt wird, oder doch nicht und Skript irgendwo sich verläuft oder was auch immer. Normalerweise sollte es mit Fehler 1 (s. Fehlerliste) ohne abzustürzen und großartig Fehler in die Gegend zu spucken terminieren.

MfG
 
Das du dich an die verkrautete Config der avm-Kisten überhaupt Scriptgesteuert rangewagt hast, ist grossartig.

Hmm, für mich sehen die cfg-Dateien aus wie JSON - Dateien aus ... kann mich aber auch täuschen. Wenn nicht, dort gibt es auch schon einiges an Beispiel-Code in verschiedenen Sprachen
 
Das sieht ähnlich aus. Danke für diesen Link. Man kann da sicherlich viel abgucken. Allerdings sind die AVM-Regeln da sehr freizügiger. Es gibt z.B. in ar7.cfg (und in anderen auch) ganz viele Namenlose Subsektionen. Manche haben intern einen "name", es ist aber auch da nicht einheitlich. Das sollte die AVM-Parodie auf Arrays sein. Nur bei diesem JSON werden Arrays logischerweise mit [] definiert, um es von Strukturen {} zu unterscheiden. AVM macht dies aber nicht. Und mein Konfigurator kann mit diesen Pseudo-Arrays bis jetzt nicht vernünftig umgehen.

MfG


Edit:
@bodega:
Code:
/var/mod/root # structcfg get ar7.ar7cfg.mode
dsldmode_router
/var/mod/root # structcfg get -s ar7.ar7cfg.mode
dsldmode_router
Ich kann deinen Fehler leider nicht reproduzieren. Kannst du bitte mit "grep", "awk" oder "sed" in deiner ar7.cfg nach dem Wert suchen und hier die entsprechende Passage posten?
 
Zuletzt bearbeitet:
Denke mal, es steht und fällt damit, ob man das (inkl. der Merkwürdigkeiten) noch in einer deterministisch kontextfreien Grammatik darstellen kann. Wenn ja, würde ich zur Langzeitstabilität empfehlen, den sed-Ansatz wegzukippen (obwohl ich aus eigenen Versuchen weiss, wieviel Arbeit da drinstecken muss), und einen ordentlichen Parser auf die Beine zu stellen. Das wäre dann eine klassische Aufgabe für bison/flex.

http://de.wikipedia.org/wiki/Parser-Generator

(edit: Das hier sieht nach einer brauchbaren Kurzeinführung für Einsteiger aus: http://www4.tu-ilmenau.de/ate/TET/nlnet/flex_bison.html )
 
Zuletzt bearbeitet:
Hallo Hermann,

der Exitstatus ist bei mir 5:
Code:
# ./structcfg get tr069.tr069cfg.enabled; echo $?
cat: can't open '/var/flash/tr069.cfg': No such file or directory

5
Und mit cat:
Code:
# cat /var/flash/tr069.cfg; echo $?
cat: can't open '/var/flash/tr069.cfg': No such file or directory
1

Bzgl. des doppelten Eintrags hatte ich vorerst diese beiden Variablen in Verdacht:
Code:
ar7cfg {
        [COLOR="Red"]mode = dsldmode_router;[/COLOR]
        tsdisabled = no;
        igddenabled = no;
        igdd_control_enabled = no;
        wan_bridge_with_dhcpc = yes;
        wan_bridge_gateway = 0.0.0.0;
        dhcpc_use_static_dns = no;
        ethmode = ethmode_bridge;
        tcom_targetarch = no;
        StatisticStartOfMonth = 1;
        macdsl_override = 00:00:00:00:00:00;
        serialcfg {
                [COLOR="Red"]mode = serialmode_off;[/COLOR]
                pin = "";
                number = "*99#";
                provider = "internet.t-mobile";
                username = "$$$$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
                passwd = "$$$$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
                chatscript_init = "ABORT BUSY ABORT 'NO CARRIER'",
                                  "ABORT VOICE ABORT 'NO DAILTONE'",
                                  "ABORT 'NO ANSWER' ABORT DELAYED",
                                  "FATAL 'incorrect password'",
                                  "FATAL '\nERROR\r\n'", "TIMEOUT 5",
                                  "'' ATZ",
                                  "OK AT+CPIN? READY-AT+CPIN=${pin} OK",
                                  "TIMEOUT 20",
                                  "'' 'AT+cgdcont=1,\"IP\",\"${provider}\"'",
                                  "OK 'AT&FE0V1X1&D2&C1S9=0'", "OK";
                chatscript_connect = "ABORT BUSY ABORT 'NO CARRIER'",
                                     "ABORT VOICE ABORT 'NO DAILTONE'",
                                     "ABORT 'NO ANSWER' ABORT DELAYED",
                                     "TIMEOUT 20", "'' 'ATDT${number}'",
                                     "CONNECT", "WAIT 2";
                stay_always_online = no;
                inactivity_timeout = 1m;
        }
Ein grep gibt daher folgendes aus:
Code:
# cat /var/flash/ar7.cfg | grep "mode ="

        mode = dsldmode_router;
        ethmode = ethmode_bridge;
                mode = serialmode_off;
                hansenet_manual_mode = no;
                hansenet_manual_mode = no;
                lcpecho_disconnect_mode = lcpecho_auto;
                icbmode = pppcfg_icbmode_none;
                ocbmode = pppcfg_ocbmode_none;
                lcpecho_disconnect_mode = lcpecho_auto;
                icbmode = pppcfg_icbmode_none;
                ocbmode = pppcfg_ocbmode_none;
        expertmode = yes;
        dsl_pushmail_mode = 0;
        eth0_mode = 2;
        eth1_mode = 1;
        eth2_mode = 1;
        eth3_mode = 1;
Getestet mit Standard-FW der 7170 (29.04.67, busybox v1.12.3).

Falls ich noch irgendwie etwas testen kann, sag einfach bescheid. Falls mir noch etwas auffallen sollte, poste ich natürlich.
 
Zuletzt bearbeitet:
@linuxservice: Danke für die Infos. Man kann sicherlich von dort Einiges abgucken, direkt kannst du es aber nicht verwenden. Die Aufgabe ist völlig anders, wenn ich es richtig verstanden habe. Der Parser soll die Programme auf ihre Korrektkeit überprüfen. Hier ist es erstmal nicht erforderlich. Wie man die {} zusammenzählen kann, sehe ich in C nicht als Problem. Und für Kommentare entfernen würde ich trotzdem eher sed benutzen. Dafür ist sed primär da und ist auch schnell. Die Geschwindigkeitsprobleme kommen daher, weil ich nach mehreren komplizierten Muster (vor allem mit Platzhalter) suche, um die Zählung von {} umzugehen. Syntax könnte man sicherlich auch kontrollieren, das wäre aber eine andere Aufgabe.

@bodega: kannst du bitte deinen Abschnitt mit dem zweiten "mode" noch wenigstens bis zum nächsten } (Abschnittsende) posten? Und checke bitte, ob alle { auch entsprechend irgendwo in einer } enden. Das Problem ist eindeutig der zweiter Wert mit dem gleichen Namen. Normalerweise sollte aber der Konfigurator es auch im Schnellmodus erkennen. Woher kommt übrigens diese Sektion (serialcfg)? Ich habe bei meiner 7170 sowas gar nicht drin.

Aber was ich gut finde, und was bei sed nicht selbstverständlich ist, es ist mir doch gelungen, dass der Konfigurator nicht "ethmode" nimmt, wenn man nach "mode" sucht. Denn Letzteres ist das Bestandteil vom ethmode.

MfG
 
Ist geändert ^^

Leider habe ich auch keine Ahnung, wo die Sektion "serialcfg" her kommt. Ich dachte immer, das wäre überall gleich...

Die Bereiche, die mit { beginnen, enden auch alle mit }. Jedoch scheint es so, als kämen in den Werten auch geschweifte Klammern vor. Vielleicht kommt das Skript hier durcheinander? Ich teste das mal... moment...

EDIT:
Also es scheint nicht an den geschweiften Klammern innerhalb des Wertes zu liegen. Ich habe die ar7.cfg auch mal stark reduziert. Der doppelte Eintrag bleibt aber:
Code:
ar7cfg {
        mode = dsldmode_router;
        tsdisabled = no;
        igddenabled = no;
        igdd_control_enabled = no;
        wan_bridge_with_dhcpc = yes;
        wan_bridge_gateway = 0.0.0.0;
        dhcpc_use_static_dns = no;
        ethmode = ethmode_bridge;
        tcom_targetarch = no;
        StatisticStartOfMonth = 1;
        macdsl_override = 00:00:00:00:00:00;
        serialcfg {
                mode = serialmode_off;
        }
}

Ich hab dann mal in structcfg (Zeile 290), ein 'head -n 1' eingefügt. Dann klappt es:

Code:
...
    if [ $COMMAND = "get" -o $COMMAND = "full" ]; then
        TESTVAL=$(echo "$VALUE" | sed -n -e "/[=\;]/!d;p")
        if [ -n "$TESTVAL" ]; then
            VALUE=""
        fi
        if [ -z "$VALUE" ]; then
            ERROR=5
        fi
        echo "$VALUE"[COLOR="Red"] | head -n 1[/COLOR]
    fi
...
Jedoch kann ich momentan noch nicht absehen, ob es Auswirkungen auf die anderen Parameter hat.
 
Zuletzt bearbeitet:
@linuxservice: Danke für die Infos. Man kann sicherlich von dort Einiges abgucken, direkt kannst du es aber nicht verwenden. Die Aufgabe ist völlig anders, wenn ich es richtig verstanden habe. Der Parser soll die Programme auf ihre Korrektkeit überprüfen. Hier ist es erstmal nicht erforderlich.

Das tut er ganz nebenbei. In erster Linie erhältst Du damit eine tokenisierte Repräsentation der Eingabe. Auf der kannst Du dann weiterarbeiten (auch wenn Du zur Zeit nur vorhast, eine Zuweisung zu ändern). Wenn Du dann statt eines Compilers einfach nur die Ausgabe der tokenisierten Version im Ursprungsformat dranbappst...

Vorteile: Die Ausgabe ist automatisch syntaktisch korrekt. Und wenn das Format mal erweitert werden sollte, ist das schlimmstenfalls mit einer Änderung der Grammatik abgehakt. (BTW, selbst wenn sich die Configsyntax nicht in BNF darstellen lassen sollte - Bison kann auch GLR).

Der sed-Ansatz fliegt u.U. schon auf die Nase, wenn da plötzlich die falsche Variable neu eingeführt wird, mit der Du im Moment noch nicht rechnest.
 
Hi Herman,

hab es noch nicht getestet, fände aber speziell den Konfigurator einen echten "Meilenstein" in der Entwicklung!

Kann man den ggf. dann auch für "komplette Zeilen" nutzen? Wenn man z.B. die Firewall-GUI um die ganze SEDerei, AWKerei usw. entlasten könnte, wäre das genial.
Auch für das Extrahieren von anderen Dingen aus der ar7.cfg (für mein Projekt "ohne dsld und multid") ist es sicher toll, Daten nicht selbst zu suchen sondern sich auf eine verlässliche Basis abzustützen, speziell weil man nie weiß, ob es nicht in einer anderen Box wieder ganz leicht anders aussieht ;-)

Nochmals: Klasse Idee!


Jörg
 
@linuxservice: Es hört sich stark nach theoretischer Informatik an. Es freut mich, dass man es methodisch angehen kann. Ich hab es aber leider nicht studiert und habe keine Zeit es mir nebenbei anzueignen. Wie gesagt, wenn jemand es nach diesem Ansatz lösen kann, kann er es gerne tun. Ich werde als erster ihm dankbar sein. Man muss nur nicht vergessen, dass die Box relativ klein ist und den parser dementsprechend gestalten.
Mit sed ist mir schon bewußt, dass es nur eine Fummellösung ist.

@bodega: Ich vermute Probleme eher in den Sonderzeichen / und \. Könnte aber auch sein, dass die schnelle Methode einfach bis zum Ende der Config durchläuft (muss ich schauen, weiß nicht mehr genau). Es gibt halt zwei Alternativen bei der schnellen Suche:
1. Bis zum nächsten { oder } zu suchen. Dann verliert man die Variablen hinter den eingeschleiften Strukturen.
2. Bis zum Ende der Datei zu suchen und alle Verschachtelungen mitnehmen. Mit der Gefahr, wenn die Unterstrukturen gleichnamige Variablen haben, werden sie auch "mitgenommen".
Es sieht so aus, dass ich momentan die zweite Variante benutze.

Edit:

@MaxMuster: Zuverlässig ist noch nichts. Lass es einfach durchlaufen und schaue mal, was es ausspuckt. Je mehr Leute es testen, desto besser. Eure AVM-Firewall-CGI hatte ich übrigens als Referenz genommen. So schlecht sind die ganzen sed-s und awk-s da auch nicht. Da ich allerdings awk gar nicht beherrsche, hab ich da gar nicht verstanden, obwohl es vermutlich ähnlich läuft.
Ich würde dir dankbar sein, wenn du es mit mehrzeiligen Variablen testen würdest. Aber bitte erstmal im Lesemodus. Gerade bei der Firewall verwenden man solche Variablen. Der zweite Hacken, der momentan gar nicht geht: Namenlose Strukturen. Und davon gibt es reichlich im Firewallbereich von ar7.cfg
Wie schreibt ihr denn in die ar7.cfg rein? Benutzt ihr auch diese merge-Funktion vom avm-Tool?


MfG
 
Zuletzt bearbeitet:
wenn jemand es nach diesem Ansatz lösen kann, kann er es gerne tun. Ich werde als erster ihm dankbar sein. Man muss nur nicht vergessen, dass die Box relativ klein ist und den parser dementsprechend gestalten.

Wollte Dich auch nicht davon abbringen, nur eine vielleicht sinnvollere Variante vorschlagen. Mir persönlich fehlt dank Diplomarbeit im Moment jegliche Freizeit.
Da Du Dich schon mit sed-Ausdrücken rumschlägst, dachte ich, dass Dich Grammatiken auch nicht schocken dürften ;) Die Tools führen übrigens nicht zu bloated code, ganz im Gegenteil. bison/flex bzw. die Unix-Vorläufer yacc/lex haben ihre Ursprünge in den späten 70ern. Da wäre unsere Fritzbox noch ein Grossrechner gewesen ;)
 
Zuletzt bearbeitet:
@bodega: Das "head -n 1" allerdings lässt weitere Matches einfach untergehen. Ob das so gut ist.... ;)
 
@Silent-Tears:
Kommt ganz drauf an. Ich habe mir die seds noch nicht im Ganzen angeschaut.

Jedoch sind die Einträge der ar7.cfg hierarchisch aufgebaut. Im Falle von get und set könnte man sogar (der Geschwindigkeit halber) nur den ersten, gefundenen Eintrag zurückliefern/ändern. "mode =" dürfte nie zweimal in der Ebene "ar7cfg" vorkommen, jedoch aber in weiteren Unterebenen.

Sobald der Eintrag in der jeweiligen Ebene gefunden wurde, kann man aufhören zu zählen und spart etwas Zeit. Jedoch ist eine Berücksichtigung der Ebenenen unabdingbar. Natürlich zählen auch Mehrzeilige Werte dazu (wie z.B. chatscript_init =).

Wie das nun bei structcfg genau aussieht, kann nur Hermann beurteilen (dafür habe ich mich in das Skript zu wenig eingelesen).
 
Das Hauptproblem sind eben diese Unterebenen beim Finden des Abschnittsende. Ich habe mit sed keine Möglichkeit gefunden die ganzen {} zu zählen. Und ohne zu zählen geht es halt nur mit komplizierten Suchmustern.
Die Idee mit Suche aufzuhören, sobald gefunden wurde finde ich gut, die Frage ist nur, wie bringe ich es sed vernünftig bei. Was sich aber auf jeden Fall realisieren ließe, das Ignorieren des zweiten Wertes.

Die Mehrzeiligen Werte in den Variablen sollen sich wenigstens beim Auslesen korrekt verhalten. Beim schreiben hab ich nicht überprüft und kann nicht garantieren. Übrigens, was hält ihr davon, so ein -d (Debug)-Schalter für Testzwecke einzuführen? Dann würde ich z.B. beim Schreiben es nicht tatsächlich tun, sondern nur die Struktur simulieren und sie ausgeben. Sieht dann in etwa so aus:
Code:
Hauptstruktur {
                   Unterstruktur1 {
                                       Unterstruktur2 {
                                                           Variable = "Wert";
                                                            }
                                       }
                    }
Wird auch so gemacht und in einer temp-Datei abgelegt, bevor es mit der eigentlichen config gemerget wird.

MfG
 
Debug ist immer gut, vor allem, wenn man Fehler sucht bzw. sich etwas ändert. Von daher, gern. Ich sollte mir die ar7 mal angucken genauer, ob sich da nicht doch etwas verallgemeinern lässt. Aber sed durhc relativ komplexe Sachen zu jagen ist nicht immer gut. Da ist deine anfängliche Vermutung schlicht besser. Etwas anderes als die Shell zu nutzen ist da nicht zwangsläufig verkehrt.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.