Wo speichert man am besten ein Shell-Script und seine Begleitdateien?

[HansD]

Ich habe ein Bash-Script geschrieben, das ich auch anderen zur Verfügung gestellt habe. Während der Entwicklung und der Tests habe ich bisher alle seine Dateien auf meinem Rechner in einem Verzeichnis gehalten. (Ich habe dafür erstmals auch git benutzt, aber bisher nur rudimentär. Bei der Versionsverwaltung hat mir das noch kein bißchen geholfen, nur bei der Bereitstellung.) Inzwischen habe ich das Hauptprogramm und seine statische Datenbasis auch nach ~/bin kopiert.

Was ist der beste Speicherort -- oder wenigstens ein korrekter und sinnvoller für die verschiedenen Dateien?

Insgesamt gibt es etwa folgende Dateien

Zwei Bash-Scripte

• <progname> (das eigentliche Programm)
• <scriptname>.sh (generiert bei der Installation die Datenbasis)

Eine statische Datenbankdatei (flat file)

• <filename>.txt

Informative Begleitdateien

• LICENSE
• README.md
• README.txt
• USAGE.txt

(Eine Konfigurationsdatei braucht das kleine Programm bisher nicht, also brauche ich derzeit dafür nichts in /etc abzulegen.)

Ich sollte das Programm/Script vermutlich in /usr/bin oder in /usr/local/bin speichern.

Alle anderen Dateien sollten dann vermutlich in einen eigenen Unterordner von /usr/share oder /usr/local/share.

Habe ich die File System Standards einigermaßen richtig verstanden?
Was ist Eurer Erfahrung nach die best practise, das effektivste und funktionssicherste Vorgehen?

[Meillo]

Du hast das richtig verstanden. Verwende /usr/local fuer dein eigenes Zeug, das du (systemweit) an der Paketverwaltung vorbei installierst.

Siehe Filesystem Hierarchiy Standard (FHS) und die Manpage hier(7).


Wenn du nur etwas fuer deinen User installierst, tue das in seinem Home-Directory (in ~/bin und Co.), dann brauchst du keine Root-Rechte.

[HansD]

Verwende /usr/local fuer dein eigenes Zeug, das du (systemweit) an der Paketverwaltung vorbei installierst.

Ok, alles klar. THX

[hikaru]

kosmetische Anmerkung:
Soweit ich weiß, wäre es sauberer, das Installationsscript und die Datendatei ohne Dateiendung abzulegen.

[Meillo]

kosmetische Anmerkung:
Soweit ich weiß, wäre es sauberer, das Installationsscript und die Datendatei ohne Dateiendung abzulegen.

Ja. Aber nicht nur kosmetisch, denn nur so kann man spaeter die Implementierung z.B. von Bash auf Python umstellen, ohne die Kompatibiliaet unnoetigerweise brechen zu muessen.

Bei der Datendatei sehe ich das etwas anders. Wenn es z.B. eine XML-Datei ist, sollte die auch *.xml heissen. In dem Fall ist es ein Plaintext-Datei, da wuerde man traditionell unter Unix gar keine Dateiendung hinschreiben, weil plain text der Normalfall ist. Da heutzutage der Einfluss anderer Betriebssysteme derart umfassend ist, koennte man auch Plaintext-Dateien mit einer txt-Dateiendung versehen. In diesem Fall finde ich das nebensaechlich. Die Datei soll vom User ja eh nicht direkt genutzt werden. Sie ist also hinter der Abstraktionschicht des Programmes versteckt. Damit kann sie auch jederzeit geaendert werden, ohne dass es Kompatibilitaetsauswirkungen haette. Beim Programmname, der ein oeffentliches Interface darstellt, ist das anders.

[hikaru]

Bei der Datendatei sehe ich das etwas anders. Wenn es z.B. eine XML-Datei ist, sollte die auch *.xml heissen. In dem Fall ist es ein Plaintext-Datei, da wuerde man traditionell unter Unix gar keine Dateiendung hinschreiben, weil plain text der Normalfall ist.

".txt" impliziert für mich eigentlich formatfrei, was bei einer "Datenbankdatei" sicher nicht der Fall ist.
Daher stimme ich zwar deiner Ansicht zu, dass so eine Datei durchaus eine Endung haben kann, aber ich halte dann ".txt" für schlechter als ganz ohne Endung. Das verbreitetste Flat-File-Datenbankformat ist vermutlich Sqlite, und dann fände ich z.B. ".sqlite" eine sinnvolle Endung. Ähnliches gilt für ".xml", ".ini" usw. Aber falls es eine Endung gibt, dann sollte die mMn tatsächlich etwas über das Datenformat aussagen.

[Meillo]

Bei der Datendatei sehe ich das etwas anders. Wenn es z.B. eine XML-Datei ist, sollte die auch *.xml heissen. In dem Fall ist es ein Plaintext-Datei, da wuerde man traditionell unter Unix gar keine Dateiendung hinschreiben, weil plain text der Normalfall ist.

".txt" impliziert für mich eigentlich formatfrei, was bei einer "Datenbankdatei" sicher nicht der Fall ist.
Daher stimme ich zwar deiner Ansicht zu, dass so eine Datei durchaus eine Endung haben kann, aber ich halte dann ".txt" für schlechter als ganz ohne Endung. Das verbreitetste Flat-File-Datenbankformat ist vermutlich Sqlite, und dann fände ich z.B. ".sqlite" eine sinnvolle Endung. Ähnliches gilt für ".xml", ".ini" usw. Aber falls es eine Endung gibt, dann sollte die mMn tatsächlich etwas über das Datenformat aussagen.

