Wenn die Funktion innerhalb der .sh aufgerufen wird, muss die Datei irgendwie "eingebunden" werden!?
Die shell muss die Funktionen aus der Datei ja alle irgendwie schon kennen - wie wird das gemacht?

Ich denke ich kann den Ablauf des reconnects jetzt theoretisch nachvollziehen.
Aus irgend einem Grund werden sämtliche "print" Anweisungen nicht ausgegeben.
Kann es sein, dass die Paramterübergabe von

reconnect "Manuell" 1 1

nicht funktioniert? Wie debugged man sowas?

Ins log wird von der reconnect() nichts geschrieben - ist so vorgesehen.
In der Datei

\log\reconnect.log

werden aber die Verbindungen geloggt. Der Teil ist ziemlich am Ende der Funktion, daraus folgere ich,
dass die reconnect() bis zum Ende durchläuft.

Im Verlauf von reconnect() wird jedoch auch die voipcheck() aufgerufen. D.h. auch bei manuellem Auslösen sollte
ein laufendes VoIP Gespräch nicht unterbrochen werden.

Das if ! kehrt den Rückgabewert der reconnectEnabled() um?
Wird da implizit ein positives Ergebnis erwartget? Anders macht der Ausdruck irgendwie keinen Sinn.

Schau dir an, was reconnectEnabled() zurückgibt. Eine Funktion kann etwas zurückliefern, muss aber nicht immer nicht einen Rückgabewert haben.
In diesem Fall kommt von reconnectEnabled() entweder "0" oder "1" - je nach den Ergebnissen innerhalb der Funktion.

http://openbook.rheinwerk-verlag.de/she … ammierung/ kann ich als Einstieg sehr empfehlen.

Oder anders gefragt, wird mit

reconnect "Manuell" 1 1

die reconnect.sh aufgerufen oder nur die Funktion innerhalb der reconnect.sh?

Damit wird die Funktion reconnect aufgerufen, die in der lib/reconnect.sh definiert wurde.

Wenn der die Funktion reconnectEnabled ein negatives Ergebnis ausgibt, wird abgebrochen und damit der Reconnect nicht durchgeführt.

return 0

beendet die Funktion und gibt einen positiven Rückgabewert zurück.
Jeder andere Returncode entspricht einem negativen Ergebnis.

Verständlich, aber wird die Datei dann von oben nach unten ausgeführt oder wird nach dem Abarbeiten der Funktion, hier reconnect(),
beendet?

Oder anders gefragt, wird mit

reconnect "Manuell" 1 1

die reconnect.sh aufgerufen oder nur die Funktion innerhalb der reconnect.sh?

Hiermit wird also die reconnectEnabled() mit den Parametern 1 1 aufgerufen?

if ! reconnectEnabled $forceReconnect $showMsg;

Das if ! kehrt den Rückgabewert der reconnectEnabled() um?
Wird da implizit ein positives Ergebnis erwartget? Anders macht der Ausdruck irgendwie keinen Sinn.

if ! 1 (oder wie?)

Ich hätte da einen Vergleich erwartet so a la

if 1=1; then ...

Diese Zeile verstehe ich nicht.

if ! reconnectEnabled $forceReconnect $showMsg; then

Die Funktion reconnect Enabled ist erst weiter unten!? Wir die hier aufgerufen und ausgeführt?

Danke für die Aufklärung!

Dafür sind ja Funktionen gedacht. Damit man sie an anderer Stelle aufrufen kann.
Stell dir den Spaghetti Code vor, wenn du bei jeder Funktionalität alles immer wieder neu schreiben musst.
Deswegen werden Bereiche, die man möglicherweise wieder benötigt, in Funktionen ausgelagert.

Wo die Funktion implementiert ist, ist von Programmiersprache zu Programmiersprache verschieden.
In Bash Scripts kann die unterhalb im File stehen und trotzdem oberhalb aufgerufen werden.

Plain old C erlaubt das z.B. nicht.

Funktion:

