Wutze
Anmeldungsdatum: 16. November 2009
Beiträge: 364
|
Hallo zusammen. Ich verstehe es grad nicht und benötige mal bitte Eure Hilfe. Ich habe hier ein ziemlich umfangreiches bash-Script, welches über mehreren Dateien verteilt ist, in Bearbeitung. Nun nimmt das solche Dimensionen an, dass eine "feste" Programmierung so langsam aber sicher unübersichtlich wird. Bisher sieht das (in gekürzter Form) so aus: | #!/usr/bin/env bash
main() {
source init.sh
source echo.sh
}
main
|
Es funktioniert und eigentlich ist alles gut.
Jetzt möchte ich aber alle Scripte, weil es unübersichtlich wird, in einem Unterordner lagern. Die Veränderung funktioniert auch ohne Probleme, es ist ja "nur" ein neuer Pfad. Damit ich aber etwas flexibler werde und nicht jedes Mal das Hauptscript verändern muss, möchte ich das ganze etwas dynamischer machen. Neue Datei einfach einfügen und sie wird mit abgearbeitet. Also so: | #!/usr/bin/env bash
main() {
for file in eingabe/*.sh
do
source $file
done
}
main
|
Das Script bricht mit der ersten Datei ohne Ausgabe eines Fehlers ab. Ersetze ich "source" durch echo, läuft es durch bis zum Ende, jede einzelne Datei wird angezeigt. Ich habe da wohl irgendwo einen Denkfehler, leider sehe ich grad den Wald vor lauter Bäumen nicht. Wo steckt mein Fehler?
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Wenn er vorzeitig abbricht, würde ich mal in die Skripte schauen, ob da irgendwo exit Befehle ausgeführt werden - am besten mal in der zweiten Zeile des Skripts ein set -x einfügen, dann sieht man was für Schritte er durchläuft. Mit einer Process Substitution könnte man auf die for-Schleife verzichten (alle Pfade, die auf den Glob passen, müssen lesbare Dateien sein):
| #!/bin/bash
source <(cat eingabe/*.sh)
|
|
Wutze
(Themenstarter)
Anmeldungsdatum: 16. November 2009
Beiträge: 364
|
Danke, die Idee mit dem Verkürzen ist auch nicht schlecht. Der Fehler lag jedoch ganz woanders. Eine Datei mit dem Namen "ende.sh" wird natürlich immer vor funktion.sh oder query.sh oder xy.sh aufgerufen. Und wenn in der Datei "ende.sh" ein exit 0 steht, nun dann macht das Script natürlich auch, es beendet sich. Ich hole mir jetzt mal meine mobile Tischplatte und werfe sie mir an den Kopf. Danke und Sorry ... das mit den Bäumen und dem Wald, ich wusste es. ...
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12823
|
Zum Tracen packe ich immer folgende Zeile an den Anfang des Skriptes: | test -z "$DEBUG" || set -x
|
Dann kann man einen ganzen Satz von Skripten so tracen: Warum hast Du denn das Skript auf mehrere Dateien aufgeteilt? Wenn Du die Teile nicht mehrfach in anderen Skripten einbinden willst, ist die Sache ggf. einfach zu handhaben, wenn alles in einer Datei ist.
|
Wutze
(Themenstarter)
Anmeldungsdatum: 16. November 2009
Beiträge: 364
|
Danke, auch eine Idee. Ich werde es mal versuchen damit. Der Grund weswegen ich die Dateien aufsplitte ist, dass das eine Script so langsam unübersichtlich geworden ist. Genau genommen ist es mein Firewall-Script, dass inzwischen auf weit über 500 Zeilen angewachsen ist. Und um da wieder etwas Übersicht hinein zu bringen, habe ich für jedes Regelset eine eigene Datei angelegt. Teils sind es sogar diverse Netzwerkgeräte, die ein eigenes Regelset besitzen. Inzwischen erschien mir das aber nicht gut genug, da ich die Flexibilität schätze, ohne im Hauptscript jedes mal Änderungen bzw. Ergänzungen machen zu müssen. Zudem ist es inzwischen auf verschiedenen Routern mit teils sehr unterschiedlichen Konfigurationen aktiv. Updates und Änderungen am Hauptscript waren somit immer sehr aufwändig und oft fehleranfällig. Wenn das ganze läuft wollte ich es sowieso auf github veröffentlichen. Dann wird sich sicher automatisch erklären, weswegen ich diesen Weg gewählt. habe. ;o)
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12823
|
Wutze schrieb:
Der Grund weswegen ich die Dateien aufsplitte ist, dass das eine Script so langsam unübersichtlich geworden ist. Genau genommen ist es mein Firewall-Script, dass inzwischen auf weit über 500 Zeilen angewachsen ist.
Oh. Wenn man so viele Feuerwandregeln hat, dann wird es natürlich leicht mal unübersichtlich. So etwas kann auch ein Sicherheitsproblem sein.
Und um da wieder etwas Übersicht hinein zu bringen, habe ich für jedes Regelset eine eigene Datei angelegt. Teils sind es sogar diverse Netzwerkgeräte, die ein eigenes Regelset besitzen. Inzwischen erschien mir das aber nicht gut genug, da ich die Flexibilität schätze, ohne im Hauptscript jedes mal Änderungen bzw. Ergänzungen machen zu müssen. Zudem ist es inzwischen auf verschiedenen Routern mit teils sehr unterschiedlichen Konfigurationen aktiv. Updates und Änderungen am Hauptscript waren somit immer sehr aufwändig und oft fehleranfällig.
Dann macht es natürlich Sinn, den Teil, der gemeinsam ist, zu zentralisieren und die gerätespezifische Logik auszulagern.
Wenn das ganze läuft wollte ich es sowieso auf github veröffentlichen. Dann wird sich sicher automatisch erklären, weswegen ich diesen Weg gewählt. habe. ;o)
Ja, da bin ich gespannt.
|
Wutze
(Themenstarter)
Anmeldungsdatum: 16. November 2009
Beiträge: 364
|
So, was lange währt wird gut, oder so. Das "Script", wenn man das noch so sagen darf, ist so weit erst mal fertig und auch getestet.
Es läuft eigentlich ohne Probleme, wurde am Ende nur ein klein wenig umfangreicher als gedacht. Aber jetzt deckt es meines Erachtens nach alles ab was man möchte. Wer mag kann ja hier mal rein sehen https://github.com/Wutze/firewall Die Doku ist noch nicht ganz beendet, für den ersten Blick und Verständnis sollte es aber genügen, denke ich. Wird auf jeden Fall noch weiter entwickelt, so ich die Zeit dazu finde. Viel Spaß
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12823
|
Wutze schrieb: So, was lange währt wird gut, oder so.
☺
Wer mag kann ja hier mal rein sehen https://github.com/Wutze/firewall
Ein paar völlig unsortierte Anmerkungen:
Die Funktion main ist völlig überflüssig und führt nur dazu, dass der Code weiter eingerückt wird. Die Variablen main0 usw. sind gleich mehrfach überflüssig: zum einen, weil sie einfach nur die Werte von $0, $1 und $2 beinhalten, zum anderen, weil man die Werte auch beim Aufruf übergeben könnte und schließlich wegen dem vorherigen Punkt. Die Hilfe kannst Du einfacher durch ein Here-Document erzeugen. Wenn man Variablen, die nur intern im Skript verwendet und nicht exportiert werden, klein schreibt, ist es ein bisschen übersichtlicher. Die Variablen TICK und CROSS werden nur an einer Stelle verwendet, weshalb ich sie komplett streichen würde. Die Werte in den Variablen COL_* könnte man ggf. portabler mit tput erzeugen. Damit wäre das Skript noch unabhängiger vom aktuellen Terminal.
|
Wutze
(Themenstarter)
Anmeldungsdatum: 16. November 2009
Beiträge: 364
|
rklm schrieb: Ein paar völlig unsortierte Anmerkungen:
Die natürlich gern gesehen sind. Danke.
Die Funktion main ist völlig überflüssig und führt nur dazu, dass der Code weiter eingerückt wird. Die Variablen main0 usw. sind gleich mehrfach überflüssig: zum einen, weil sie einfach nur die Werte von $0, $1 und $2 beinhalten, zum anderen, weil man die Werte auch beim Aufruf übergeben könnte und schließlich wegen dem vorherigen Punkt.
Im Grunde hast Du Recht. Das Dilemma ist hier eben, ich finde es so übersichtlicher, strukturierter.
Das ist ne Idee
Wenn man Variablen, die nur intern im Skript verwendet und nicht exportiert werden, klein schreibt, ist es ein bisschen übersichtlicher.
Einer meiner üblichen "Fehler".
Die Variablen TICK und CROSS werden nur an einer Stelle verwendet, weshalb ich sie komplett streichen würde. Die Werte in den Variablen COL_* könnte man ggf. portabler mit tput erzeugen. Damit wäre das Skript noch unabhängiger vom aktuellen Terminal.
Mal reinlesen. tput war mir bisher gar nicht so geläufig. Auf jeden Fall Danke fürs rein sehen. Im Moment muss das Script sich im harten Alltagseinsatz beweisen. Da wird sicher die ein oder andere Idee noch mit einfließen. Im Moment hab ich jedenfalls viel Spaß, endlich ist das alles mal "aufgeräumt" und zeigt auch die richtigen Fehler an. Und im Gegensatz zu der vorherigen Version, die ich ja hier schon mal dokumentiert habe ( https://forum.ubuntuusers.de/topic/iptables-im-netzwerk-firewall-netzwerkdoku/ ), ist das ein gewaltiger Sprung. ;o)
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12823
|
Wutze schrieb: rklm schrieb: Ein paar völlig unsortierte Anmerkungen:
Die natürlich gern gesehen sind. Danke.
Bitte.
Die Funktion main ist völlig überflüssig und führt nur dazu, dass der Code weiter eingerückt wird. Die Variablen main0 usw. sind gleich mehrfach überflüssig: zum einen, weil sie einfach nur die Werte von $0, $1 und $2 beinhalten, zum anderen, weil man die Werte auch beim Aufruf übergeben könnte und schließlich wegen dem vorherigen Punkt.
Im Grunde hast Du Recht. Das Dilemma ist hier eben, ich finde es so übersichtlicher, strukturierter.
😛 Bist Du C-Programmierer? 😉
Die Variablen TICK und CROSS werden nur an einer Stelle verwendet, weshalb ich sie komplett streichen würde. Die Werte in den Variablen COL_* könnte man ggf. portabler mit tput erzeugen. Damit wäre das Skript noch unabhängiger vom aktuellen Terminal.
Mal reinlesen. tput war mir bisher gar nicht so geläufig.
Ich wollte mir auch immer malTM diese ganzen Tools und Specs für Terminalbeschreibungen in Ruhe zu Gemüte zu führen. Aber wie das immer so ist...
Auf jeden Fall Danke fürs rein sehen. Im Moment muss das Script sich im harten Alltagseinsatz beweisen. Da wird sicher die ein oder andere Idee noch mit einfließen.
Klar, so etwas ist meistens ein Prozess. Von Zeit zu Zeit kommen dann noch mal neue Anforderungen dazu oder die genannten neuen Ideen. Da bastelt man dann weiter. ☺
Im Moment hab ich jedenfalls viel Spaß, endlich ist das alles mal "aufgeräumt" und zeigt auch die richtigen Fehler an. Und im Gegensatz zu der vorherigen Version, die ich ja hier schon mal dokumentiert habe ( https://forum.ubuntuusers.de/topic/iptables-im-netzwerk-firewall-netzwerkdoku/ ), ist das ein gewaltiger Sprung. ;o)
Prima!
|