Dieser Aussage von dir stimme ich zu. Vermutlich haben wir hier ein Verstaendnisproblem. Ich bin davon ausgegangen, dass es eine beliebige Plaintext-Datei ist (darum *.txt), die irgendein eigenes ``Datenbank''-Format hat, also eigentlich eine beliebige anwendungsspezifische Datenablage in Plaintext. Auf dieser Annahme basiert meine Aussage. Falls es sich aber so verhaelt wie du es beschreibst, dass naemlich sowas wie Sqlite drin steckt, dann sollte eine andere Dateiendung verwendet werden. (Und besser keine als eine unpassende.)

Btw: Was bedeutet schon ``formatfrei''? Eigentlich doch nur, dass es kein bekanntes Format ist. Da sind die Grenzen aber fliessend. Was einer als formatfreien Text ansieht, kann ein anderer vielleicht (zufaellig) als Markdown interpraetieren. Ich will es mal so formulieren: Fuer Dateien mit der Endung *.txt ist ein Texteditor das bevorzugte/geeignete Verarbeitungsprogramm. Und andersrum: Wenn der Texteditor das bevorzugte/geeignete Verarbeitungsprogramm ist, dann kann man die Datei *.txt nennen. (Traditionell unter Unix ist das natuerlich gar nicht noetig (weswegen meine Textdateien selten Endungen haben), aber in Anbetracht der Dominanz anderer Betriebssysteme in den Koepfen der Anwender und der Softwareentwickler ist eine Dateiendung der kompatiblere Weg ... genauso wie die \r\n-Zeilenumbrueche der Internetprotokolle.)

[hikaru]

Mit "formatfrei" meine ich hier wirklich formatfrei, also wirklich ohne definiertes Format, nicht nur "unbekanntes Format". Ein Beispiel wäre Prosatext.

Zumindest aus HansDs Perspektive hat die Datei ein Format, sonst könnte er sie nicht automatisiert verarbeiten. Entweder hat er ein ihm bekanntes etabliertes Format übernommen, oder er hat sich selbst eines ausgedacht. So eine wie auch immer formatierte Datei sollte mMn entweder eine zum Format passende Endung oder gar keine haben.
Bei selbst ausgedachten Formaten darf man sich dann selbst eine Formatbezeichnung ausdenken, muss dabei aber auf Kollisionen mit anderen Formatbezeichnungen achten, was zumindest bei n.3-Formaten schnell problematisch wird.
Oft beruhen selbst ausgedachte Formate aber auf mangelnder Recherche über etablierte Formate. Die meisten dieser Formate ließen sich genauso gut als ".ini", ".csv" oder ".xml" ablegen, und dann sollte man auch das etablierte Äquivalent nutzen.

[Meillo]

Mit "formatfrei" meine ich hier wirklich formatfrei, also wirklich ohne definiertes Format, nicht nur "unbekanntes Format". Ein Beispiel wäre Prosatext.

Das Problem ist, dass die Grenze, was ein Format ist und was keines ist, fliessend ist und auf den Blickwinkel ankommt. Prosa hat auch ein Format. Es hat Absaetze, Kapitel, etc. Was ein Format ist, haengt letztlich genau daran, dass es *bekannt* ist, wenn auch nur einer einzigen Person. Ich habe mich immer wieder mit dem Thema der Formaterkennung beschaeftigt. Inzwischen ist mein Ergebnis, dass es bei der Formatfrage keine Exaktheit gibt. Man kann nur sagen, ob eine konkrete Datei einer Formatdefinition (in einer bestimmten Version) entspricht oder nicht. Es gibt aber keine offizielle, vollstaendige Liste aller Dateiformate, ebenso kann eine Datei mehreren Formaten entsprechen. Letztlich kann man fast gar nichts aussagen, ausser, dass alles fliessend ist. Darum tue ich mir mit deiner Aussage schwer.

Zumindest aus HansDs Perspektive hat die Datei ein Format, sonst könnte er sie nicht automatisiert verarbeiten. Entweder hat er ein ihm bekanntes etabliertes Format übernommen, oder er hat sich selbst eines ausgedacht. So eine wie auch immer formatierte Datei sollte mMn entweder eine zum Format passende Endung oder gar keine haben.
Bei selbst ausgedachten Formaten darf man sich dann selbst eine Formatbezeichnung ausdenken, muss dabei aber auf Kollisionen mit anderen Formatbezeichnungen achten, was zumindest bei n.3-Formaten schnell problematisch wird.

Sagen wir, er kodiert seine Informationen als RFC822-Header. Was hilft dann mehr:
1) Er nennt seine Datei *.xyz (willkuerlich)
2) Er nennt seine Datei *.rfc822header (vermutlich das treffendste)
3) Er nennt seine Datei *.txt (der Obertyp)
4) Er vergibt gar keine Dateiendung (nichts falsch gemacht)

Variante (1) finde ich schaedlich. Variante (2) hat das Problem, dass sie sperrig ist und moeglicherweise insofern problematisch, dass er nicht alle Anforderungen und Moeglichkeiten von RFC822-Headern umgesetzt hat. Variante (3) ist wenigstens robust, setzt aber auf den Menschen zur genaueren Identifizierung. Variante (4) setzt noch mehr auf den Menschen weil dieser sogar zuerst den Obertyp des Formats identifizieren muss.

Aus diesen Gruenden gefaellt mir (3) hier noch am besten, weil ich denke, dass es am konstruktivsten ist.

Oft beruhen selbst ausgedachte Formate aber auf mangelnder Recherche über etablierte Formate. Die meisten dieser Formate ließen sich genauso gut als ".ini", ".csv" oder ".xml" ablegen, und dann sollte man auch das etablierte Äquivalent nutzen.

Da bin ich dann wieder ganz deiner Meinung.


(Schoen, dass wir hier so tief ueber die Dinge diskutieren koennen und tun. Darum mag ich dieses Forum. )

