[gelöst] wohin mit Konfig./Pref. und Datenbank?

[miriki]

Moinsens!

Ich bastel hier gerade ein Progrämmchen in C++, das eine Verzeichnis-Struktur einliest (rekursiv also), bei passenden Dateien weitere Infos aus dem Dateinamen dekodiert und aus dem Ganzen dann eine Datenbank-Zeile erzeugt. Z.Z. erstelle ich mit " und ; eine .csv Zeile und pflaster das mit cout ins Terminal. Ich denke mittelfristig aber eher an SQlite oder MySQL. Konkret geht es um Verzeichnisse mit Video-Dateien, die einem strikten Schema bei der Benennung folgen.

Nun habe ich mehrere Basis-Verzeichnisse, ab denen ich scannen, das Ergebnis aber in einer DB zusammenführen möchte.. Und außerdem ist der "Typ" in diesem Fall vom Basis-Verzeichnis abhängig, also nicht in den Dateinamen kodiert. Also dachte ich mir: Ich baue eine kleine Konfigurations-Datei, in der ich eine Liste von Verzeichnissen und Typen einstelle. So in der Art einer .ini Datei, aber vielleicht auch anders:

Code: Alles auswählen

[dir1]
path = /media/video1/dir1/
type = type1

[dir2]
path = /media/video1/dir2/
type = type2

[dir3]
path = /media/video2/dir1/
type = type1

. . .

Aber: Wohin packe ich diese videodb.cfg jetzt am besten? Das aktuelle Programm ist jetzt erstmal nur zum Erstellen der DB gedacht. Es muss also nur die Pfade und Typen auslesen. Ein anderes Programm später soll zum Bearbeiten dieser Pfad-Liste dienen. Und weitere Tools sollen dann... ach, später.

Jetzt erstmal ist die Entwicklung in /home/miriki/projects/cpp/video/gendb/src/. In diesem festen Pfad kann ich natürlich eine .cfg einlesen und eine .db anlegen. Eigentlich soll der ganze Schronz später aber global verfügbar sein. Liege ich da mit /usr/local/bin/ falsch? Bislang habe ich da nur ein Script für cron reingelegt, ansonsten ist das Verzeichnis komplett leer. Und die cfg dann in ~/ wäre ja nicht so dolle. Wäre /usr/local/etc/ da sinnvoll? Das ist bislang auch völlig leer. Und dann die Datenbank wohin? Ob /usr/local/share/ dafür passend wäre? Da liegt schon 'n bisschen was, wo meine Video-DB eigentlich nicht so ganz dazu passen würde. Aber wo sonst?

Gruß, Michael

[brummer]

Also für config files checke ich immer ob XDG_CONFIG_HOME gesetzt ist.

Code: Alles auswählen

getenv("XDG_CONFIG_HOME"))

Wenn das so ist sichere ich die config files da. Wenn nicht, nutze ich $HOME/.config

Für die Datenbank würde ich auch ein Verzeichnis in $HOME wählen, XDG_DOCUMENTS_DIR würde sich eventuell anbieten. Oder soll nur root sie bearbeiten dürfen?

[miriki]

Hi, brummer!

config files {...] XDG_CONFIG_HOME [...] Wenn nicht [...] $HOME/.config

Hmmm... Woher kommen die XDG Variablen denn originär? Ich habe davon z.Z.:

Code: Alles auswählen

printenv | grep XDG
XDG_SESSION_TYPE=x11
XDG_CURRENT_DESKTOP=KDE
XDG_SESSION_CLASS=user
XDG_SESSION_ID=c57
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop

Was ich für die cfg suche: Ein "globales" Verzeichnis, in dem root eine cfg ablegen kann mit Grundeinstellungen. In $HOME kann dann noch eine cfg mit erweiterten / abweichenden Einstellungen liegen. Abstraktes Beispiel:

Code: Alles auswählen

global.cfg
{COLORS]
Foreground = Yellow
Background = Blue
[...]

private.cfg
[COLORS]
Background = DarkGray

[CURSOR]
Blink = Static
[...]

So kann das "default" von root vorgegeben werden, ein User sich aber eine andere Hintergrundfarbe aussuchen. In obigem Beispiel würde die Default-Vordergrundfarbe, aber die abweichende persönliche Hintergrundfarbe benutzt werden. Und solange ein User mit den Defaults zufrieden ist, bleibt die persönliche cfg eben leer bzw. wird gar nicht erst erzeugt.

Datenbank {...] $HOME [...] XDG_DOCUMENTS_DIR

Ich würde gerade die Datenbank eher ungern in $HOME ablegen. Die DB ist ein Abbild, Extrakt wieauchimmer von öffentlichen Verzeichnissen. Sie soll letztendlich nur der Navigation in den dortigen Files helfen. x verschiedene User, die sich jeweils eine DB anlegen, würden jedesmal die gleiche DB anlegen, wie alle anderen User auch, gleicher Inhalt, Aktualität vorausgesetzt. Z.Z. erstelle ich sie sogar in einem "Transfer"-Verzeichnis, auf das ich per Windows-Kiste zugreifen kann --> Test Import .csv in Excel.

