Verzeichnisnamen Konventionen

[PatrickBaer]

Servus zusammen,

ich möchte gerne eine Struktur für Software-Installationen festlegen. Leider scheitert es am Widerstand der "Das war schon immer so"-Kollegenschaft. Gibt es eine verbindliche Konvention für die Benennung von Dateistrukturen?

Zum Beispiel

bin => Programmdateien als Binary oder Shell-Script
log => Logfiles
inc => Include-Dateien
cfg => Configurationsdateien im Flat-Text-Format.

Merci vielmals!

[DeletedUserReAsG]

Es gibt den FHS. Verbindlich ist hingegen gar nichts.

[Meillo]

Viele orientieren sich bei ihren eigenen Projekten an dem was sie wo anders sehen, das koennen andere Projekte sein oder auch der FHS. Wichtig ist, dass man sich zurecht findet. Das ist gegeben, wenn es bei euch so ist wie in den Projekten die die Leute kennen. Aber selbst wenn es anders ist, die allerwichtigste Eigenschaft ist Konsistenz. In meinem Projekt mmh heissen zwei Ordner beispielsweise ``uip'' und ``sbr''. Das ist recht kryptisch und ich hab das noch nie irgendwo so gesehen, aber es ist immerhin im MH-Umfeld so ueblich. Nachdem man einmal in die Readme geschaut hat und lernt, dass das fuer ``user interface programs'' bzw. ``subroutines'' steht, findet man sich auch zurecht. Wenn das also bei euch schon immer so war, dann ist die Frage, was der grosse Vorteil ist, wenn man es aendert? Sind dann weniger Supportanfragen zu erwarten o.ae.? Es darf halt nicht nur Bikeshedding sein. Auch folgendes ist ein guter Ratgeber: https://www.netmeister.org/blog/two-questions.html

[PatrickBaer]

Naja, hier heisst "bin" zum Beispiel "scripts", was ich für etwas quer halte. Die Abteilung besteht aus drei Leuten, also kann man da schon mal eine kleine Umgewöhnung andenken, mein ich mal so.

[Meillo]

Naja, hier heisst "bin" zum Beispiel "scripts", was ich für etwas quer halte.

Man kann sich auch fragen, ob ``bin'' nicht das ist was quer ist, weil ``bin'' fuer ``binaries'' steht, aber bei euch vielleicht nur Scripte drin sind. Es trotzdem ``bin'' zu nennen ist nur eine Unix-Konvention, aber, je nach Inhalt und Art des Projekts und Arbeitsumgebung der Entwickler und Anwender, nicht unbedingt eine ueberzeugende.

Insofern wuerde ich mich eher auf die Seite deiner Kollegen stellen.

Ebenso im Bezug auf die zwei Fragen:
1) Macht es die Lage schlechter? Ein bisschen, weil Arbeit noetig ist, weil die Pfade je nach Version andere sind, etc.
2) Macht es die Lage besser? Nur optisch. ``bin'' ist auch nicht sprechender als ``scripts'', eher das Gegenteil.
Also sollte man alles so lassen wie es ist.

(btw: Ich denke durchaus, dass man Bezeichner aendern sollte, wenn sie missverstaendlich sind o.ae., aber das sehe ich hier nicht gegeben.)

[PatrickBaer]

Es ist ja nicht so, daß ich eine vorhandene göttliche Struktur durcheinander bringen will. Bis dato ist das eher eine kunterbunte Sammlung von "Standards", die alle fünf Wochen je nach aktueller Wetterlage oder Anforderung geändert wurden.

Kunde A hat seine Skripte/Programme in ~/scripts incl. Logfiles, dazugehörige SQL-Scripte, temp-files. Kunde B hat alles in /opt/software, aber nur für die Software von root. User-Software ist dann direkt in ~/

Cronjobs laufen einmal unter dem richtigen User, dann wieder über root mit su usw. Chaos pur also.

[Milbret]

Ich handhabe es aktuell auch etwas gemischt.
Benutzer Skripte + Anwendungn schiebe ich in den bin Ordner des Benutzers.
Wenn alle es nutzen dürfen, dann kommt es nach /usr/local/bin.

Logs würde ich in einen log Ordner packen.
Include Dateien habe ich keine, würde also nirgends wo bei mir landen.
Hir bräcute ich mehr Infomationen was für Include Dateien das sind um einen Vorschlag zu machen.
cfg Dateien kann man hier bei Benutzer Programmen in den entsprechenden Benutzer Ordner unter .config und dem eigenen Programm Unterordner packen.
Wäre also schon stark in die aktuellen gängigen Linux Praxis Richtung gehen.

Ich würde mich der entsprechenden Platform anpassen anstelle zu versuchen es passend für mich umzubiegen.
Gerade wenn man dann mit anderer Software, die eben nach gängiger Praxis arbeiten, mischen muss wird es ziemlich umständlich und wirr.
Hier hilft es sich dem jeweiligen Ökosystem der Platform unterordnen.

Dies ist aber nur eine persönliche Empehlung.
Wenn es für euch einfacher ist, euren Weg zu nehmen, dann tut es.
Nichts ist schlimmer als einen Status Quo weg zu gehen, der im Wiederspruch mit einem eigenen und sinnvolleren Ablauf liegt.

Martin