[hikaru]

Das Problem ist, dass die Grenze, was ein Format ist und was keines ist, fliessend ist und auf den Blickwinkel ankommt.

Im Allgemeinen stimme ich dir zu, aber im hier vorliegenden Fall ist die Sache deutlich einfacher:
HansD hat ein Programm geschrieben. Dieses verarbeitet eine formatierte Datei. HansD als Autor der Software kennt das Format.

Um das vielleicht klarzustellen: Mir geht es nicht um den Grundsatz (ich denke, da stimmen wir überein), sondern um den konkreten Fall "HansDs Plain-Text-DB".

Sagen wir, er kodiert seine Informationen als RFC822-Header. Was hilft dann mehr:
1) Er nennt seine Datei *.xyz (willkuerlich)
2) Er nennt seine Datei *.rfc822header (vermutlich das treffendste)
3) Er nennt seine Datei *.txt (der Obertyp)
4) Er vergibt gar keine Dateiendung (nichts falsch gemacht)

Ich wäre im Zweifelsfall für:
5) Er lehnt die Bezeichnung nicht an die Syntax, sondern an den Zweck des Inhalts an und nennt sie "*.hansdb".

Das könnte man nun als Unterart von 1) ansehen und es schädlich finden, aber ich finde es nicht schädlich, weil es in meinen Augen eben nicht willkürlich ist. Es ist gehaltvoller als 1), griffiger als 2), präziser als 3) und zumindest in der Abwägung zwischen Aussagekraft und Exotik nicht schlechter als 4).
Eine gehaltvolle, griffige und präzise Standarderweiterung würde ich trotzdem vorziehen, je nach Aufwand auch zu dem Preis, nochmal die Struktur des Dateiinhalts überarbeiten zu müssen.

Die Identifizierbarkeit durch Menschen halte ich hier für nachrangig (nicht unwichtig). Der Fokus der Datei liegt in der automatischen Verarbeitung durch ein Programm. Ottonormalnutzer haben gar keine NOTWENDIGKEIT die Datei mit einem Editor zu öffnen. Falls sie ein INTERESSE daran haben, dann verlassen sie ihre Rolle als Ottonormalnutzer und ich finde es zumutbar, dass sie dann zur Identifizierung file bemühen müssen (oder realistischer: trial and error).

(Schoen, dass wir hier so tief ueber die Dinge diskutieren koennen und tun. Darum mag ich dieses Forum. )

Ich staune noch, dass man mit einer ernsthaften Formatdiskussion überhaupt einen Thread kapern kann.

[Meillo]

Das Problem ist, dass die Grenze, was ein Format ist und was keines ist, fliessend ist und auf den Blickwinkel ankommt.

Im Allgemeinen stimme ich dir zu, aber im hier vorliegenden Fall ist die Sache deutlich einfacher:
HansD hat ein Programm geschrieben. Dieses verarbeitet eine formatierte Datei. HansD als Autor der Software kennt das Format.

Um das vielleicht klarzustellen: Mir geht es nicht um den Grundsatz (ich denke, da stimmen wir überein), sondern um den konkreten Fall "HansDs Plain-Text-DB".

Sagen wir, er kodiert seine Informationen als RFC822-Header. Was hilft dann mehr:
1) Er nennt seine Datei *.xyz (willkuerlich)
2) Er nennt seine Datei *.rfc822header (vermutlich das treffendste)
3) Er nennt seine Datei *.txt (der Obertyp)
4) Er vergibt gar keine Dateiendung (nichts falsch gemacht)

Ich wäre im Zweifelsfall für:
5) Er lehnt die Bezeichnung nicht an die Syntax, sondern an den Zweck des Inhalts an und nennt sie "*.hansdb".

Das könnte man nun als Unterart von 1) ansehen und es schädlich finden, aber ich finde es nicht schädlich, weil es in meinen Augen eben nicht willkürlich ist. Es ist gehaltvoller als 1), griffiger als 2), präziser als 3) und zumindest in der Abwägung zwischen Aussagekraft und Exotik nicht schlechter als 4).

Ich kann deine Argumentation nachvollziehen. Wir unterscheiden uns nur in geringfuegig unterschiedlicher Bewertung von Aspekten ... die man aber gar nicht pauschal festlegen kann, sondern sie viel mehr davon abhaengen, was wir in dem konkreten Fall vor Augen haben (Produkte unserer Vorstellung, basierend auf sehr wenigen Informationen).

Eine gehaltvolle, griffige und präzise Standarderweiterung würde ich trotzdem vorziehen, je nach Aufwand auch zu dem Preis, nochmal die Struktur des Dateiinhalts überarbeiten zu müssen.

Das waere der vermutlich beste Weg.

Die Identifizierbarkeit durch Menschen halte ich hier für nachrangig (nicht unwichtig). Der Fokus der Datei liegt in der automatischen Verarbeitung durch ein Programm. Ottonormalnutzer haben gar keine NOTWENDIGKEIT die Datei mit einem Editor zu öffnen. Falls sie ein INTERESSE daran haben, dann verlassen sie ihre Rolle als Ottonormalnutzer und ich finde es zumutbar, dass sie dann zur Identifizierung file bemühen müssen (oder realistischer: trial and error).

