Verständnisfrage zu /etc/vdr/conf.d

Habe gerade ein Update hochgeschickt

Zitat von Copperhead

Ich lese jetzt zum ersten mal in deinem Code. Ich muss zugeben das das stellenweise nicht unbedingt leicht zu lesen ist. Liegt vielleicht auch an der Uhrzeit.

Mag sein, aber perl ist auch nicht ohne Grund als write-only-Sprache bekannt

Zitat von Copperhead

-chomp machtnicht das, was du in deinem Kommentar angibst.

Das wird auf jeden Fall an der Uhrzeit gelegen haben - oder an einem copy&paste zu viel. Ist korrigiert. Natürlich wird mit chomp der Zeilenumbruch entfernt

Zitat von Copperhead

- Filehandles bzw. in deinem Fall Dirhandles öffnet man nicht mehr über Barewords. Das ist deprecated. Spätestens mit Perl6 wirst du da massiv Probleme bekommen. http://perlmaven.com/open-files-in-the-old-way

Gut, wusste ich nicht. Ich hatte es ursprünglich so gelernt, womöglich aus entsprechend alten Skripten, und bisher hat es immer funktioniert. Mit perl6 habe ich mich auch noch gar nicht befasst.

Zitat von Copperhead

- Du prüfst über eine Regular Expression nach einem 'trailing slash'. Dann lieber einmal ein Slash zu viel, als Performance über eine unnötige Regular Expression zu verlieren.

Für argsdir könnte das klappen, mit einem doppelten Slash mache ich mir aber meine Prüfung kaputt ob der jetzige Link in die richtige Richtung schießt - das müsste man dann an anderer Stelle anpassen. Habe mal einen passenden Kommentar eingefügt. Vielleicht ergibt sich noch eine bessere Lösung

Zitat von Copperhead

- Deine Editor Sucherei finde ich ein bisschen Overkill. Ja, ich habe nano als Default gesetzt. Wählt man jetzt als Default 'vi' sollte man auf der sicheren Seite sein. So ist das bei Git z.B. auch.

Die Umgebungsvariable an erster Stelle ist klar, an zweiter stelle, das /usr/bin/editor, zeigt bei mir auf /etc/alternatives/editor, was per update-alternatives entsprechend angepasst werden kann. Die Suche danach habe ich jetzt kurzerhand durch ein `which vi` ersetzt ansonsten gibt es eben eine (neue) Fehlermeldung

Zitat von Copperhead

- Du hast immer mal wieder mit einbuchstabige Skalarnamen. Ich glaube es ist eine Referenz auf ein Hash.

Ja, Referenz auf ein Element aus %files, was wiederum ein anonymes Hash ist. Dient nur dazu den Quellcode zu verkürzen um nicht jedesmal $files{$name} scheiben zu müssen

Zitat von Copperhead

- Achja und eine Sache noch. Du hast eine Subroutine auf einen Skalar gelegt. Das sehe ich bei dir zum ersten mal. Ich wusste gar nicht, dass das geht. Wenn ich das richtig verstehe versteckst du damit das sub innerhalb von 'getFiles'.

Kann man machen, nennt sich anonymous subroutine. Ich hatte es gemacht weil ich getFiles vorher aus den einzelnen Unterfunktionen list, enable etc. aufgerufen habe und diese Routine gerne in der Funktion getFiles definiert haben wollte. Da ich aber dazu übergegangen bin getFiles direkt vorab aufzurufen habe ich die Schachtelung kurzerhand entfernt. Aus der anonymen Funktion konnte so eine "richtige" werden.

Clemens

Zitat von acb321

Mag sein, aber perl ist auch nicht ohne Grund als write-only-Sprache bekannt

Danke, Danke! Siehste Copperhead, das meine ich.

Gerald

Zitat von gda

Danke, Danke! Siehste Copperhead, das meine ich.

Ohh, du hast keine Ahnung.
Jede Programmiersprache kann man so schreiben, dass sie kein anderer mehr lesen kann. Die Kunst ist es, genau das nicht zu tun.