Das klingt jetzt alles pfriemeliger, als es ist. Genau genommen könnte ich den Kram auch komplett in $HOME ablegen und Ruhe ist. Ausser miriki arbeitet hier gefälligst keiner auf meiner Kiste! Aber mich würde jetzt eben der "globale" Weg interessieren, wie man es denn normalerweise richtig macht. Das hängt damit zusammen, dass ich mich auch gerade mit 'make' beschäftigen will, eine CMakeLists.txt bearbeite und auch sowas wie 'make install' einrichten möchte.

Aber um auf die XDG zurück zu kommen: Wäre XDG_DATA_DIRS dann was?

Oder soll nur root sie bearbeiten dürfen?

Hmmm... Nein, eher nicht, zumindest noch nicht. Eigentlich soll und kann jeder User die DB jederzeit neu aufbauen. Ist jetzt auch kein grosses Ding. Die DB besteht aktuell gerade aus 2 .csv Files mit zusammen knapp 700kb. Ich schätze, im endgültigen Stadium, weitere Verzeichnisse und weitere Typen, werde ich bei kaum mehr als 5mb liegen. Das ist in Sekunden aufgebaut. Später vielleicht, eine Einschränkung root-rw und user-r, joah... Ich kann das gendb-Tool ja auch per sudo aufrufen.

Und wohin jetzt mit den Executables 'gendb', 'updatedb', 'dirsdb', ... $PATH benutzen? Also vielleicht doch /usr/local/bin/? Worin unterscheiden sich /usr/xxx und /usr/local/xxx eigentlich?

Vor Jahrenden, elend lange her, hatte ich mal eine Übersicht, war von SuSE glaube ich, welche Verzeichnisse im Linux üblicherweise für was benutzt werden. Gibt es sowas auch in aktuell?

Gruß, Michael

[brummer]

Hmmm... Woher kommen die XDG Variablen denn originär?

Die Spezifikationen kommen von freedesktop.org

Was ich für die cfg suche: Ein "globales" Verzeichnis, in dem root eine cfg ablegen kann mit Grundeinstellungen. In $HOME kann dann noch eine cfg mit erweiterten / abweichenden Einstellungen liegen.

Kann man so machen, wäre dann wohl /usr/(local)/share/appname/
Ich persönlich setze alle default werte im constructor oder im init() und überschreibe diese mit einer config aus dem $HOME, falls vorhanden.

Ich würde gerade die Datenbank eher ungern in $HOME ablegen.

Da wäre wohl auch wieder /usr/(local)/share/appname/ der geeignete Platz.

Später vielleicht, eine Einschränkung root-rw und user-r, joah... Ich kann das gendb-Tool ja auch per sudo aufrufen.

Aufrufe per sudo aus einem C/C++ Programm sind nicht trivial. Hier werden sehr schnell Einfall Tore für exploits geschaffen. Ich würde immer versuchen das zu vermeiden.

Und wohin jetzt mit den Executables 'gendb', 'updatedb', 'dirsdb',

Ja, /usr/(local)/bin ist der richtige Ort.

Worin unterscheiden sich /usr/xxx und /usr/local/xxx eigentlich?

/usr/xxx ist gedacht für distributions-spezifische Daten, /usr/local/xxx ist für lokale daten, also alles was du installierst und nicht von deiner Distribution (Paket Manager) kommt.

[miriki]

Hi, brummer!

Vielen Dank für die ausführliche und detaillierte Antwort.

Die Spezifikationen kommen von freedesktop.org

Ah, ok, hab dort mal quer gelesen mit den Env.-Var. Interessant...

Was ich für die cfg suche: Ein "globales" Verzeichnis, in dem root eine cfg ablegen kann mit Grundeinstellungen.

Kann man so machen, wäre dann wohl /usr/(local)/share/appname/

Ok, dachte ich mir so in der Art auch, wobei ich auch gleich mit dem "local"-Zweig geliebäugelt hatte. Was hältst Du von /usr/local/etc? Das ist nämlich (bei mir) auch kpl. leer und ich kann deswegen nicht so recht ableiten, was man da ggf. reinpacken könnte.

Ich würde gerade die Datenbank eher ungern in $HOME ablegen.

Da wäre wohl auch wieder /usr/(local)/share/appname/ der geeignete Platz.

check

Später vielleicht, eine Einschränkung root-rw und user-r, joah... Ich kann das gendb-Tool ja auch per sudo aufrufen.

Aufrufe per sudo aus einem C/C++ Programm sind nicht trivial. Hier werden sehr schnell Einfall Tore für exploits geschaffen. Ich würde immer versuchen das zu vermeiden.

Ne, schon Aufruf der Tools von der CLI. Z.B. Aufbau der DB mittels gendb, ggf. nur von root. Update der DB mit updatedb aber auch von user, nachdem z.B. neue Files in die Struktur abgelegt wurden. Die Verzeichnisse verwalten, die gescannt werden, mittels dirsdb dann wieder nur von root. Ist jetzt nur so aus'm Stegreif, sicher noch nicht endgültig, aber so in der Art...

Und wohin jetzt mit den Executables 'gendb', 'updatedb', 'dirsdb',

Ja, /usr/(local)/bin ist der richtige Ort.

check

/usr/xxx ist gedacht für distributions-spezifische Daten, /usr/local/xxx ist für lokale daten [...] nicht von deiner Distribution (Paket Manager) kommt.

von Distri, so einfach, klar. Danke! Dann bewege ich mich ja eh besser im local.

Gruß, Michael