Mir geht hier durch den Kopf, dass es unter Unix (traditionell) nur eine Art von Usern gibt, naemlich solche, die ihr System verstehen sollen. Dort gibt es diese Unterschiedung nicht. Das ist fuer mich die Windows-Denkweise: Endanwender benutzen Programme; alles andere ist nicht fuer sie bestimmt und kann oder soll versteckt werden. Unix hat eine Durchlaessigkeit im System. Man kann da schon auch nur die Programme benutzen, aber man (d.h. jeder) kann sich jederzeit beliebig viele Stufen tief in das System vorarbeiten, ohne dass er staendig in anwendungsspezifische Spezialwelten abtauchen muesste oder dass er nicht soll. Die Idee ist derart: Nimm die Standard-Tools deines Betriebssystems und dessen Dokumentation (Manpages) und du kannst damit das komplette System durchforsten, analysieren, veraendern und verstehen. Das ist mir bei deinen Worte unwillkuerlich gekommen. (Natuerlich ist ein heutiges GNU/Linux auch nicht mehr wie Unix damals, aber trotzdem oder gerade deshalb sollte davon viel mehr geredet werden.)

(Schoen, dass wir hier so tief ueber die Dinge diskutieren koennen und tun. Darum mag ich dieses Forum. )

Ich staune noch, dass man mit einer ernsthaften Formatdiskussion überhaupt einen Thread kapern kann.

Es wehrt sich ja auch keiner. Diese Art von Kaperei finde ich fast immer in Ordnung ... das liegt allerdings vielleicht daran, dass ich in diesen Faellen oft genug selber ein Anfuehrer der Kaperer bin.

[hikaru]

Die Identifizierbarkeit durch Menschen halte ich hier für nachrangig (nicht unwichtig). Der Fokus der Datei liegt in der automatischen Verarbeitung durch ein Programm. Ottonormalnutzer haben gar keine NOTWENDIGKEIT die Datei mit einem Editor zu öffnen. Falls sie ein INTERESSE daran haben, dann verlassen sie ihre Rolle als Ottonormalnutzer und ich finde es zumutbar, dass sie dann zur Identifizierung file bemühen müssen (oder realistischer: trial and error).

Mir geht hier durch den Kopf, dass es unter Unix (traditionell) nur eine Art von Usern gibt, naemlich solche, die ihr System verstehen sollen. Dort gibt es diese Unterschiedung nicht. Das ist fuer mich die Windows-Denkweise: Endanwender benutzen Programme, alles andere ist nicht fuer sie bestimmt und kann oder soll versteckt werden. Unix hat eine Durchlaessigkeit im System. Man kann da schon auch nur die Programme benutzen, aber man (d.h. jeder) kann sich jederzeit beliebig viele Stufen tief in das System vorarbeiten, ohne dass er staendig in anwendungsspezifische Spezialwelten abtauchen muesste oder dass er nicht soll. Die Idee ist derart: Nimm die Standard-Tools deines Bestriebssystems und dessen Dokumentation (Manpages) und du kannst damit das komplette System durchforsten, analysieren, veraendern und verstehen. Das ist mir bei deinen Worte unwillkuerlich gekommen. (Natuerlich ist ein heutiges GNU/Linux auch nicht mehr wie Unix damals, aber trotzdem oder gerade deshalb sollte davon viel mehr geredet werden.)

Ich weiß gerade nicht, ob wir hier aneinander vorbei reden, denn ich sehe das ganz genauso wie du und gerade deshalb (nicht trotzdem) halte ich hier die "Identifizierbarkeit durch Menschen" für nachrangig.

So wie du die Identifizierung durch Menschen in's Spiel gebracht hast, verstehe ich darunter den ursprünglichen DOS/Windows-Ansatz: Ich schaue als Mensch auf die Endung einer Datei und weiß, was da drin steht.
Nun ist diese Herangehensweise ja aber nicht die von Unix. Der klassische, fachkompetente User sollte das wissen und stattdessen die entsprechenden Tools zur Identifizierung nutzen. Dateiendungen sind also aus Sicht von Unix (und seiner kompetenten Anwender) überflüssig und man sollte sie vorzugsweise weglassen.

Der eigentlich "artfremde" "Endanwender" lässt sich aber nicht ignorieren und der identifiziert Dateien eben anhand der Erweiterung*. Deshalb bekommen Dateien im unmittelbaren Zugriff des Endanwenders sprechende Endungen, auch wenn sie aus Systemsicht Schall und Rauch sind. Dieser Fremdkörper greift dann um sich und erfasst zunächst zwar anwendernahe, aber vorwiegend automatisch verarbeitete Dateien (Konfigurationsdateien) und später außer zu Debugingzwecken ausschließlich automatisch verarbeitete Dateien (z.B. Flat-DBs).
Davon weiß auch der kompetente Unix-User und erwartet daher (wider besseres Wissen) wie der Endanwender, dass eine Dateiendung etwas über den Dateiinhalt aussagt. Die Endung ".txt" für alle möglichen Plain-Text-Dateien kann diese Erwartung nicht erfüllen, denn sie sagt nichts über die Struktur aus und der Inhalt wird sowieso erst beim Betrachten ersichtlich.

Zwei Beispiele zur Veranschaulichung:

1. Ersetzen wir in Gedanken die unbekannte Datei "plaintext.txt" durch "binary.bin": Was sagt dir nun die Endung ".bin" über die binäre Datei? Nichts! Sie verät dir nichts über den Inhalt und auch nichts über den Zweck. Mit Plain-Text besteht im Prinzip das selbe Problem, wenn auch etwas entschärft, da das Betrachten mit einem beliebigen Plain-Text-Betrachter für den Unix-User eine Fingerübung ist.

2. Stell dir vor, du schaust in ein Verzeichnis mit tausenden unbekannten Plain-Text-Dateien aus verschiedenen Quellen, die alle "*.txt" heißen: Was bringt dir hier die Dateiendung bezüglich Strukturierung? Wieder Nichts! Du kannst Konfigurationsdateien nicht von Logs unterscheiden und Datenbanken nicht von Liebesbriefen.

In beiden Fällen wäre das Weglassen der Erweiterung besser gewesen, denn im besten Fall ist die Endung nutzlos, im schlimmsten Fall irritiert sie. Alternativ wären auch aussagekräftigere Endungen Interesse der Strukturierung besser gewesen.