Zitat von Copperhead

Ohh, du hast keine Ahnung.
Jede Programmiersprache kann man so schreiben, dass sie kein anderer mehr lesen kann. Die Kunst ist es, genau das nicht zu tun.

Ich habe deutlich mehr Ahnung als du denkst ;). Aber Perl ist die einzige Sprache bei der die Entwickler auch noch stolz darauf sind.

Gerald

Zitat von gda

Aber Perl ist die einzige Sprache bei der die Entwickler auch noch stolz darauf sind.

Was hat das mit Stolz zu tun, wenn ich sage, dass andere Sprachen auch nicht besser sind.

Einigen wir uns darauf, dass alle Sprachen ganz toll und kacke sind?
Back to topic...

Lars

Ist der Hilfetext für den Befehl "list" Absicht oder ein C&P Fehler? https://github.com/CReimer/vdrctl/blob/master/vdrctl#L188 ff.

Commands
    list
         read files from <directory> instead of AVAILDIR


         --enabled
              print a sorted list of all configuration files from ARGSDIR


         --disabled
              print a sorted list of all configuration files from AVAILDIR
              which are not symlinked to ARGSDIR

So wie ich https://github.com/CReimer/vdrctl/blob/master/vdrctl#L61 verstehe, sollte ein "vdrctl list" alle Konfigurationsdateien auflisten und jeweils farblich markiert angeben, ob sie aktiv sind oder nicht.