reconnect() {

	local showMsg="${1:--}" forceReconnect=${2:-0} showMsg=${3:-0}

Lokale Variablendeklaration
1: 2: 3: sind dabei willkürlich gewählt und werden von dem Parameter mit dem die Funktion aufgerufen wird überschrieben?
Unser Beispiel

"Manuell" 1 1

Dann folgt

	if ! reconnectEnabled $forceReconnect $showMsg; then

Auf Deutsch:

wenn nicht reconnectEnabled 1 1 dann

dann nochmal, abhängig von der showMsg Variable eine Nachricht ausgeben und return 1.
   

 [ ${showMsg:-0} -ne 0 ] && print "Die erneute Verbindung wurde nicht ausgeführt, weil Einstellungen oder Signaldateien (laufende Download-Prozesse) dies verhindern..."
    return 1
  fi 

Diese Zeile verstehe ich nicht.

if ! reconnectEnabled $forceReconnect $showMsg; then

Die Funktion reconnect Enabled ist erst weiter unten!? Wir die hier aufgerufen und ausgeführt?

Danke für die Aufklärung!

local showMsg="${1:--}" forceReconnect=${2:-0} showMsg=${3:-0}

Das erste showMsg ist in "", die sind irgendwie nicht gleich.

Das ist unerheblich, da links vom '=' der Variablenname festgelegt wird und der ist ident.

Möglicherweise reicht bereits meine Änderung zu einem anderen Variablennamen.

"Manuell" 1 1

ausgeführt wird.
Nun, es ändert nichts. Reconnect wird erfolgreich durchgeführt, keine weitere Ausgabe wie sie in der reconnect.sh eigentlich hinterlegt sind.
Irgendwo nimmt er immer noch die Abkürzung...

local showMsg="${1:--}" forceReconnect=${2:-0} showMsg=${3:-0}

Das erste showMsg ist in "", die sind irgendwie nicht gleich.

@Chefi
Die voipcheck.lua funktioniert auf der 7490. 

Das eine ist eine Funktion, das andere ist ein File. Du kannst kein Scriptfile per se so aufrufen, wenn das File mehrere Funktionen erhält.
Das sind Programmier Grundlagen - das aber nur so beiseite.

Irgendwo sagte ich ja bereits, dass das nicht so mein Metier ist 
Ich bemühe mich zwar, aber bin da nur Teilzeitsportler. Vielleicht kannst Du ja etwas helfen?

Der Auslöser ist in der

FritzLoad\cgi\gui_reconnect_do.cgi

und lautet:

#!/bin/ash
INSTANCE_BASE_LINK=gui_download.cgi
. ./gui_main.cgi
cd $pdir/bin

echo "<pre class=msg>Sende die Neustartanweisung...";
./reconnect 0
echo "</pre>"
PAGEEND 

Ist damit nicht die Datei

\FritzLoad\bin\reconnect (ohne Endung)

gemeint? Das ist eine Funktion. Wußte nicht, dass man die einfach so ablegen kann. Welcher Teil in der Funktion verarbeitet den Parameter "0" (sehe nicht wer den auswertet).

/bin/reconnect 0

Die Funktion prüft dann ob irgendwelche reconnects bereits laufen und startet am Ende

reconnect "Manuell" 1 1

Ist dann damit die

FritzLoad\lib\reconnect.sh

gemeint? Ansonsten bin ich hier auf dem Holzweg. Und was die Übergabe von "Manuell" 1 1 angeht sowieso.
Da sind dann weiter Prüfungen und irgendwo auch die Funktionen

doReconnect(){

und im weiteren Verlauf auch

upnp_reconnect(){

Wobei ich mir bei dieser upnp_reconnect nicht sicher bin ob das schon der reconnect-Befehl ist (den Inhalt des curl aufrufes verstehe ich nicht), denn vom Ablauf her ist die Funktion zu früh dran.

Danke für die Aufklärung! 

Dort wird

/bin/reconnect 0

aufgerufen - das ist echt madig. Und ohne jeglichen Kommentar ins log usw.
Warum wird da nicht die

/lib/reconnect.sh

aufgerufen?
Offensichtlich sind ja beide Skripte lauffähig! Gibt's da einen technischen Grund?

Das eine ist eine Funktion, das andere ist ein File. Du kannst kein Scriptfile per se so aufrufen, wenn das File mehrere Funktionen erhält.
Das sind Programmier Grundlagen - das aber nur so beiseite.

EDIT: Das obige ist nicht falsch, aber man sollte sich doch den Code genau ansehen, bevor man was postet *hüstel* (auf mich bezogen).
Warum das so gelöst worden ist, erschließt sich mir jetzt auch nicht, es wird aber seine Gründe gehabt gehabt haben ... hoffentlich

Das entscheidende passiert im File "reconnect" (OHNE Endung) hier:

reconnect "Manuell" 1 1

Das ruft dann in der reconnect.sh die Funktion reconnect() auf:

reconnect() {
	local showMsg="${1:--}" forceReconnect=${2:-0} showMsg=${3:-0}
...
}

Und damit sollte als Message "Manuell" angezeigt werden und/oder ins Log gehen, forceReconnect erhält eine "1" und ebenso bekommt der dritte Parameter eine "1" - damit die Message eben angezeigt wird.

Und wenn ich das jetzt sehe, dass zweimal die gleiche Variable angelegt wird (showMsg) aber unterschiedliche Parameter erhält (einmal den ersten und einmal den dritten) dann dürfte hier schon ein Bug liegen. Unter der Voraussetzung, dass es nicht doch was zulässiges ist - ich bin kein Bash Script Experte.

EDIT_ENDE

Im gesamten Code sind sicher genug "Wanzen/nicht mehr lauffähige Teile/nicht angepasster Code" enthalten, manchmal kommt mir so vor, wenn eine Baustelle zugemacht wird, gehen zwei neue auf.

Auf den Switch "Erneut verbinden:" hab ich noch nie geklickt, ich sehe erst jetzt, dass da was dahinter steckt und nicht nur beim aktiv/inaktiv Switch daneben.

Zusammengefasst ist das Problem jetzt folgendes:
Beim Klick auf "Erneut verbinden" wird ein Reconnect eingeleitet und die Prüfungen wie beim automatischen Aufruf finden nicht statt

Falls ja, glaube ich, daß dass immer so war, denn der Code hier wurde mWn schon lange nicht mehr verändert.
Außerdem denke ich soll ja ein Reconnect erzwungen werden, deswegen wurde das so erst implementiert.

Es kann aber auch ganz anders sein, nur ob wir das je erfahren ...

/bin/reconnect

abgearbeitet ist, ruft die wiederum eine

reconnect "Manuell" 1 1

auf. Die Übergabe von "1 1" ist vermutlich der Schlüssel. Da werden die Prüfungen auf irgendwas gleich gültig gesetzt.
Wenn man die vielleicht wegläßt läuft vermutlich der normale Prozess ab.
Könnte man ruhig im log was ausgeben oder gleich auf der GUI.

Die .lua habe ich noch nicht ausprobiert - war schon spät gestern nach all dem Testen.
Vielleicht schaffe ich es heute Abend.
Oder ich tune mal eben diese beiden 1er weg und schau ob es pfeifft. 

Ich habe das nochmal gelesen was du da gschrieben hast, und wenn ich mal so drüber nachdenke dann irgnoriert der Klick auf erneut verbinden die aktivierten Checks. Die Mac/und voip checks laufen nur bei eineim automatisiertem Reconnect.

Dürfte aber nicht sein, bzw. das war mal anders.
Ich blicke leider nicht durch die Struktur des gesamten Programms - was wen wann aufruft etc.
Dieser Mix mit den .cgi Dateien die dann Teils doch shell-skripte sind und dann wieder doch nicht...harter Tobak - echt.
Aber ich meine ich konnte das Problem lokalisieren in der Datei

/cgi/gui_reconnect_do.cgi

Dort wird

/bin/reconnect 0

aufgerufen - das ist echt madig. Und ohne jeglichen Kommentar ins log usw.
Warum wird da nicht die

/lib/reconnect.sh

aufgerufen?
Offensichtlich sind ja beide Skripte lauffähig! Gibt's da einen technischen Grund?
Klärt mich gerne auf!