*) Lass uns bitte ignorieren, dass das eigentlich überholt ist, weil der Endanwender Dateien in Wahrheit an ihrem Thumbnail erkennt, falls er überhaupt noch in der Lage ist Dateitypen zu unterscheiden oder auch nur weiß, was eine Datei ist.

[Meillo]

Ich weiß gerade nicht, ob wir hier aneinander vorbei reden, denn ich sehe das ganz genauso wie du und gerade deshalb (nicht trotzdem) halte ich hier die "Identifizierbarkeit durch Menschen" für nachrangig.

So wie du die Identifizierung durch Menschen in's Spiel gebracht hast, verstehe ich darunter den ursprünglichen DOS/Windows-Ansatz: Ich schaue als Mensch auf die Endung einer Datei und weiß, was da drin steht.
Nun ist diese Herangehensweise ja aber nicht die von Unix. Der klassische, fachkompetente User sollte das wissen und stattdessen die entsprechenden Tools zur Identifizierung nutzen. Dateiendungen sind also aus Sicht von Unix (und seiner kompetenten Anwender) überflüssig und man sollte sie vorzugsweise weglassen.

Der eigentlich "artfremde" "Endanwender" lässt sich aber nicht ignorieren und der identifiziert Dateien eben anhand der Erweiterung*. Deshalb bekommen Dateien im unmittelbaren Zugriff des Endanwenders sprechende Endungen, auch wenn sie aus Systemsicht Schall und Rauch sind. Dieser Fremdkörper greift dann um sich und erfasst zunächst zwar anwendernahe, aber vorwiegend automatisch verarbeitete Dateien (Konfigurationsdateien) und später außer zu Debugingzwecken ausschließlich automatisch verarbeitete Dateien (z.B. Flat-DBs).
Davon weiß auch der kompetente Unix-User und erwartet daher (wider besseres Wissen) wie der Endanwender, dass eine Dateiendung etwas über den Dateiinhalt aussagt. Die Endung ".txt" für alle möglichen Plain-Text-Dateien kann diese Erwartung nicht erfüllen, denn sie sagt nichts über die Struktur aus und der Inhalt wird sowieso erst beim Betrachten ersichtlich.

Ich sehe den Argumentationsweg und er leutet mir ebenso ein. Heute kann ich das fuer mich nicht mehr loesen.

Ich denke mal laut: Das mit den Dateiendungen ist ja schon seltsam unter Unix. Technisch noetig sind sie nicht (im alten Unix). Dennoch gibt es sie auch dort. Das beste Beispiel sind *.c, *.h, *.o, usw. Die wurden von den Unix-Entwicklern selbst eingefuehrt. Dabei koennte man die auch mittels file(1) identifizieren. Gut, moeglicherweise ist file(1) juenger als cc(1). Hier spielt sicher auch noch die Entsprechung mehrerer Dateien eine Rolle: foo.c, foo.h, foo.o. Darum Dateiendungen, also einfaches Mittel zur Gruppenbildung.

Zwei Beispiele zur Veranschaulichung:

1. Ersetzen wir in Gedanken die unbekannte Datei "plaintext.txt" durch "binary.bin": Was sagt dir nun die Endung ".bin" über die binäre Datei? Nichts! Sie verät dir nichts über den Inhalt und auch nichts über den Zweck. Mit Plain-Text besteht im Prinzip das selbe Problem, wenn auch etwas entschärft, da das Betrachten mit einem beliebigen Plain-Text-Betrachter für den Unix-User eine Fingerübung ist.

2. Stell dir vor, du schaust in ein Verzeichnis mit tausenden unbekannten Plain-Text-Dateien aus verschiedenen Quellen, die alle "*.txt" heißen: Was bringt dir hier die Dateiendung bezüglich Strukturierung? Wieder Nichts! Du kannst Konfigurationsdateien nicht von Logs unterscheiden und Datenbanken nicht von Liebesbriefen.

In beiden Fällen wäre das Weglassen der Erweiterung besser gewesen, denn im besten Fall ist die Endung nutzlos, im schlimmsten Fall irritiert sie. Alternativ wären auch aussagekräftigere Endungen Interesse der Strukturierung besser gewesen.

Beim zweiten Beispiel stimme ich dir zu. Jetzt auch mehr als anfangs in dieser Diskussion.

Beim ersten Beispiel sehe ich es (noch? ) etwas anders. Die Endung *.bin hat einen Wert unter Unix, denn unter Unix ist normalerweise alles Text und in den meisten Faellen plain Text. Binaerdateien sorgen fuer eine Menge Probleme, weil sie mit dem System eigentlich kollidieren. Die meisten schoenen Tools funktionieren damit nicht und wenn man sie ausgibt zerschiessen sie das Terminal. Darum macht es Sinn, diese Sonderlinge zu kennzeichnen, sozusagen als Warnhinweis. Das *.bin sagt uns: Achtung, mach bloss kein cat(1) oder ed(1) auf die Datei. Man darf nur Programme verwenden, die bei der Ausgabe nicht-druckbare Zeichen in Ersatzdarstellung ausgeben, wie less(1) und vi(1).



Was sind denn nun unsere Erkenntnisse?

1) Wenn ein klar definiertes, bekanntes Format verwendet wird (was man moeglichst tun sollte), dann sollte man dessen Dateiendung verwenden.

2) Andernfalls besser keine Dateiendung verwenden (ausser bei Binaerdaten evtl. *.bin, damit man sich nicht so leicht das Terminal kaputt schiesst -- dazu hast du noch nichts entgegnet -- ... aber binaere Datenablagen sollte man sowieso als allererstes vermeiden -- wobei wir uns garantiert einig sind).

[hikaru]

