[PATCH] vdr-2.1.10: CLI Help ---> argsdir Templates (/etc/vdr/conf.d/*.conf.tmpl oder /tmp/*.conf.tmpl)

Hallo,

ich hatte mir gedacht dass es doch praktisch wäre, wenn man beim Erstellen von neuen oder Updaten nach Erweiterung von CLI-Parametern, von argdir-Konfigdateien etwas Unterstützung hätte. Die ist ja praktisch fast onboard, und zwar die Ausgabe der CLI-Hilfe. Ich habe nur noch Änderungen erstellt die über einen zusätzlichen CLI-switch --tmplargs mit optionaler Angabe eines Verzeichnisses (default: /etc/vdr/conf.d) für den VDR oder explizit angegebene Plugins (oder auch alle mit -P'*'), diese Templates erstellt, mit auskommentierter CLI-Hilfe oder dem Hinweis dass es keine Argumente für die CLI gibt. Die müssen dann nur noch in das eigentliche Verzeichnis woher sie VDR nutzt (/etc/vdr/conf.d) oder ein anderes, wo sie ein distributionsspezifisches Tool verwaltet (/etc/vdr/conf.avail oder ähnlich) mit der Extension *.conf umbenannt und editiert werden, dass es für die Distribution oder die eigenen Wünsche passt. Praktisch finde ich dass die ganze CLI-Hilfe kommentiert mit dabei ist.

# vdr --tmplargs
vdr: successfully generated config template: /etc/vdr/conf.d/vdr.conf.tmpl

Die Datei würde dann so aussehen, man muß nur noch zwichen den jeweiligen Beschreibungen die gewünschten Parameter auch tatsächlich unkommentiert angeben:

# cat /etc/vdr/conf.d/vdr.conf.tmpl
# Please move/rename this file to argsdir with just the .conf extension and edit it with one option per line as needed.
# vdr (2.1.10) - The Video Disk Recorder
[vdr]


#Usage: vdr [OPTIONS]
#
# -a CMD, --audio=CMD send Dolby Digital audio to stdin of command CMD
# --cachedir=DIR save cache files in DIR (default: /var/cache/vdr)
# --chartab=CHARACTER_TABLE
# set the character table to use for strings in the
# DVB data stream that don't begin with a character
# table indicator, but don't use the standard default
# character table (for instance ISO-8859-9)
...
...

Und für Plugins:

# vdr --tmplargs -P'graphlcd' -P'softhddevice' -P'skindesigner'
vdr: successfully generated config template: /etc/vdr/conf.d/graphlcd.conf.tmpl
vdr: successfully generated config template: /etc/vdr/conf.d/softhddevice.conf.tmpl
vdr: successfully generated config template: /etc/vdr/conf.d/skindesigner.conf.tmpl

Ein Beispiel für eine Plugin-Konfig:

# cat /etc/vdr/conf.d/skindesigner.conf.tmpl
# Please move/rename this file to argsdir with just the .conf extension and edit it with one option per line as needed.
# skindesigner (0.2.2) - Skin Designer
[skindesigner]


# -s <SKINPATH>, --skinpath=<SKINPATH> Set directory where xml skins are stored
# -l <LOGOPATH>, --logopath=<LOGOPATH> Set directory where a common logo set for all skins is stored
# -e <EPGIMAGESPATH>, --epgimages=<IMAGESPATH> Set directory where epgimages are stored

Ich habe meine Änderungen zur Nachvollziehbarkeit in 2 Patches unterteilt und erachte sie nicht wirklich als invasiv. Der erste Patch konsolidiert nur die VDR-eigene CLI-Hilfe in eine Funktion, damit man sie auch beim Generieren des Templates nutzen kann, bei Plugins war das schon sowieso gegeben, das heisst dieser erste Patch sollte rein gar nichts an der Funktionalität des VDR ändern. Es ist der zweite Patch der den neuen CLI-Parameter und das Generieren der Templates einführt.

Vielleicht findet jemand sowas auch praktisch...

Ciao,
Lucian

Later Edit:

• Patch 0002 in 2ter Version nun, generiert im argsdir-Verzeichnis auch für Plugins ohne Parameter das Template, die Erweiterung ist .tmpl
• Patch 0003 biegt das Verzeichnis für die Templates doch auf /tmp um, weil es ja nur Templates sein sollen, die in der Form und Dateiendung nicht irgendwo unter /etc/vdr/.. landen sollten.
• Nochmal zur Erläuterung, nachdem dieser Thread in Diskussionen über vdrctl ausgeartet ist: Mir ging es bloß um das Look'n'feel der Configs, welches an die verrtraute Ausgabe der CLI-Hilfe erinnern sollte, welches man so distributionsübergreifend hätte vereinheitlichen können, so wie z.B. diese paar meiner gesymlinkten Configs, die vdr.conf , die softhddevice.conf oder auch mal pin.conf um auch ein Plugin ohne Parameter zu zeigen, aber viele wollen das scheinbar nicht. Bei Gentoo habe ich schon gute Gründe zu glauben, das wir das so machen werden...

Zitat von TheChief

Hm interessant, aber brauchts dazu einen Patch des VDR? Tuts nicht auch ein kleines externes Tool, was "vdr --help" parst und solche templates oder .conf Dateien erstellt?

Tja, diesen "Spaß" das extern zu parsen wollte ich anderen überlassen, habe einfach die für mich schnellste zielführende Variante gestern Abend mal umgesetzt...
Later Edit: Das soll nur ausdrücken, das ich damit nicht wirklich Spaß gehabt hätte, ich weiß sehr wohl dass es geht, ich hätte es wohl auch hinbekommen, aber für mich mit erheblich mehr Aufwand. Zudem hatte ich diese Idee weil es auch --showargs im VDR gibt, das braucht man auch nicht unbedingt...

Ciao,
Lucian

Zitat von mini73

Das ist eine nette Idee, hat aber für meinen Geschmack den Nachteil, dass die Informationen in den Templates veralten und nicht aktuell gehalten werden können.

Mir ging es darum, das Template jederzeit mit Bordmitteln (deswegen im VDR) aktuell halten zu können, egal ob ich Maintainer oder fortgeschrittener User bin.

Zitat von mini73

Da würde ich auch eher eine externe Lösung bevorzugen, die dem Nutzer die Hilfe direkt aus dem vdr präsentiert.

Das ist die Hilfe direkt aus dem VDR, nur fertig auskommentiert und mit [section] im Template.

Zitat von M-Reimer

Ich hatte eigentlich die Hoffnung, dass Plugin-Autoren irgendwann selber ein "Template" mitliefern und dieses dann beim "make install" im Idealfall auch installieren.

Die Hoffnung habe ich auch, aber ich bin mir sicher, etliche werden gar nichts liefern. Mit etwas Hilfe vieleicht schon, oder wenn der Maintainer das ausbaden muss, dachte ich mir die Hilfe ist ihm willkommen

Zitat von M-Reimer

Würde es denn gehen bei einem "noch nicht installierten" Plugin mit deinem Tool/Patch das Template für das Verpacken im Distributions-Paket zu erstellen?

Eventuell wäre es sogar garnichtmal so verkehrt den Versuch zu machen sowas auszulagern? Eigenes Tool "vdr-mkconftemplate" oder so ähnlich das als Argument den Pfad zur ".so" bekommt und dann auf STDOUT das Template auswirft? Dürfte für Distributoren praktischer sein, denn dort wird beim Paketieren ja kein Plugin installiert. Und dem Benutzer ist letztlich egal ob es ein Parameter an den VDR oder ein eigenständiges Tool ist.

Ich denke sowas sollte doch auch machbar sein.

CU,
Lucian

Mein Ansatz war nur als kleiner Baustein, den man nacher auf verschiedenste Weisen nutzen kann, gedacht.

Zitat von mini73

Ich weiß, aber das Template, das dann da rumliegt, wird bei einer neuen Version des Plugins mit neuen/geänderten Parametern ja nicht automatisch aktualisiert.

Das Template muß auch nicht zwingend rumliegen, darüber hat keiner was gesagt, man kann es sogar bei der ersten Benutzung verschieben und editieren. Oder wenn man sieht, dass die Version dem Aktuellen Stand hinterher hinkt, einfach mal sicherheitshalber den entsprechenden Aufruf machen um nur diese eine Datei zu aktualisieren. Was übrigens auch beim Installieren automatisiert werden kann, wenn man es so möchte.

Zitat von mini73

Warum eine Information mehrfach ablegen? Wer auch immer so eine conf-Datei öffnet und bearbeiten möchte, weiß eigentlich vorher schon, was er will. Wenn er da jetzt eine Beschreibung sieht, die zu einem alten Versionsstand gehört, ist das nur verwirrend.

Wieso Informationen abgelegt? Wenn es als Template betrachtet wird (laut Verzeichnis, oder man könnte auch die Endung von .conf ändern wenn es jemanden verwirrt) weiss man dass diese Information doch nur als Hilfestellung gemeint ist unmittelbar, zeitnah dem Moment wann sie generiert wurde, abgelegt ist sie in der Form nur noch in den Binaries, dafür aktuell, denn die tatsächlichen editierten Konfigdateien sind schon eine andere Geschichte, die enthalten dann möglciherweise ganz wilde Anpassungen der Pfade usw. Und wenn jemand verwirrt eine ältere Version des Templates hier vorfindet, weiß er auch dass er sie aktualisieren kann (das kann man noch im oberen Bereich hineinschreiben), oder die Distribution sorgt wie oben angegeben dafür, dass sowas nicht vorkommt, oder liefert solche Templates überhaupt nicht mit.

Zitat von mini73

Wie wäre es denn, wenn "vdrctl edit" in der Datei nachsieht, die enthaltenen Plugins identifiziert, und unten an der Datei die Ausgabe von "vdr -Pplugin --help" mit dem Präfix "#HELP: " anhängt und nach dem Speichern diese Zeilen wieder entfernt?
Dann haben wir immer die aktuellen Hilfetexte beim Bearbeiten der Datei verfügbar.

Muß nun jeder so ein vdrctl nutzen, und einen gewissen Editor? Warum nicht die Aufgaben schön verteilt lassen, damit man sie flexibel einsetzten kann? Ich weiß ja nicht ob in der Distribution meiner Wahl dieses vdrctrl von dem Ihr sprecht überhaupt zum Einsatz kommen wird, wir haben da sehr gute Installationsmechanismen die die Verwaltung der aktiven/inaktiven Plugins, Aktualisierung von Konfigs machen, ähnlich wie auch in anderen Distributionen, wenn wir dann auf argsdir umstellen werden die wohl erweitert werden können um das zu bewältigen. Oder man nimmt so ein vdrctrl, time will tell.

Ciao,
Lucian

Hi Lars,

Zitat von mini73

Das würde ich schon mal gut finden, denn der vdr liest nur *.conf aus dem argsdir, wenn da *.template oder *.conf.template-Dateien liegen, stören die nicht und man braucht kein neues Verzeichnis.

daran hatte ich auch als Alternative gedacht, der Patch is dann noch um Einiges kleiner, ich hatte nur andererseits gedacht, zu den sowieso möglicherweise vielen *.conf Dateien kommen dann nochmal so viele hinzu. Aber wenn man dafür sorgt, dass diese ursprünglichen erst gar nicht mehr 'rumliegen bleiben, ist es auch ganz ok.

Zitat von mini73

So langsam verstehe ich, wo du eigentlich hin willst. Das wurde evtl. durch die anderen Beiträge etwas für mich verwirrt.

Dir geht es um die Neuanlage einer conf-Datei z.B. für ein Plugin. Damit du weißt, was du da überhaupt eintragen kannst, möchtest du es mit dem Hilfetext des Plugins vorausfüllen, und dann natürlich mit dem Pluginnamen in eckigen Klammern. In meinen Augen genau ein Job für vdrctl (da gibt's einen anderen Thread, wo es auch schon erste Implementierungen gibt, auf der ML hab ich einen RFC für die Aufrufsyntax gepostet). Denkbar wäre dann "vdrctl new softhddevice", dass dann aus dem aktuell installierten vdr die Hilfe holt, die Datei anlegt und mit Kommentaren versieht, die man dann nur noch anpassen muss.

Ja, genau, darum ging es mir, um einen bequemen Ausganspunkt, mit konsistenten, frischen Daten und den Erklärungen daneben zu haben. Das Tool vdrctrl könnte doch den Aufruf vdr --tmplargs [-P'plugname'] machen und so ohne umständliches Geparse an konsistente Daten aus erster Hand kommen wenn man es mit new aufruft, den Rest genau wie Du es beschreibst.

Zitat von mini73

Für Distributoren sehe ich es eigentlich nicht so, dass die vorgefertigten conf-Dateien die Hilfetexte aus dem vdr brauchen. Als Distributor weiß man, warum man welche Parameter in eine Datei schreibt (sind ja häufig Pfadangaben usw.). Und wenn man ein neues Plugin (oder eine neue Version) paketiert, setzt man sich ja meistens auch einmal mit den Optionen auseinander. Deshalb würde ich eine leere conf-Datei zu einem Plugin, wo der Hilfetext (zu irgend einem Versionsstand) auskommentiert drin steht, vermeiden wollen.

Distributoren brauchen sie vielleicht oder auch nicht, aber was ist denn verkehrt wenn nacher der geneigte User der diese Dateien eventuell noch von Hand anpassen will genau das look'n'feel der CLI-Hilfe darin findet? Und wenn die Datei nur auskommentierte Hilfe beinhaltet, so zeigt diese jedem der sie liest (meistens User, und davon gibts verschiedenste Arten) welche Möglichkeiten es gibt oder auch nicht, zu diesem Plugin, und das dies mit Sicherheit bei der angegebenen Version so war, ob es bei der aktuellen verändert wurde kann er selber überprüfen indem er den Inhalt mit einem frisch generiertem Template vergleicht.

Bei Gentoo z.B. gibt es derzeit noch für VDR ein recht komplexes Skriptsystem, welches für jedes Plugin welches Parameter entgegennimmt, ein Teilskript mitbringt, welches eine Konfigurationsdatei mit Umgebungsvariablen auswertet, umd zur finalen CLI-Schlange für VDR beizutragen. Diese Umgebungsvariablen sind für verschiedene Pluginparameter in diesen Dateien kommentiert und erklärt, haben defaultwerte im Skript-Teil, ist ein Haufen Arbeit beim Paketieren und ist im Vergleich zu den Möglichkeiten die argsdir und warum auch nicht vdrctrl eröffnen, viel zu kompliziert. In dieser Hinsicht erachte ich dass auskommentierte CLI-Hilfe in diesen cfg-Dateien, die auch noch gratis da landen und distributionsübergreifend sehr ähnlich gehandhabt werden könnte, doch für den User einen hohen Wiedererkennungswert bringt.

Zitat von mini73

Niemand muss irgendwas.
Der Editor, den vdrctl aufruft, ist einfach der aus der Umgebungsvariable EDITOR, so wie alle Programme das machen.
Ziel der Entwicklung ist natürlich, dass wir uns auf ein vdrctl einigen, das dann dem vdr beigelegt wird, ähnlich svdrpsend usw.

Das klingt doch vernünftig. Ich wollte doch nur an einer Stelle mithelfen, wo ich auch für mich einen schnellen Start im Umkrempeln meines VDR auf argsdir ermöglichen wollte. Es spricht doch nichts dagegen, so einen Patch, auch gerne in verbesserter Form, mit vdrctrl zu kombinieren. Ich halte generell nicht viel von Infos die erst geparst werden müssen, wenn sie doch direkt ausgegeben werden können, und von aussen, ob man vdrctrl newconf softhddevice oder direkt vdr --tmplargs -P'softhddevice' aufruft, ist fast das Gleiche, ok, vdrctrl kann noch drum herum mehr machen, zwecks Verwaltung, Editieren usw, das wäre tatsächlich vielleicht für alle Distributionen sinnvoll nutzbar.

VG,
Lucian