Ich verlinke diesen Post mal hierher, weil er diesen Thread genauso betrifft: [PATCH] vdr-2.1.10: CLI Help ---> argsdir Templates (/etc/vdr/conf.d/*.conf.tmpl)

Zitat von Copperhead

Was hat das mit Stolz zu tun, wenn ich sage, dass andere Sprachen auch nicht besser sind.

Das hast du da jetzt willkürlich reininterpretiert. Meine Antwort bezog sich auf den ersten Satz den ich gequoted habe, ich hätte den Folgesatz entfernen müssen.
Aufgrund meiner Erfahrung habe ich es eben mehr als einmal erlebt, dass sich Perl-Programmierer sehr wohl bewusst sind, dass sie kryptisch programmieren können und
es auch noch gut finden.

Gerald

Zitat von seahawk1986

So wie ich https://github.com/CReimer/vdrctl/blob/master/vdrctl#L61 verstehe, sollte ein "vdrctl list" alle Konfigurationsdateien auflisten und jeweils farblich markiert angeben, ob sie aktiv sind oder nicht.

Das tut es, wenn du weder --enabled noch --disabled angibst.

ich weiß nicht. mini73 hat das in seinem RFC so drin gehabt. Ich habe dann da reininterpretiert, dass er das für Skripte oder ähnliches haben möchte.
Wenn du --enabled oder --disabled angibst kommt einfach nur eine unformatierte Liste zurück.

Zitat von Copperhead

Das tut es, wenn du weder --enabled noch --disabled angibst.

Ja, aber was hilft mir dann die Erklärung "read files from <directory> instead of AVAILDIR" für "list"? Da übergebe ich doch noch nicht mal ein extra Verzeichnis.

BTW: perl-switch ist keine Äbhängigkeit der base-Gruppe unter Arch Linux.

Zitat von seahawk1986

Ja, aber was hilft mir dann die Erklärung "read files from <directory> instead of AVAILDIR" für "list"? Da übergebe ich doch noch nicht mal ein extra Verzeichnis.

Ach das meinst du. Ja das scheint ein Copy/Paste Fehler zu sein.

Zitat von seahawk1986

BTW: perl-switch ist keine Äbhängigkeit der base-Gruppe unter Arch Linux.

Gut, dann werde ich das wohl rausnehmen. Ich will soweit es geht nur Core-Module verwenden.

Was "switch" angeht: http://perldoc.perl.org/perlsyn.html#Switch-Statements
Sorgt aber für eine Versions-Einschränkung (mindestens Perl 5.10.1).

Ich hab mich mal an einer bash-completion für vdrctl gemacht: https://github.com/CReimer/vdrctl/pull/1/files. Dabei ist mir aufgeallen, dass es noch schön wäre so etwas wie vdrctl list --all zu haben. Der Befehl wäre analog zu --enabled/disabled würde aber alle Plugins unformatiert anzeigen.

Zitat von olebowle

Dabei ist mir aufgefallen, dass es noch schön wäre so etwas wie vdrctl list --all zu haben.

Das kann ich einbauen. Das ist ja nur eine Kleinigkeit. Deinen Pull-Request pulle ich dann erst, wenn du das an --list angepasst hast und ich das nachfolgende geklärt habe.

Allerdings nochmal zur Edit Funktion. Ich habe jetzt zwei Dinge fertig implementiert.

Ich nenne es mal Simple und Extended

Simple: Ruft einfach nur einen Editor auf und gut ist. Hilfetexte sind fest in den Configdateien vom Distributor eingetragen.
Extended: Liest die Config, schreibt die in eine temporäre Datei, liest die Hilfe vom VDR, schreibt diese dazu. Öffnet einen Editor auf die temporäre Datei. Schreibt danach die Config zurück ohne die Hilfetexte vom VDR.

Jetzt gibt es da ein Problem: Ich habe mich mich mit M-Reimer beraten und VDR4Arch präferiert die "Simple-Methode". Alleine schon, weil wir das jetzt schon länger so betreiben und damit eigentlich bisher ganz gut fahren.

mini73 hat sich, scheinbar stellvertretend für yaVDR, für die Extended Methode ausgesprochen.

Ich finde beides interessant und beide Ansichten nachvollziehbar. Ich persönlich kann mich auch nicht wirklich entscheiden. Daher überlege ich oben im Perl-File ein Flag einzubauen, das die Extended Edit Funktion aktiviert. yaVDR setzt dann dieses Flag um und aktiviert damit permanent das gewünschte Verhalten.
Gibt es da irgendwelche Einwände?

Von meiner Seite gibt es keine Einwände.

Lars

Zu "list --all":
Ein list ohne Parameter sollte eigentlich alle verfügbaren conf-Dateien anzeigen. Ist das in der spec unklar?

Prima, dass sich jemand um die bash-completion kümmert.

Lars

list ohne -- Parameter bringt eine formatierte Liste. Ähnlich dem was systemd bei dem list-unit-files Parameter liefert.

Ok, was ist denn der Unterschied zwischen formatiert und unformatiert?

Lars

Also ich würde auch eher die Extended Methode vorziehen. Das erleichtet eigentlich nicht nur deine Arbeit, weil du die configs nicht anpassen musst, sondern auch die der User, weil sie keine .pacnews einpflegen müssen. Wo seht ihr die Vorteile von simple? Meines Erachtens nach gibt es keine vielleicht abgesehen davon, dass man mitbekommt wenn es neue Optionen eines Plugins gibt. Aber auch nur dann, wenn man die config verändert hat.

Mit extended müssen die config Dateien natürlich ins backup Array, so dass sie bei einem Update nicht überschrieben werden. Solange die Dateien nur den [Pluginnamen] enthalten und evtl. Pfadveränderungen, müssen die User auch nix mergen, da sie sich ja äußerst selten ändern.

Apropos config aktuell halten: Ich hab gerade mal die wenigen Plugins (vdr-femon, vdr-skindesigner, vdr-softhddevice, vdr-streamdev), die ich installiert habe durchgeschaut. Und es stellt sich raus, dass selbst bei mir schon 2 Plugins nicht den letzten Stand haben: vdr-skindesigner und vdr-softhhdevice. Wollt ihr das auf Dauer wirklich antun?

Ich trag eure Entscheidung dann natürlich mit, wie auch immer geartet sie sein möge.

PS: vdrctl edit vdr geht nicht, weil er ja nur in conf.avail sucht.

EDIT: Ok ist doch nur ein Plugin, bei vdr-softhhdevice ist es nur nicht in der richtigen Reihenfolge.