Beim ersten Beispiel sehe ich es (noch? ) etwas anders. Die Endung *.bin hat einen Wert unter Unix, denn unter Unix ist normalerweise alles Text und in den meisten Faellen plain Text. Binaerdateien sorgen fuer eine Menge Probleme, weil sie mit dem System eigentlich kollidieren. Die meisten schoenen Tools funktionieren damit nicht und wenn man sie ausgibt zerschiessen sie das Terminal. Darum macht es Sinn, diese Sonderlinge zu kennzeichnen, sozusagen als Warnhinweis. Das *.bin sagt uns: Achtung, mach bloss kein cat(1) oder ed(1) auf die Datei. Man darf nur Programme verwenden, die bei der Ausgabe nicht-druckbare Zeichen in Ersatzdarstellung ausgeben, wie less(1) und vi(1).

Das ist richtig, aber du denkst nicht weit genug.
Wir sind uns einig darüber, dass Binärdateien Mist sind und dass man sie mit gesonderten Dateiendungen markieren sollte, falls man überhaupt Dateien so markiert. Aber alle Binärdateien in einen ".bin"-Sack zu stecken ist nicht besser als alle Plain-Text-Dateien in einen ".txt"-Sack zu stecken. Es ist sogar noch schlimmer, weil anders als bei Plain-Text-Dateien nicht die Möglichkeit der "Interpretation durch den Menschen" besteht.
Daher ist es noch wichtiger, verschiedene Binärdateien mit verschiedenen Endungen zu versehen, weil ".bin" als Sammelbezeichnung an sich eben noch weniger Wert hat als ".txt".

Was sind denn nun unsere Erkenntnisse?

1) Wenn ein klar definiertes, bekanntes Format verwendet wird (was man moeglichst tun sollte), dann sollte man dessen Dateiendung verwenden.

2) Andernfalls besser keine Dateiendung verwenden

Dem kann ich mich anschließen. Wenn du "Andernfalls besser" noch durch "Oder" ersetzt, dann bin ich ganz bei dir.
(Den Einwand in der Klammer berachte ich durch die Erkllärung von oben als entkräftet, falls du damit einverstanden bist.)

[HansD]

Dieser Aussage von dir stimme ich zu. Vermutlich haben wir hier ein Verstaendnisproblem. Ich bin davon ausgegangen, dass es eine beliebige Plaintext-Datei ist (darum *.txt), die irgendein eigenes ``Datenbank''-Format hat, also eigentlich eine beliebige anwendungsspezifische Datenablage in Plaintext. Auf dieser Annahme basiert meine Aussage. Falls es sich aber so verhaelt wie du es beschreibst, dass naemlich sowas wie Sqlite drin steckt, dann sollte eine andere Dateiendung verwendet werden. (Und besser keine als eine unpassende.)

Es ist eine reine Textdatei. Das Format ist denkbar einfach; IMO kein Format eines namhaften Datenbanksystems. Jeder Datensatz ist eine Zeile. Jeder Datensatz besteht aus zwei Feldern, die durch ein Tabulatorzeichen getrennt sind. Also noch simpler als comma-quote-delimited. Ich hab das Ding übrigens nicht erfunden, sondern das ist ein Format, das ich vorgefunden habe und mit meinem Shell-Script abfrage.

Am Ende der Datenfelder gibt es optionale Textmarken, die den Inhalt des jeweiligen Datenfelds klassifizieren.

[Meillo]

Ich habe das Gefuehl, dass ich darauf noch reagieren will ...

Zuerst der einfachere Teil:

Was sind denn nun unsere Erkenntnisse?

1) Wenn ein klar definiertes, bekanntes Format verwendet wird (was man moeglichst tun sollte), dann sollte man dessen Dateiendung verwenden.

2) Andernfalls besser keine Dateiendung verwenden

Dem kann ich mich anschließen. Wenn du "Andernfalls besser" noch durch "Oder" ersetzt, dann bin ich ganz bei dir.
(Den Einwand in der Klammer berachte ich durch die Erkllärung von oben als entkräftet, falls du damit einverstanden bist.)

Da missverstehen wir uns vielleicht. Ich will sagen: Erstens, verwende moeglichst ein klar definiertes, bekanntes Format. Da sind wir doch einer Meinung? Falls du ein solches verwendest, dann nimm auch seine Dateiendung (*.xml, *.ini, *.sqlite, ...). Auch da wirst du zustimmen, vermute ich. Andernfalls, ... Da kommt jetzt die eigentliche Frage auf ...


Nun zum schwierigeren Teil:

Beim ersten Beispiel sehe ich es (noch? ) etwas anders. Die Endung *.bin hat einen Wert unter Unix, denn unter Unix ist normalerweise alles Text und in den meisten Faellen plain Text. Binaerdateien sorgen fuer eine Menge Probleme, weil sie mit dem System eigentlich kollidieren. Die meisten schoenen Tools funktionieren damit nicht und wenn man sie ausgibt zerschiessen sie das Terminal. Darum macht es Sinn, diese Sonderlinge zu kennzeichnen, sozusagen als Warnhinweis. Das *.bin sagt uns: Achtung, mach bloss kein cat(1) oder ed(1) auf die Datei. Man darf nur Programme verwenden, die bei der Ausgabe nicht-druckbare Zeichen in Ersatzdarstellung ausgeben, wie less(1) und vi(1).

Das ist richtig, aber du denkst nicht weit genug.
Wir sind uns einig darüber, dass Binärdateien Mist sind und dass man sie mit gesonderten Dateiendungen markieren sollte, falls man überhaupt Dateien so markiert. Aber alle Binärdateien in einen ".bin"-Sack zu stecken ist nicht besser als alle Plain-Text-Dateien in einen ".txt"-Sack zu stecken. Es ist sogar noch schlimmer, weil anders als bei Plain-Text-Dateien nicht die Möglichkeit der "Interpretation durch den Menschen" besteht.
Daher ist es noch wichtiger, verschiedene Binärdateien mit verschiedenen Endungen zu versehen, weil ".bin" als Sammelbezeichnung an sich eben noch weniger Wert hat als ".txt".

