1 Aug
2022
1 Aug
'22
5:17 p.m.
Beim booten läuft bei mir ein script. Gestartet aus einem rc5.d/Sxx.
Da wird z.B. eine Textdatei aus dem System geparst und daraufhin
bestimmte Variablen und auch Pfade gesetzt.
Diese werden dann im weitere Verlauf genutzt und zu verschiedenen
Aktivitäten führen. Soweit so normal.
Jetzt ist mein script schon etwas länglich geworden und es droht die
Übersicht verloren zu gehen. Also hab ich es in Funktionen aufgeteilt.
Damit wird das script aber nicht kürzer. Das ganze möchte ich etwas
wartungsfreundlicher und lesbarer gestalten.
Ideal wäre ein einem Startscript die Variablen/Pfade zu setzen und dann
bestimmte Unterscripts zu starten. Was aber dabei ein Problem zu sein
scheint:
a) die Variablen vom Startscript übernehmen
b) Variablen im Idealfall auch noch von Unterscript zu Unterscript
weiterreichen
Erschwerend kommt hinzu, dass das ganze während des Bootens passiert,
also nicht aus einer klassischen shell heraus. Ich meine, das nicht mal
a) da so ohne weiteres geht. Oder gibt es da Tricks? Ich hab nicht so
viel sinnvolles dazu gefunden oder ich hab nicht die richtigen keywords
dazu.
Zusatzfrage:
Wenn ein Script wie meines gerade aus Funktionen besteht:
Am Ende der Funktionsdefinitionen werden die aufgerufen.
Kann man z.B. zum Testen, diese Funktionen (aus einer echten) Shell auch
einzeln aufrufen?
Also nur einzelne Funktionen um das Step by Step zu testen. Wie gesagt,
die Pfade/Variablen müssen gesetzt bleiben, sonst ist es sinnlos.
Bei läuft dann immer nur das ganze Script...
Wenn ich das richtig verstanden hab, kann man nur dann einzelne
Funktionen eines scripts aufrufen, wenn es kein "main" gibt, also
sozusagen nur Funktionen. Ist das wahr?
Schöne Woche,
Arno
1 Aug
1 Aug
11:16 p.m.
New subject: Aw: shell scripte und Funktionen/Gliederung
Hallo Arno,
Das hängt von deiner verwendeten Shell ab.
In der Bash gibt es das "source"-Kommando dafür.
https://devconnected.com/source-command-on-linux-explained/
Viele Grüße,
Stefan.
Gesendet: Montag, 01. August 2022 um 17:17 Uhr
Von: "Arno" <epsi(a)gmx.de>
An: flug(a)lug-freiburg.de
Betreff: shell scripte und Funktionen/Gliederung
Beim booten läuft bei mir ein script. Gestartet aus einem rc5.d/Sxx.
Da wird z.B. eine Textdatei aus dem System geparst und daraufhin
bestimmte Variablen und auch Pfade gesetzt.
Diese werden dann im weitere Verlauf genutzt und zu verschiedenen
Aktivitäten führen. Soweit so normal.
Jetzt ist mein script schon etwas länglich geworden und es droht die
Übersicht verloren zu gehen. Also hab ich es in Funktionen aufgeteilt.
Damit wird das script aber nicht kürzer. Das ganze möchte ich etwas
wartungsfreundlicher und lesbarer gestalten.
Ideal wäre ein einem Startscript die Variablen/Pfade zu setzen und dann
bestimmte Unterscripts zu starten. Was aber dabei ein Problem zu sein
scheint:
a) die Variablen vom Startscript übernehmen
b) Variablen im Idealfall auch noch von Unterscript zu Unterscript
weiterreichen
Erschwerend kommt hinzu, dass das ganze während des Bootens passiert,
also nicht aus einer klassischen shell heraus. Ich meine, das nicht mal
a) da so ohne weiteres geht. Oder gibt es da Tricks? Ich hab nicht so
viel sinnvolles dazu gefunden oder ich hab nicht die richtigen keywords
dazu.
Zusatzfrage:
Wenn ein Script wie meines gerade aus Funktionen besteht:
Am Ende der Funktionsdefinitionen werden die aufgerufen.
Kann man z.B. zum Testen, diese Funktionen (aus einer echten) Shell auch
einzeln aufrufen?
Also nur einzelne Funktionen um das Step by Step zu testen. Wie gesagt,
die Pfade/Variablen müssen gesetzt bleiben, sonst ist es sinnlos.
Bei läuft dann immer nur das ganze Script...
Wenn ich das richtig verstanden hab, kann man nur dann einzelne
Funktionen eines scripts aufrufen, wenn es kein "main" gibt, also
sozusagen nur Funktionen. Ist das wahr?
Schöne Woche,
Arno
2 Aug
2 Aug
5:30 p.m.
Hallo Stefan,
vielen Dank.
Es ist tatsächlich nur die sh, nicht mal die bash, schätze aus der Busybox.
Ok verstehe, das souce script.sh macht schon was anderes als nur ein
./script.sh.
Also sieht so aus als wenn man im Hauptscript script.sh ein source
subscript.sh machen kann und dies alle Variablen kennt die auch in
script.sh bekannte sind (bis du dem Aufruf schätze ich).
Aber Variablen aus dem subscript wieder in script.sh zurück geben?
Mal sehen ob ich morgen Abend. mal zum testen kommen.
Gruß,
Arno
Am 01.08.22 um 23:16 schrieb Stefan Ziegler:
Hallo Arno,
Das hängt von deiner verwendeten Shell ab.
In der Bash gibt es das "source"-Kommando dafür.
https://devconnected.com/source-command-on-linux-explained/
Viele Grüße,
Stefan.
> Gesendet: Montag, 01. August 2022 um 17:17 Uhr
> Von: "Arno" <epsi(a)gmx.de>
> An: flug(a)lug-freiburg.de
> Betreff: shell scripte und Funktionen/Gliederung
>
> Beim booten läuft bei mir ein script. Gestartet aus einem rc5.d/Sxx.
> Da wird z.B. eine Textdatei aus dem System geparst und daraufhin
> bestimmte Variablen und auch Pfade gesetzt.
> Diese werden dann im weitere Verlauf genutzt und zu verschiedenen
> Aktivitäten führen. Soweit so normal.
>
> Jetzt ist mein script schon etwas länglich geworden und es droht die
> Übersicht verloren zu gehen. Also hab ich es in Funktionen aufgeteilt.
> Damit wird das script aber nicht kürzer. Das ganze möchte ich etwas
> wartungsfreundlicher und lesbarer gestalten.
> Ideal wäre ein einem Startscript die Variablen/Pfade zu setzen und dann
> bestimmte Unterscripts zu starten. Was aber dabei ein Problem zu sein
> scheint:
> a) die Variablen vom Startscript übernehmen
> b) Variablen im Idealfall auch noch von Unterscript zu Unterscript
> weiterreichen
>
> Erschwerend kommt hinzu, dass das ganze während des Bootens passiert,
> also nicht aus einer klassischen shell heraus. Ich meine, das nicht mal
> a) da so ohne weiteres geht. Oder gibt es da Tricks? Ich hab nicht so
> viel sinnvolles dazu gefunden oder ich hab nicht die richtigen keywords
> dazu.
>
> Zusatzfrage:
> Wenn ein Script wie meines gerade aus Funktionen besteht:
> Am Ende der Funktionsdefinitionen werden die aufgerufen.
> Kann man z.B. zum Testen, diese Funktionen (aus einer echten) Shell auch
> einzeln aufrufen?
> Also nur einzelne Funktionen um das Step by Step zu testen. Wie gesagt,
> die Pfade/Variablen müssen gesetzt bleiben, sonst ist es sinnlos.
> Bei läuft dann immer nur das ganze Script...
> Wenn ich das richtig verstanden hab, kann man nur dann einzelne
> Funktionen eines scripts aufrufen, wenn es kein "main" gibt, also
> sozusagen nur Funktionen. Ist das wahr?
>
> Schöne Woche,
> Arno
>
7:15 a.m.
On Mon, Aug 01, 2022 at 05:17:25PM +0200, Arno wrote:
Beim booten läuft bei mir ein script. Gestartet aus
einem rc5.d/Sxx.
[...] Soweit so normal.
Jetzt ist mein script schon etwas länglich geworden und es droht die
Übersicht verloren zu gehen. Also hab ich es in Funktionen aufgeteilt.
Damit wird das script aber nicht kürzer. Das ganze möchte ich etwas
wartungsfreundlicher und lesbarer gestalten.
Ideal wäre ein einem Startscript die Variablen/Pfade zu setzen und dann
bestimmte Unterscripts zu starten. Was aber dabei ein Problem zu sein
scheint:
a) die Variablen vom Startscript übernehmen
b) Variablen im Idealfall auch noch von Unterscript zu Unterscript
weiterreichen
Die Frage ist ziemlich allgemein gestellt, deshalb kann nur eine
ziemlich allgemeine Antwort gegeben werden.
Was an der Shell besonders ist (und heute eher ungewöhnlich, und
ungewohnt) ist, dass die "Variablen" einen dynamischen Scope haben,
d.h., wenn ich eine in einem Stück Shell setze, dann ist sie in
allen Stücken, die von dort aus aufgerufen werden auch "sichtbar"
(wenn das Aufrufen nicht als (shell-) Funktion passiert, sondern
durch "Aurufen" einer anderen Datai (Subshell), dann muss die
Variable EXPORTiert werden).
Eine andere Ungewöhnlichkeit ist das Textersetzungsmodell: eine
Zeile wird erst nach bestimmten Regeln transformiert ($variable
wird durch ihr Wert ersetzt, $(ausdruck) auch, etc.) und dann
erst interpretiert.
Diese zwei Dinge zu managen führt zu einem etwas anderen Stil
in der Programm"architektur".
So. Genug herumgeschwafelt ;-)
Erschwerend kommt hinzu, dass das ganze während des
Bootens passiert,
also nicht aus einer klassischen shell heraus. Ich meine, das nicht mal
a) da so ohne weiteres geht. Oder gibt es da Tricks? Ich hab nicht so
viel sinnvolles dazu gefunden oder ich hab nicht die richtigen keywords
dazu.
Das ist alles halb so wild. Shell ist shell. Du musst wissen, mit welcher
Du es zu tun hast (ist es die bash? ist es ihre kleine Schwester) und
Du musst berücksichtigen, mit welcher Umgebung Du es zu tun hast (ist
$PATH so wie Du sie erwartest? Musst Du ggf. "/bin/rm" statt nur "rm"
sagen? Plane etwas Zeit ein fürs Debuggen).
Zusatzfrage:
Wenn ein Script wie meines gerade aus Funktionen besteht:
Am Ende der Funktionsdefinitionen werden die aufgerufen.
Kann man z.B. zum Testen, diese Funktionen (aus einer echten) Shell auch
einzeln aufrufen?
How do the masters do it?
Einen netten Ansatz findest Du bei den alten sysvinit-Skripten. Die
ersten zwei Zeilen (abgesehen von Kommentaren) in einem (Quizfrage:
welches?) von meinen sehen so aus:
[ -r /usr/share/postgresql-common/init.d-functions ] || exit 0
. /usr/share/postgresql-common/init.d-functions
Es wird eine Datei "gesourct", in der irgendwelche nützliche Funktionen
definiert werden. Das würde ich mal das "library"-Pattern nennen.
Also nur einzelne Funktionen um das Step by Step zu
testen. Wie gesagt,
die Pfade/Variablen müssen gesetzt bleiben, sonst ist es sinnlos.
Was auch immer Du damit meinst. Das muss konkreter werden. Wenn ich
eine Variable in einer Funktion setze, dann ist dieser Zustand im die
Funktion einschliessenden Skript sichtbar. Nicht jedoch, wenn ich sie
in einem "Unterskript" setze.
Bei läuft dann immer nur das ganze Script...
Wenn ich das richtig verstanden hab, kann man nur dann einzelne
Funktionen eines scripts aufrufen, wenn es kein "main" gibt, also
sozusagen nur Funktionen. Ist das wahr?
Ich weiss nicht genau, wie ich die Aussage im Kontext einer Shell
verstehen soll. Vermutlich nicht. Wer oder was ist "main"?
Nehmen wir an, ich habe ein Skript, nennen wir es "muuh":
#!/bin/bash
echo "Guten Morgen"
say-hello ()
{
echo hello
}
say-good-bye ()
{
echo good bye
}
Und dann "source" ich das Ding in einem anderen:
...
. muuh
...
Was passiert ist, dass wenn die Ausführung in meinem Skript an diesen
Punkt kommt, "Guten Morgen" ausgegeben wird (wohin immer gerade stdout
zeigt) und die zwei Funktionen definiert werden, die ich dann im
weiteren Verlauf verwenden kann.
Ein ganz gerader, naiver Interpreter: mach' dies, dann mach' das. Ob
die Ausgabe von "Guten Morgen" jetzt erwünscht war oder nicht, das
kannst nur Du wissen. Typischerweise wird man so eine Library so bauen,
dass sie nur Funktionen definiert, sei es nur darum, nicht den Verstand
zu verlieren. Vielleicht meintest Du das mit "main".
Solche allgemeinen Regeln finde ich immer suspekt.
Da gibt es noch ein anderes Muster, das mit den Subcommands (inspiriert
durch git). Aber das möge erst mal genügen :)
lg
--
t
5:51 p.m.
Am 02.08.22 um 07:15 schrieb tomas(a)tuxteam.de:
Konkret: Wenn value=10 vor dem Aufruf von init.d-functions steht, dann
ist value dort bekannt.
Aber was wenn ich in init.d-functions value2=20 setze.
Kann ich die 20 in dem aufrufenden Vater-Script verwenden?
Ok aber kann ich auch (Syntax frei erfunden)
. muh::say-hello()
machen und dann wird nur "hello" zurückgebeben.
Das meine ich, wenn ich die Funktionen eines Scripts testen will.
Bei mir wäre gegenwärtig das Problem das das muh wohl so aussieht:
#/bin/sh
funk1() { echo 1 }
funk2() { echo 2 }
funk3() { echo 3 }
echo Test
funk1
echo blabla
funk3
funk2
Ich müsste zum Test die unteren 5 Zeilen komplett rausnehmen und
source muh.sh
funk2
machen um nur funk2 zu testen, richtig?
On Mon, Aug 01, 2022 at 05:17:25PM +0200, Arno wrote:
Ja, es ist nur die /bin/sh
Beim booten läuft bei mir ein script. Gestartet
aus einem rc5.d/Sxx.
[...] Soweit so normal.
Jetzt ist mein script schon etwas länglich geworden und es droht die
Übersicht verloren zu gehen. Also hab ich es in Funktionen aufgeteilt.
Damit wird das script aber nicht kürzer. Das ganze möchte ich etwas
wartungsfreundlicher und lesbarer gestalten.
Ideal wäre ein einem Startscript die Variablen/Pfade zu setzen und dann
bestimmte Unterscripts zu starten. Was aber dabei ein Problem zu sein
scheint:
a) die Variablen vom Startscript übernehmen
b) Variablen im Idealfall auch noch von Unterscript zu Unterscript
weiterreichen
Die Frage ist ziemlich allgemein gestellt, deshalb kann nur eine
ziemlich allgemeine Antwort gegeben werden.
Was an der Shell besonders ist (und heute eher ungewöhnlich, und
ungewohnt) ist, dass die "Variablen" einen dynamischen Scope haben,
d.h., wenn ich eine in einem Stück Shell setze, dann ist sie in
allen Stücken, die von dort aus aufgerufen werden auch "sichtbar"
(wenn das Aufrufen nicht als (shell-) Funktion passiert, sondern
durch "Aurufen" einer anderen Datai (Subshell), dann muss die
Variable EXPORTiert werden).
Eine andere Ungewöhnlichkeit ist das Textersetzungsmodell: eine
Zeile wird erst nach bestimmten Regeln transformiert ($variable
wird durch ihr Wert ersetzt, $(ausdruck) auch, etc.) und dann
erst interpretiert.
Diese zwei Dinge zu managen führt zu einem etwas anderen Stil
in der Programm"architektur".
So. Genug herumgeschwafelt ;-)
Erschwerend kommt hinzu, dass das ganze während
des Bootens passiert,
also nicht aus einer klassischen shell heraus. Ich meine, das nicht mal
a) da so ohne weiteres geht. Oder gibt es da Tricks? Ich hab nicht so
viel sinnvolles dazu gefunden oder ich hab nicht die richtigen keywords
dazu.
Das ist alles halb so wild. Shell ist shell. Du musst wissen, mit welcher
Du es zu tun hast (ist es die bash? ist es ihre kleine Schwester) und Du musst berücksichtigen, mit welcher Umgebung Du es
zu tun hast (ist
$PATH so wie Du sie erwartest? Musst Du ggf. "/bin/rm" statt nur
"rm"
sagen? Plane etwas Zeit ein fürs Debuggen).
Das ist klar, da verwende ich nur absolute Pfade.
Zusatzfrage:
Wenn ein Script wie meines gerade aus Funktionen besteht:
Am Ende der Funktionsdefinitionen werden die aufgerufen.
Kann man z.B. zum Testen, diese Funktionen (aus einer echten) Shell auch
einzeln aufrufen?
How do the masters do it?
Einen netten Ansatz findest Du bei den alten sysvinit-Skripten. Die
ersten zwei Zeilen (abgesehen von Kommentaren) in einem (Quizfrage:
welches?) von meinen sehen so aus:
[ -r /usr/share/postgresql-common/init.d-functions ] || exit 0
. /usr/share/postgresql-common/init.d-functions
Es wird eine Datei "gesourct", in der irgendwelche nützliche Funktionen
definiert werden. Das würde ich mal das "library"-Pattern nennen. Also nur
einzelne Funktionen um das Step by Step zu testen. Wie gesagt,
die Pfade/Variablen müssen gesetzt bleiben, sonst ist es sinnlos.
Was auch immer Du damit meinst. Das muss konkreter werden. Wenn ich
eine Variable in einer Funktion setze, dann ist dieser Zustand im die
Funktion einschliessenden Skript sichtbar. Nicht jedoch, wenn ich sie
in einem "Unterskript" setze. Bei läuft dann
immer nur das ganze Script...
Wenn ich das richtig verstanden hab, kann man nur dann einzelne
Funktionen eines scripts aufrufen, wenn es kein "main" gibt, also
sozusagen nur Funktionen. Ist das wahr?
Ich weiss nicht genau, wie ich die Aussage im Kontext einer Shell
verstehen soll. Vermutlich nicht. Wer oder was ist "main"?
Nehmen wir an, ich habe ein Skript, nennen wir es "muuh":
#!/bin/bash
echo "Guten Morgen"
say-hello ()
{
echo hello
}
say-good-bye ()
{
echo good bye
}
Und dann "source" ich das Ding in einem anderen:
...
. muuh
...
Was passiert ist, dass wenn die Ausführung in meinem Skript an diesen
Punkt kommt, "Guten Morgen" ausgegeben wird (wohin immer gerade stdout
zeigt) und die zwei Funktionen definiert werden, die ich dann im
weiteren Verlauf verwenden kann.
Immerhin. Also sind die Funktionen auch nach Ausführung noch verfügbar.
Ein ganz gerader, naiver Interpreter: mach' dies,
dann mach' das. Ob
die Ausgabe von "Guten Morgen" jetzt erwünscht war oder nicht, das
kannst nur Du wissen. Typischerweise wird man so eine Library so bauen,
dass sie nur Funktionen definiert, sei es nur darum, nicht den Verstand
zu verlieren. Vielleicht meintest Du das mit "main".
Solche allgemeinen Regeln finde ich immer suspekt.
Da gibt es noch ein anderes Muster, das mit den Subcommands (inspiriert
durch git). Aber das möge erst mal genügen :)
lg
Also vielen Dank für die Mühe, dann werd ich mich mal ans refactoring
machen und mit kleinen Demos beginnen.
Viele Grüße,
Arno
9:13 p.m.
On Tue, Aug 02, 2022 at 05:51:40PM +0200, Arno wrote:
"die" /bin/sh gibt es nicht wirklich:
tomas@trotzki:~$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 Dec 10 2020 /bin/sh -> dash
(Wenn Du sagst, dass es bei Dir eine Busybox ist, dann wird's etwas
anders sein).
das einzige, was dieser Tage erwartet wird ist, dass sie einigermassen
Bourne-kompatibel ist.
Konkret: Wenn value=10 vor dem Aufruf von init.d-functions steht, dann
ist value dort bekannt.
Aber was wenn ich in init.d-functions value2=20 setze.
Kann ich die 20 in dem aufrufenden Vater-Script verwenden?
Nicht in einem "Unterskript". Aber in einer Funktion. Die Frage ist,
ob Du das /willst/. Du siehst Deinem Hauptskript nicht an, ob eine
Variable zwei Stockwerke tiefer verändert wird. Vielleicht passiert
das nur aus Versehen, weil jemand "da unten" auch den Namen $BLUNTSCHLI
für was ganz anderes verwendet wurde?
Entweder machst Du dazu also Gebrauch vom Library-Pattern (s.o.), oder
Du "gibst ein Ergebnis zurück". Da strenggenommen Shell-Funktionen nur
eine Art (Integer) "Fehlercode" zurückliefern, kannst Du mit stdout
arbeiten:
secret-name () {
echo "rumpelstilzchen"
}
SECRET=$(secret-name)
... so etwas funktioniert. Auch noch krasser:
SECRET=$(secret-name | sed -e s/u/ü/g)
Das schöne an dem Stil ist, dass Du in Deinem Hauptprogramm /siehst/,
dass der Wert der Variable SECRET verändert wird.
[...]
Nö, sowas wie namespaces gibt es nicht.
Ja, im Skript immer.
Am 02.08.22 um 07:15 schrieb tomas(a)tuxteam.de:
> On Mon, Aug 01, 2022 at 05:17:25PM +0200, Arno wrote:
> > Beim booten läuft bei mir ein script. Gestartet aus einem rc5.d/Sxx.
> > [...] Soweit so normal.
[...]
Das ist alles
halb so wild. Shell ist shell. Du musst wissen, mit welcher
Du es zu tun hast (ist es die bash? ist es ihre kleine Schwester) und
Ja, es ist nur die /bin/sh > Du musst berücksichtigen, mit welcher Umgebung Du
es zu tun hast (ist
> $PATH so wie Du sie erwartest? [...]
Das ist klar, da verwende ich nur absolute Pfade.
Nicht so klar: vielleicht willst Du Deinen Anwender*innen einen "Platz"
geben für "hier was auch immer Ihr für rm benutzt". Die OO-Fuzzis nennen
sowas "mixin". Man kann den Kopf so oder auch so drehen :-)
Zusatzfrage:
Wenn ein Script wie meines gerade aus Funktionen besteht:
Am Ende der Funktionsdefinitionen werden die aufgerufen.
Kann man z.B. zum Testen, diese Funktionen (aus einer echten) Shell auch
einzeln aufrufen?
How do the masters do it?
Einen netten Ansatz findest Du bei den alten sysvinit-Skripten. Die
ersten zwei Zeilen (abgesehen von Kommentaren) in einem (Quizfrage:
welches?) von meinen sehen so aus:
[ -r /usr/share/postgresql-common/init.d-functions ] || exit 0
. /usr/share/postgresql-common/init.d-functions
Es wird eine Datei "gesourct", in der irgendwelche nützliche Funktionen
definiert werden. Das würde ich mal das "library"-Pattern nennen. Nehmen wir an,
ich habe ein Skript, nennen wir es "muuh":
#!/bin/bash
echo "Guten Morgen"
say-hello ()
{
echo hello
}
say-good-bye ()
{
echo good bye
}
Und dann "source" ich das Ding in einem anderen:
...
. muuh
...
Ok aber kann ich auch (Syntax frei erfunden)
. muh::say-hello()
machen und dann wird nur "hello" zurückgebeben.
Das meine ich, wenn ich die Funktionen eines Scripts testen will. Bei mir wäre gegenwärtig das Problem das das muh wohl
so aussieht:
#/bin/sh
funk1() { echo 1 }
funk2() { echo 2 }
funk3() { echo 3 }
echo Test
funk1
echo blabla
funk3
funk2
Ich müsste zum Test die unteren 5 Zeilen komplett rausnehmen und
source muh.sh
funk2
machen um nur funk2 zu testen, richtig?
(Syntax-Anmerkung: nach "echo 1" usw muss wahrscheinlich ein ; sein)
Richtig. Der erste Stück geht in eine eigene Datei, my-functions, der
zweite benutzt das. Das ist vermutlich die "lesbarste" Variante. Nicht
die einzige. Eine andere:
#!/bin/sh
# datei: muh
fun1 () { ... }
...
if [ -n "$TESTING" ] ; then exit 0 ; fi
echo blabla
Also: wenn die Variable TESTING gesetzt ist, dann hüpfst Du raus,
nachdem die Funktionen definiert wurden aber bevor der Schaden
angerichtet ist. Mir gefällt die Variante nicht so sehr, aber sie
soll ja Dir gefallen :-)
Was passiert
ist, dass wenn die Ausführung in meinem Skript an diesen
Punkt kommt, "Guten Morgen" ausgegeben wird (wohin immer gerade stdout
zeigt) und die zwei Funktionen definiert werden, die ich dann im
weiteren Verlauf verwenden kann.
Immerhin. Also sind die Funktionen auch nach Ausführung noch verfügbar. > Ein ganz gerader, naiver Interpreter: mach'
dies, dann mach' das [...]
Also vielen Dank für die Mühe, dann werd ich mich mal
ans refactoring
machen und mit kleinen Demos beginnen.
Gerne :)
lg
--
t
11:22 p.m.
Hallo Arno,
On 8/1/22 17:17, Arno wrote:
Beim booten läuft bei mir ein script. Gestartet aus
einem rc5.d/Sxx.
Da wird z.B. eine Textdatei aus dem System geparst und daraufhin
bestimmte Variablen und auch Pfade gesetzt.
Diese werden dann im weitere Verlauf genutzt und zu verschiedenen
Aktivitäten führen. Soweit so normal.
..ooOO(Hmm, anno 2022 sind sh-Skripte in rc5.d/Sxx nicht mehr sooo
normal, oder? :-)
Jetzt ist mein script schon etwas länglich geworden
und es droht die
Übersicht verloren zu gehen. Also hab ich es in Funktionen aufgeteilt.
Damit wird das script aber nicht kürzer. Das ganze möchte ich etwas
wartungsfreundlicher und lesbarer gestalten.
Ideal wäre ein einem Startscript die Variablen/Pfade zu setzen und dann
bestimmte Unterscripts zu starten. Was aber dabei ein Problem zu sein
scheint:
a) die Variablen vom Startscript übernehmen
b) Variablen im Idealfall auch noch von Unterscript zu Unterscript
weiterreichen
Hierzu wurde ja schon einiges beigetragen. Mein Reflex wäre ein Skript,
das die beschriebene Komplexität erreicht hat, in was anderem als plain
Shell zu schreiben. Ich würde vermutlich Python bevorzugen, aber je nach
Gusto gibt es ja viele weitere Möglichkeiten (Perl, Bash, Node, rust, C,
...).
Erschwerend kommt hinzu, dass das ganze während des
Bootens passiert,
also nicht aus einer klassischen shell heraus.
Was ist der relevante Unterschied zwischen einem Skript, das von init
aufgerufen wird und einer "klassischen Shell"?
Liebe Grüße
Uwe
3 Aug
3 Aug
6:36 a.m.
On Tue, Aug 02, 2022 at 11:22:31PM +0200, Uwe Kleine-König wrote:
Da hatten wir zwei Kandidaten: was anderes als die gewohnte Bash (mensch
muss dann nach "bashisms" suchen) und eine andere Umgebung (environment
variables). Zweiteres ist ganz lustig: debian-user sieht mindestens
jeden Monat "warum funktioniert mein Cron-Job nicht?" einmal :)
lg
--
t
Hallo Arno,
On 8/1/22 17:17, Arno wrote:
Also bei mir... sind 34 Stück davon. Debian Bullseye. Was auch immer
"normal" ist ;-)
(Jaja, ich geb' ja zu, dass ich den Installer ein wenig gut zureden
musste, aber nichts richtig schwieriges).
Beim booten läuft bei mir ein script. Gestartet
aus einem rc5.d/Sxx.
Da wird z.B. eine Textdatei aus dem System geparst und daraufhin
bestimmte Variablen und auch Pfade gesetzt.
Diese werden dann im weitere Verlauf genutzt und zu verschiedenen
Aktivitäten führen. Soweit so normal.
..ooOO(Hmm, anno 2022 sind sh-Skripte in rc5.d/Sxx nicht mehr sooo normal,
oder? :-) Hierzu wurde ja schon einiges beigetragen. Mein Reflex
wäre ein Skript, das
die beschriebene Komplexität erreicht hat, in was anderem als plain Shell zu
schreiben. Ich würde vermutlich Python bevorzugen, aber je nach Gusto gibt
es ja viele weitere Möglichkeiten (Perl, Bash, Node, rust, C, ...).
Ich habe dazu eine Schwelle, die bei ungefähr (sehr ungefähr) 200 Zeilen
liegt. Wobei ich erst versuche, das Skript kleiner zu machen :)
Erschwerend
kommt hinzu, dass das ganze während des Bootens passiert,
also nicht aus einer klassischen shell heraus.
Was ist der relevante Unterschied
zwischen einem Skript, das von init
aufgerufen wird und einer "klassischen Shell"? 
6:39 a.m.
Hallo Arno,
im Prinzip wurde ja schon alles irgendwie gesagt.
Aber ich möchte dir noch sagen wie ich so etwas immer mache.
Ich habe zb ein Datei mit den Variablen mein.env
In mein.env steht zB
value1=10
value2=20
...
und ich habe eine Datei my_funcs.sh:
function hello
{
echo "Hello"
}
...
und in meinem Haupt script sieht das dann so aus:
#!/bin/sh
. /path/to/mein.env
. /path/to/my_funcs.sh
do something
Hier sind jetzt meine Variablen und auch meine Funktionen bekannt
ich hoffe das ist jetzt etwas klarer für dich.
Viele Grüße
Toby
Am 01.08.22 um 17:17 schrieb Arno:
Beim booten läuft bei mir ein script. Gestartet aus
einem rc5.d/Sxx.
Da wird z.B. eine Textdatei aus dem System geparst und daraufhin
bestimmte Variablen und auch Pfade gesetzt.
Diese werden dann im weitere Verlauf genutzt und zu verschiedenen
Aktivitäten führen. Soweit so normal.
Jetzt ist mein script schon etwas länglich geworden und es droht die
Übersicht verloren zu gehen. Also hab ich es in Funktionen aufgeteilt.
Damit wird das script aber nicht kürzer. Das ganze möchte ich etwas
wartungsfreundlicher und lesbarer gestalten.
Ideal wäre ein einem Startscript die Variablen/Pfade zu setzen und dann
bestimmte Unterscripts zu starten. Was aber dabei ein Problem zu sein
scheint:
a) die Variablen vom Startscript übernehmen
b) Variablen im Idealfall auch noch von Unterscript zu Unterscript
weiterreichen
Erschwerend kommt hinzu, dass das ganze während des Bootens passiert,
also nicht aus einer klassischen shell heraus. Ich meine, das nicht mal
a) da so ohne weiteres geht. Oder gibt es da Tricks? Ich hab nicht so
viel sinnvolles dazu gefunden oder ich hab nicht die richtigen keywords
dazu.
Zusatzfrage:
Wenn ein Script wie meines gerade aus Funktionen besteht:
Am Ende der Funktionsdefinitionen werden die aufgerufen.
Kann man z.B. zum Testen, diese Funktionen (aus einer echten) Shell auch
einzeln aufrufen?
Also nur einzelne Funktionen um das Step by Step zu testen. Wie gesagt,
die Pfade/Variablen müssen gesetzt bleiben, sonst ist es sinnlos.
Bei läuft dann immer nur das ganze Script...
Wenn ich das richtig verstanden hab, kann man nur dann einzelne
Funktionen eines scripts aufrufen, wenn es kein "main" gibt, also
sozusagen nur Funktionen. Ist das wahr?
Schöne Woche,
Arno
631
days inactive
633
days old
8 comments
5 participants
participants (5)
-
Arno -
Stefan Ziegler -
Toby -
tomas＠tuxteam.de -
Uwe Kleine-König