Ich finde nicht, dass *.bin schlimmer ist als *.txt.

Aber von Anfang an: Wenn wir ein bekanntes Format mit eigenes Dateiendung haben, dann sollte man diese verwenden und gut ist. Also geht es nur noch um Dateien, deren Format nicht so recht klar ist (also die ``Andernfalls''-Faelle von oben)? Das ist dann wohl irgendwas Proprietaeres fuer den internen Gebrauch einer Anwendung oder so.

Wenn die Datei nun *.bin heisst, dann weiss ich dadurch zumindest, dass es sich um ein Binaerformat handelt (Warnhinweis) und dass ich den Inhalt vermutlich nicht verstehen werde. Das sind IMO hilfreiche Informationen. (Aber natuerlich: Wir wollen solche Dateien am liebsten gar nicht haben.) Der Informationsgewinn von *.txt ist, dass es irgendeine Art von lesbarem und vermutlich intuitiv verstaendlichem Text handelt. Wir sind uns einig, dass man bei Binaerdaten nicht diese Moeglichkeit der Interpraetation durch den Menschen hat.

Wenn wir die unverstaendliche Binaerdatei nicht *.bin nehnen, wie nennen wir sie dann? Du sagst doch implizit, dass es eine bessere Alternative gibt. Wenn wir eine willkuerliche Dateiendung vergeben, dann sagt uns das auch nicht mehr und birgt die Gefahr der Verwirrung, falls man zufaellig eine Endung waehlt, die jemand anderes auch schon gewaehlt hat. (Falsche Information ist schaedlicher als keine Information.) Laesst man die Dateiendung ganz weg, fehlt der Warnhinweis, den die Sammelendung *.bin bietet. Unter Unix im Terminal wuerde ich darum sagen, dass bei willkuerlichen Binaerdateien im Dateisystem (also nicht *.o oder ``core'' oder ausfuehrbare Dateien) *.bin wertvoller ist als keine Endung. Aber von mir aus, ich kann auch ohne Endung bei Binaerdateien leben. Bloss an der Aussage, dass *.bin schlimmer als *.txt waere, stoere ich mich ein bisschen. Wir muessen uns daran aber auch nicht aufhaengen.

Das war jetzt keine perfekte Antwort, aber ich hab's zumindest mal geschafft zu antworten. Jetzt bist du wieder am Zug.

... irgendwie frage ich mich aber auch ein bisschen, um was genau es eigentlich noch genau geht. Vielleicht kannst du ja die Frage nochmal formulieren.

[hikaru]

Da missverstehen wir uns vielleicht. Ich will sagen: Erstens, verwende moeglichst ein klar definiertes, bekanntes Format. Da sind wir doch einer Meinung? Falls du ein solches verwendest, dann nimm auch seine Dateiendung (*.xml, *.ini, *.sqlite, ...). Auch da wirst du zustimmen, vermute ich.

Zustimmung.

Andernfalls, ... Da kommt jetzt die eigentliche Frage auf ...

... verwende:
A: keine Endung
B: eine selbst gewählte konfliktfreie Endung (z.B.: ".hansbin")

Beide Alternativen sind gleichberechtigt. Welche jeweils vorzuziehen ist, hängt vom Kontext ab.

Ich finde nicht, dass *.bin schlimmer ist als *.txt.

Das war vielleicht etwas drastisch formuliert. Weil Plain Text zumindest noch die Möglichkeit der menschlichen Überprüfung bietet, ist es hier weniger tragisch als bei Binärdateien, wenn die Zuordnung nicht eindeutig ist.
Wenn wir berücksichtigen, dass wir beides eigentlich automatisiert verarbeiten wollen, dann spielt es aber natürlich keine Rolle, dass man da auch nochmal persönlich reinschauen könnte.

Wenn die Datei nun *.bin heisst, dann weiss ich dadurch zumindest, dass es sich um ein Binaerformat handelt (Warnhinweis) und dass ich den Inhalt vermutlich nicht verstehen werde. Das sind IMO hilfreiche Informationen.

Wenn wir nun aber alle unsere proprietären Binärdateien *.bin nennen, dann wissen wir immer noch nicht, ob eine uns zufällig über den Weg laufende *.bin-Datei zu dem selbstgeschriebenen Programm A, B oder Z gehört. Und weil wir nicht einfach reinschauen können um das herauszufinden, ist die Wahl der Endung .bin für alle Binärdateien schlechter als die der Endung .txt für alle Textdateien.
Dass wir überhaupt eine Endung verwenden zeigt, dass wir uns die Mühe gemacht haben unterscheiden zu wollen, ob eine Binärdatei vorliegt oder nicht. Wir sind den Weg aber nicht konsequent zum Ende gegangen, indem wir die Endung so gewählt hätten, dass wir die Datei dem Programm zuordnen könnten. Als grundfaulem Menschen missfällt mir diese Halbherzigkeit. Wir hätten uns die Mühe entweder ganz sparen und ein Bier trinken sollen (keine Endung), oder wir hätten es von Anfang an richtig machen sollen (z.B.: ".bina", ".binb", ".binz").

... irgendwie frage ich mich aber auch ein bisschen, um was genau es eigentlich noch genau geht. Vielleicht kannst du ja die Frage nochmal formulieren.

Die Frage steht - nicht ganz vollständig - im Threadtitel:

Wo und wie speichert man am besten ein Shell-Script und seine Begleitdateien?

[Meillo]

Da missverstehen wir uns vielleicht. Ich will sagen: Erstens, verwende moeglichst ein klar definiertes, bekanntes Format. Da sind wir doch einer Meinung? Falls du ein solches verwendest, dann nimm auch seine Dateiendung (*.xml, *.ini, *.sqlite, ...). Auch da wirst du zustimmen, vermute ich.

Zustimmung.

Andernfalls, ... Da kommt jetzt die eigentliche Frage auf ...

... verwende:
A: keine Endung
B: eine selbst gewählte konfliktfreie Endung (z.B.: ".hansbin")

Beide Alternativen sind gleichberechtigt. Welche jeweils vorzuziehen ist, hängt vom Kontext ab.

Dem kann ich zustimmen.

Ich finde nicht, dass *.bin schlimmer ist als *.txt.

Das war vielleicht etwas drastisch formuliert. Weil Plain Text zumindest noch die Möglichkeit der menschlichen Überprüfung bietet, ist es hier weniger tragisch als bei Binärdateien, wenn die Zuordnung nicht eindeutig ist.
Wenn wir berücksichtigen, dass wir beides eigentlich automatisiert verarbeiten wollen, dann spielt es aber natürlich keine Rolle, dass man da auch nochmal persönlich reinschauen könnte.

Passt soweit auch.

Wenn die Datei nun *.bin heisst, dann weiss ich dadurch zumindest, dass es sich um ein Binaerformat handelt (Warnhinweis) und dass ich den Inhalt vermutlich nicht verstehen werde. Das sind IMO hilfreiche Informationen.

Wenn wir nun aber alle unsere proprietären Binärdateien *.bin nennen, dann wissen wir immer noch nicht, ob eine uns zufällig über den Weg laufende *.bin-Datei zu dem selbstgeschriebenen Programm A, B oder Z gehört. Und weil wir nicht einfach reinschauen können um das herauszufinden, ist die Wahl der Endung .bin für alle Binärdateien schlechter als die der Endung .txt für alle Textdateien.
Dass wir überhaupt eine Endung verwenden zeigt, dass wir uns die Mühe gemacht haben unterscheiden zu wollen, ob eine Binärdatei vorliegt oder nicht. Wir sind den Weg aber nicht konsequent zum Ende gegangen, indem wir die Endung so gewählt hätten, dass wir die Datei dem Programm zuordnen könnten. Als grundfaulem Menschen missfällt mir diese Halbherzigkeit. Wir hätten uns die Mühe entweder ganz sparen und ein Bier trinken sollen (keine Endung), oder wir hätten es von Anfang an richtig machen sollen (z.B.: ".bina", ".binb", ".binz").

Hmm, vielleicht haengen wir zu sehr an dem was wir vor Augen haben, wenn wir hier von Binaerdateien reden. Da gibt es ELF-Dateien (ohne Endung) und etablierte Binaerformate, wie gz, jpg, usw, die alle passende Endungen haben. Um all diese Faelle geht es *nicht*.

Eigentlich geht es nur um irgendwelche ``dahergelaufenen'' Binaerdateien, die es besser gar nicht geben sollte, weil sie entweder in einem der etablierten Formate sein sollten, wodurch die Datenendungsfrage geklaert ist, oder in einem Textformat sein sollten, wodurch sich die *.bin-Frage eruebrigt und die ueberhaupt weniger wichtig ist.

Siehst du es auch so, dass es nur um diesen Fall geht?

... irgendwie frage ich mich aber auch ein bisschen, um was genau es eigentlich noch genau geht. Vielleicht kannst du ja die Frage nochmal formulieren.

Die Frage steht - nicht ganz vollständig - im Threadtitel:

Wo und wie speichert man am besten ein Shell-Script und seine Begleitdateien?

Na ueber die Frage sind wir aber doch schon raus. Jetzt fragen wir uns ganz generell, in welcher Weise Dateiendungen verwendet werden sollten, in den nicht-trivialen Faellen.

[hikaru]

Eigentlich geht es nur um irgendwelche ``dahergelaufenen'' Binaerdateien, die es besser gar nicht geben sollte, weil sie entweder in einem der etablierten Formate sein sollten, wodurch die Datenendungsfrage geklaert ist, oder in einem Textformat sein sollten, wodurch sich die *.bin-Frage eruebrigt und die ueberhaupt weniger wichtig ist.

Siehst du es auch so, dass es nur um diesen Fall geht?

Im Grunde ja, aber das mit dem "besser gar nicht geben sollte" ist eben in der Praxis nicht so einfach. Wenn du Programme hast, die schon in Binärform GB-weise Daten schreiben oder lesen sollen und das möglichst schnell, dann sind Textdateien keine Option. Klingt eigentlich nach einem Fall für eine richtige DB, aber wenn dann auch noch Historie dazukommt, dann wird das zumindest manchmal unpraktisch.
Und wenn du dann zwei oder drei Programme von der Sorte hast, dann wäre es schon hilfreich, wenn du die Dateien den passenden Programmen zuorden kannst. Da bieten sich Dateiendungen an.

[Meillo]

Im Grunde ja, aber das mit dem "besser gar nicht geben sollte" ist eben in der Praxis nicht so einfach. Wenn du Programme hast, die schon in Binärform GB-weise Daten schreiben oder lesen sollen und das möglichst schnell, dann sind Textdateien keine Option. Klingt eigentlich nach einem Fall für eine richtige DB, aber wenn dann auch noch Historie dazukommt, dann wird das zumindest manchmal unpraktisch.
Und wenn du dann zwei oder drei Programme von der Sorte hast, dann wäre es schon hilfreich, wenn du die Dateien den passenden Programmen zuorden kannst. Da bieten sich Dateiendungen an.

... die ungleich *.bin sind. -- Akzeptiert.