[Problem] AVM überschreibt 6.60 freetz Version mit 6.60

Ich vermute mal, daß da physikalische Interfaces im Einsatz sind ... dann schalte einfach im Skript die Validierung des Interfaces ab und gut ist's ... das braucht ohnehin nur das intern verwendete "eva_discover" zum Senden der Broadcasts.

Folgendes sollte schon funktionieren (ungetestet allerdings):
Code:
diff --git a/eva_tools/eva_discover b/eva_tools/eva_discover
index ff0db8c..53c67da 100755
--- a/eva_tools/eva_discover
+++ b/eva_tools/eva_discover
@@ -231,8 +231,8 @@ while [ ${#1} -gt 0 ]; do
        shift
        case "$name" in
                INTERFACE)
-                       default_interface="$(check_parameter "$name" "$value" bind_to_interface 0 validate_interface)"
-                       [ $? -ne 0 ] && exit 1 || bind_to_interface=1
+                       default_interface="$value"
+                       bind_to_interface=1
                        ;;
                FROM)
                        default_local_ip="$(check_parameter "$name" "$value" bind_to_address "unused" validate_ipv4_address)"
 
Habe jetzt die 2 Zeilen geändert

./eva_discover: 316: [: xunused: unexpected operator
./eva_discover: 368: [: xunused: unexpected operator
./eva_discover: 84: [: L: unexpected operator
./eva_discover: 84: [: L: unexpected operator
./eva_discover: 84: [: L: unexpected operator
./eva_discover: 80: [: L: unexpected operator
./eva_discover: 80: [: B: unexpected operator
./eva_discover: 84: [: L: unexpected operator
./eva_discover: 402: ./eva_discover: Bad substitution
 
Falsche Shell ... Standard-Shell auf "bash" setzen.
 
ups mein fehler: The value 'eno1' specified for 'INTERFACE' is invalid.
 
Also sollte damit wunderbar gehen.
Was macht jetzt den Unterschied zwischen ruKT und AVM-Recovery aus, wenn letzteres nicht funktionieren will? Das mag an dem Windows-System liegen ... aber wieso sollte das ruKT jetzt nicht dasselbe Problem haben bzw. erst noch mehr an der IP-Konfiguration verstellen wollen (Stichwort "media sense"?) - samt Neustart?

- - - Aktualisiert - - -

@JokerGermany:
Bei der Änderung bist Du Dir sicher? Eigentlich sollte die einzige Stelle, die zu diesem Fehler führt, bereits geändert sein.

Das "if" in Zeile 316 wird nicht ausgeführt, weil "bind_to_interface" auf 1 gesetzt wurde und das "elif" in Zeile 368 auch nicht, weil "bind_to_address" nicht "unused" "change_eva_ip" nicht 0 sein dürfte (ist das Ergebnis von "TO" und das steht in "eva_switch_system").

Ich wüßte im Moment nicht, wie er zu diesem Fehler finden sollte.
 
Zuletzt bearbeitet:
Vielen Dank an alle für Eure Hilfe.
Der Trick von HabNeFritzbox mit dem rkT hat funktioniert...
Warum auch immer die recover methode nicht funktioniert hat.
Die OpenVPN Verbindung steht wieder.

Wie knebel ich jetzt die Fritzbox so, dass sie nicht mehr versucht sich selbst zu updaten?
Weil der Haken "Automatische Updates zulassen Ist diese Einstellung ausgewählt, kann der Dienstanbieter das FRITZ!OS dieses Gerätes bei Bedarf automatisch aktualisieren, um das Dienstangebot zu verbessern."
War rausgenommen???
Was kann dazu geführt haben, dass sich die Fritzbox selbst geupdatet hat?
Muss ich die anderen beiden Haken bei den Diensteanbietern auch rausnehmen?

Was passiert wenn die Fritzbox neu gestartet wird, bleibt das jetzt erstmal so gesetzt?

@Script:
Schaue mir nochmal morgen alles ganz in ruhe an und melde mich dann bei dir PeterPawn.

- - - Aktualisiert - - -

hab jetzt "Über neue FRITZ!OS-Versionen informieren und notwendige Updates automatisch installieren (Empfohlen)" in "Über neue FRITZ!OS-Versionen informieren" geändert.

Meine Fresse, der ganze Tag dahin, so viel zum "Lerntag" -__-
 
hab jetzt "Über neue FRITZ!OS-Versionen informieren und notwendige Updates automatisch installieren (Empfohlen)" in "Über neue FRITZ!OS-Versionen informieren" geändert.
Und dabei müßte die erste Einstellung ja auch reichen und das gleich aus zwei Gründen ... wenn da schon eine 06.60 drauf war (egal ob Freetz oder nicht), dann sollte da ja schon mal keine neuere Version signalisiert werden und erst recht keine, die als "notwendiges Update" gekennzeichnet ist.

Entweder AVM mauert da bis zum Erbrechen (hier gehen ja inzwischen rundherum irgendwelche automatischen Updates los) oder man hat einfach den eigenen Mechanismus zur Signalisierung nicht mehr im Griff bzw. diese ganzen "Nur benachrichtigen"-Einstellungen niemals bei der Einführung in der 06.20 wirklich auf Herz und Nieren geprüft - das letztere erscheint mir irgendwie am einleuchtendsten, wenn man sich andere Klopse so ansieht.
 
Keine Ahnung, ich hoff es ist nicht das mauern.
Bekommt man auf die neuen Fritzboxen eigentlich Freetz oder ist da durch die Signierung Schicht?

Ich hätte einfach nicht den fehlgeschlagenen Update Vorgang ignorieren sollen.
18.11.2016 04:14 schrieb:
Das FRITZ!OS Ihrer FRITZ!Box 7490 [FB7490-Musterdorf] wurde nicht aktualisiert.
Das Update wurde vom Hersteller der FRITZ!Box als notwendiges Update für den sicheren und zuverlässigen Betrieb gekennzeichnet. In Ihrer FRITZ!Box ist eingestellt, dass solche notwendigen Updates automatisch installiert werden sollen.
Hinweis:
Während des Updates ist ein Fehler aufgetreten. Zu einem späteren Zeitpunkt wird das Update erneut gestartet. Optional können Sie die Installation des Updates auch über das Menü "System / Update / FRITZ!OS-Version" starten. Sollte der Fehler weiterhin auftreten, kontaktieren Sie bitte den AVM-Support

Dachte, wenn er sowieso fehlgeschlagen ist, wird er nicht ohne meine Mithilfe gelingen...

und dann heute um 3:44:
Das FRITZ!OS Ihrer FRITZ!Box 7490 [FB7490-Musterdorf] wurde erfolgreich aktualisiert.
Das Update wurde vom Hersteller der FRITZ!Box als notwendiges Update für den sicheren und zuverlässigen Betrieb gekennzeichnet. In Ihrer FRITZ!Box ist eingestellt, dass solche notwendigen Updates automatisch installiert werden sollen.
Aktuell verwenden Sie die FRITZ!OS-Version: 06.60
Wichtige Informationen und Neuigkeiten zum neuen FRITZ!OS
Neue Features

  • WLAN: NEU - FRITZ!Hotspot: der WLAN-Gastzugang mit Zusatzfunktionen für Café, Laden oder Praxis: Vorschaltseite mit eigenem Logo, Text und Link auf eigene Homepage
  • Internet: Verbesserung - schneller Surfen durch optimierte Behandlung von DNS-Anfragen
  • Telefonie: Verbesserung - höhere Sprachqualität bei Internettelefonie durch verzögerungsarme Sprachübertragung
  • Telefonie: Verbesserung - schnellerer Verbindungsaufbau bei Internettelefonie bei gleichzeitiger Datenübertragung
  • Telefonie: Verbesserung - höhere Sprachqualität bei Internettelefonie auch bei gleichzeitiger Datenübertragung beim Anbieter Deutsche Telekom
  • Mediaserver: Verbesserung - MagentaCLOUD als Quelle für den FRITZ!Mediaserver unterstützt (ehemals T-Mediencenter)
Diese E-Mail wird nach jedem Updatevorgang automatisch an den Absender des Push Services bzw. den Empfänger des Push Services "Neues FRITZ!OS" versendet. Sollten Sie diese E-Mail nicht weiter erhalten wollen, so deaktivieren Sie den Push Service in Ihrer FRITZ!Box.
 
... wenn da schon eine 06.60 drauf war (egal ob Freetz oder nicht), dann sollte da ja schon mal keine neuere Version signalisiert werden und erst recht keine, die als "notwendiges Update" gekennzeichnet ist.
Jetzt wäre mal interessant ob JokerGermany beim erstellen des Freetz-Images [post=2106725]"FREETZ_MODIFY_AVM_VERSION=y"[/post] gesetzt hatte oder nicht, das könnte evtl. eine Ursache sein.

Bekommt man auf die neuen Fritzboxen eigentlich Freetz oder ist da durch die Signierung Schicht?
Ersteinmal wird es daran Ermangeln, dass man für die neuen Modelle noch keine (funktionierenden) Freetz-Images bauen kann. Aber wenn dieses Problem irgendwann einmal aus der Welt geschafft sein sollte (es muss allerdings auch kein Freetz-Image sein) könnte ich mir 2 Wege vorstellen (ohne die Box zu öffnen), 1. per Bootloader oder 2. per "Entwicklerversion" die man ebenfalls vom AVM-Server herunterladen und normal über das WebIf aufspielen kann, die Entwicklerversionen enthalten noch einen Konsolenzugriff (Telnet/Shelina) über den dann das Einspielen eines unsignierten Firmwareimages noch möglich ist. Ist dann einmal eine entsprechend modifizierte Firmware aufgespielt sollten weitere Firmware-Updates mit modifizierten Images kein Problem mehr darstellen.
 
Keine Ahnung, ich hoff es ist nicht das mauern.
Wenn das so in der Mail steht, muß das ja aus irgendeinem Grund (die 06.60 gibt es seit Anfang Juli schon) inzwischen auf "notwendiges Update" heraufgestuft worden sein.

Und wenn das so sein sollte, dann müßte es irgendeine bisher verschwiegene Sicherheitslücke geben, die weder in der von Dir zitierten Übersicht (und die ist "live" vom Hersteller und nicht aus der Image-Datei) noch in der Öffentlichkeit bekannt geworden ist und nun die Kennzeichnung als "notwendig" rechtfertigt und vor allem eine, die in der 06.60 bereits beseitigt wurde vor mehr als vier Monaten (nicht im "Changelog" aufgeführt ist - wenn man das überhaupt so nennen kann) und bisher wurde es trotzdem nicht für nötig gehalten, diese Lücke durch die Installation dieses Updates schon früher zu schließen.

Vor allem dann, wenn man noch die Besonderheit bei Dir berücksichtigt, daß es (a) überhaupt nichts mit 1&1 zu tun hat (das ist ein reiner Herstellermechanismus und es wird ein AVM-Server abgefragt) und es sich (b) um genau die bereits installierte Version 06.60 handeln soll, wenn man dem "Waschzettel" und Deinen Threadtitel glauben will.

Das meinte ich dann mit "AVM hat das nicht mehr im Griff" - denn diese Einordnung der Updates darf man zweifellos vornehmen ... dann fehlt aber die "öffentliche Bekanntmachung" für die Kunden, die bei sich die Einstellung "nur benachrichtigen" von Beginn an verwenden, daß diese nun ebenfalls tätig werden sollten und warum das so ist. Wobei es bei der 7390 (die kennt die dritte Einstellung gar nicht) auch Berichte gibt (mich selbst hat es ebenfalls getroffen), daß die Einstellung "nur benachrichtigen" plötzlich und unerwartet auch ignoriert wurde bzw. auf "notwendige Updates installieren" geändert wurde, wie man der unmittelbar vor dem Updateversuch gestarteten Sicherung entnehmen kann.

Die nunmehr bei Dir installierte Version 06.60 (die Mail spricht von "wurde aktualisiert" und "Aktuell verwenden Sie") wurde bereits am 06.07.2016 veröffentlicht und wird seitdem bei jedem Update als "neue Version, aber nicht notwendig" signalisiert - warum hat sich jetzt plötzlich und unerwartet der Status dieses Updates auf "notwendig" geändert?

Ganz ehrlich ... wenn ich die Schlußfolgerungen, die man aus einer absichtlichen "Heraufstufung" ziehen muß (alternative Antworten auf die aufgeworfenen Fragen würden mich sehr interessieren), mit der Erklärung "Chaos und man hat es nicht mehr im Griff - gerade durch die Arbeiten am Update-Info-Service, wo die alten Versionen ja noch den alten 'jason'-Service verwenden dürften" vergleiche, dann wäre mir letzteres tatsächlich lieber ... Fehler können passieren und das wäre mir angenehmer als wenn AVM hier wieder den Kunden (zumindest einige) "dumm sterben" läßt mit einer aktuell ausgenutzten Lücke und nach den zwei jüngsten Problemen (einem Skandal (DOCSIS-Mfg-Cert) und einem ausgesessenen Problem (TLD "box" geht in Betrieb)) hätte man dann gleich wieder das dritte an der Backe.

- - - Aktualisiert - - -

@qwertz.asdfgh:
Das kann man ja mit dem Skript für den alten Service prüfen, wie die Antworten mit einem "M" am Ende der "subversion" variieren. Da das eigentlich bei AVM-Spezialversionen auch so war (daher wurde das ja übernommen, soweit ich weiß), wäre es ja immer noch ein Fehler, wenn der Service dort enthaltene Buchstaben nicht entfernt vor einem Vergleich.

Zumal ich bei mir auf der 7390 wieder ausschließen kann, daß die "subversion" überhaupt modifiziert wurde ... da war es allerdings tatsächlich eine kleinere Zahl als bei der im Anschluß installierten 06.51. Das Problem mit der "geänderten Dringlichkeit" würde bleiben.
 
Die Fritzbox stellt die "Bootpartition" erst beim Update wieder um?

@Freetz für neue Fritzboxen:
Sollte das nicht mehr möglich sein, suche ich mir nen neuen Hersteller.
Bisher hab ich mir OpenWRT noch nicht angeschaut da ich bei AVM ganz zufrieden bin, aber sollte bei der 7580 kein Freetz möglich sein, werde ich die nicht so schnell kaufen bzw. nutzen wie geplant...

Jetzt wäre mal interessant ob JokerGermany beim erstellen des Freetz-Images [post=2106725]"FREETZ_MODIFY_AVM_VERSION=y"[/post] gesetzt hatte oder nicht, das könnte evtl. eine Ursache sein.

Sollte bei mir so gewesen sein, da ich es gut finde auch die Freetz Version beim einloggen sehen zu können (Immo 06.60-freetz-devel-13905M )
Und habe gerade mal in meinen freetz-trunk Ordner gesehen und wenn es wirklich der Trunk Ordner ist von der vor 4 Monaten erstellten Version, dann steht dort deine oben genannte Option in der .config
 
Was steht denn jetzt in der "jason_boxinfo.xml", wenn die Freetz-Version inzwischen wieder läuft? Einfach "wget -qO - http://fritz.box/jason_boxinfo.xml" auslesen lassen.

Das sollten die entscheidenden Daten sein, die auch an AVM übermittelt werden bei der Suche nach einem Update.
 
Was steht denn jetzt in der "jason_boxinfo.xml", wenn die Freetz-Version inzwischen wieder läuft? Einfach "wget -qO - http://fritz.box/jason_boxinfo.xml" auslesen lassen.

Bei der betroffenen Box habe ich scheinbar das 1und1 Branding irgendwann mal entfernt:
Code:
<j:BoxInfo xmlns:j="http://jason.avm.de/updatecheck/">
<j:Name>FRITZ!Box 7490</j:Name>
<j:HW>185</j:HW>
<j:Version>113.06.60-13905</j:Version>
<j:Revision>33668</j:Revision>
<j:Serial>xxx</j:Serial>
<j:OEM>avm</j:OEM>
<j:Lang>de</j:Lang>
<j:Annex>B</j:Annex>
<j:Lab></j:Lab>
<j:Country>049</j:Country>
<j:Flag>crashreport</j:Flag>

Das hier ist meine Box die ich bei mir stehen habe:
Code:
<j:BoxInfo xmlns:j="http://jason.avm.de/updatecheck/">
<j:Name>FRITZ!Box 7490 (UI)</j:Name>
<j:HW>185</j:HW>
<j:Version>113.06.60-13905</j:Version>
<j:Revision>33668</j:Revision>
<j:Serial>xxx</j:Serial>
<j:OEM>1und1</j:OEM>
<j:Lang>de</j:Lang>
<j:Annex>B</j:Annex>
<j:Lab></j:Lab>
<j:Country>049</j:Country>
<j:Flag>crashreport</j:Flag>
 
Das Problem beim Freetz dürfte weniger die Möglichkeit der Installation einer eigenen Version auf dem Gerät werden (da findet sich immer irgendein Weg) als vielmehr die fehlende Unterstützung der 75x0-Modelle im Freetz. Die beiden basieren ja wohl auf dem GRX500, das ist wieder gesondert einzuarbeiten.

Dabei ist nicht einmal die Umstellung der VR9-Modelle so weit abgeschlossen, daß die alle einen eigenen Kernel mit 3.10 ermöglichen würden ... es gibt halt niemanden mehr so richtig, der sich kümmert und die Zeit dazu hat. Seitdem @er13 anderes zu tun hat, passiert da nicht mehr viel und er war ja auch schon längere Zeit (gewollt und was die "Basis" wie Firmware-Versionen und buildroot angeht) alleine unterwegs. Das ist halt die Gefahr, wenn so jemand dann mehr oder weniger ebenfalls ausfällt.

Auch bei der 4020 und 4040 dürfte es bisher noch düster aussehen ... aber damit beschäftige ich mich auch nicht so richtig.

Die Angabe der 13905 bei "Version" ist aber tatsächlich fragwürdig - da gehört derselbe Wert wie in "Revision" hinein (bei AVM-Firmware). Wobei das immer noch das "hochgestufte Update" erforderlich macht, denn das steht ja dann sicherlich schon länger so an dieser Stelle und das Update wurde ja vorher auch nie ausgeführt.

EDIT: Bei Release-Versionen steht bei AVM wohl bei "Version" gar kein Wert nach dem Bindestrich (der dann auch entfällt) ... ich kann mich erinnern, daß ich extra diesen Fall noch im juischeckupdate-Skript abgefangen hatte und bei fehlender Revision in "Version" den Wert aus dem Feld für "Revision" auslesen lasse.
 
Zuletzt bearbeitet:
Ich kann leider nichts zu Eurem Thema beitragen, wollte aber nur kurz loswerden, dass die 7490 bei meinen Eltern auch von 06.60-freetz auf 06.60 upgedatet wurde.

Ich hatte das Häkchen bei "Über neue FRITZ!OS-Versionen informieren und notwendige Updates automatisch installieren (Empfohlen)" stehen, habe es jetzt auf "Über neue FRITZ!OS-Versionen informieren" gesetzt. Hoffentlich hilft das gegen diese ungewollten Updates!

Beste Grüße,
Whoopie
 
Zuletzt bearbeitet:
Hallo JokerGermany,

was halten Sie denn davon, wenn Sie ein Kollege unserer Technik telefonisch kontaktiert und Sie ihn befragen können?
Eventuell können wir ja auch etwas für Sie tun. Wenn Sie mögen, dann senden Sie uns dazu bitte Ihre Kunden- und Rückrufnummer per Direktnachricht hier in diesem Forum.

Danke schön und viele Grüße
Xenia,1&1
 
@PeterPawn:
Hab jetzt das github verzeichnis nochmal komplett gelöscht und neu runtergeladen.
Den Path gesetzt.

Fehlermeldung:
eva_switch_system eno1 192.168.2.1
The value 'eno1' specified for 'INTERFACE' is invalid.

Dann habe ich die unten beschriebenen - Zeilen gelöscht und dafür die + Zeilen ersetzt. (im eva_discover script)
Code:
-                       default_interface="$(check_parameter "$name" "$value" bind_to_interface 0 validate_interface)"
-                       [ $? -ne 0 ] && exit 1 || bind_to_interface=1
+                       default_interface="$value"
+                       bind_to_interface=1

Ergebnis:
Code:
/home/simon/fritzbox/YourFritz/eva_tools//eva_discover: 316: [: xunused: unexpected operator
/home/jokergermany/fritzbox/YourFritz/eva_tools//eva_discover: 368: [: xunused: unexpected operator
/home/jokergermany/fritzbox/YourFritz/eva_tools//eva_discover: 84: [: L: unexpected operator
/home/jokergermany/fritzbox/YourFritz/eva_tools//eva_discover: 84: [: L: unexpected operator
/home/jokergermany/fritzbox/YourFritz/eva_tools//eva_discover: 84: [: L: unexpected operator
/home/jokergermany/fritzbox/YourFritz/eva_tools//eva_discover: 80: [: L: unexpected operator
/home/jokergermany/fritzbox/YourFritz/eva_tools//eva_discover: 80: [: B: unexpected operator
/home/jokergermany/fritzbox/YourFritz/eva_tools//eva_discover: 84: [: L: unexpected operator
/home/jokergermany/fritzbox/YourFritz/eva_tools//eva_discover: 402: /home/jokergermany/fritzbox/YourFritz/eva_tools//eva_discover: Bad substitution





@1und1:
Hat sich erledigt, ihr seid unbeteiligt^^
 
@JokerGermany:
Da ich überwiegend mit Systemen mit VLANs (und damit mit logischen/virtuellen Schnittstellen) arbeite, war es mir gar nicht so richtig aufgefallen, daß ich ja an der falschen Stelle im sysfs nachsehe. Der korrekte Pfad wäre /sys/class/net und da sollten dann sowohl physikalische als auch logische Interfaces zu finden sein. Nur für die Unterscheidung bei der "Technologie" (WLAN vs. Ethernet) muß ich dann woanders suchen ... daher kam das im Skript aber mal (macht halt über WLAN-Schnittstellen nur selten Sinn - da braucht es dann den AP, der mit der Box mit einem Kabel verbunden ist) und nur für das "eva_discover" brauchte ich das mit den Interfaces überhaupt.

Ich schaue mir das noch einmal gründlicher an bei Gelegenheit ... und dann korrigiere ich es ggf. gleich.

Nachdem Du ja nun Erfahrungen zur falschen Zeit gesammelt hast, bleiben die Dir ja in jedem Falle erhalten.

Das "ruKernelTool" hat in meinen Augen den Nachteil des "Verfalls" (wenn r@iner das nicht geändert haben sollte) und ist dann immer gerade im falschen Moment (mit nicht startender Box) nicht aktuell ... wenn Du Dir auf einem Windows-System eine Lösung "auf Vorrat" hinlegen willst, gäbe es auch noch dieselbe Funktionalität in Form zweier PowerShell-Skripte (die verfallen eben nicht).

- - - Aktualisiert - - -

Und Du hast offenbar wieder die falsche Shell verwendet. Du kannst natürlich auch in den "SheBangs" auf /bin/bash ändern ... auch die "ash" der BusyBox sollte funktionieren. Diese dusslige "dash" kann aber wirklich nur POSIX-kompatible Shell-Syntax und braucht an den simpelsten Stellen so viel zusätzlichen Aufwand, daß ich keinen Bock darauf habe. Notfalls ruft man es eben über "busybox sh <script>" auf - eine Box mit "PREFER_APPLETS=y" sollte dann mit der "ash" arbeiten und damit funktioniert das dann auch wieder.
 
Moins


:motz:
PeterPawn schrieb:
Und Du hast offenbar wieder die falsche Shell verwendet
Kann das SHEBANG nicht irgendwie so gestaltet werden, dass immer die richtige SHELL genommen wird?
...gesehen hab ich meist Beispiele mit env, kann mir aber statt env auch ein Skript vorstellen, welches testet und den richtigen Interpreter zurückliefert.

@JokerGermany: PeterPawn meint das hier...
Code:
 $l /bin/*sh
-rwxr-xr-x 1 root root 863400 Oct 18  2014 /bin/bash
-rwxr-xr-x 1 root root 104088 Jan 21  2014 /bin/dash
lrwxrwxrwx 1 root root      4 Jan  1  1970 /bin/rbash -> bash
lrwxrwxrwx 1 root root      4 Jan  1  1970 [color="red"]/bin/sh -> dash[/color]
 
Zuletzt bearbeitet:
@koy:
Mein Primärziel ist und bleibt immer die FRITZ!Box und zwar die mit originaler AVM-Firmware. Unter anderen deshalb baue ich eben solche Applets wie "mktemp" oder "base64" notfalls auch mit POSIX-Shell-Statements zusammen - ist zwar elendig langsam, aber es gibt eben Boxen, da gibt es kein "base64" und das leidige "mktemp"-Thema hatte ich beim Signieren der Firmware zuhauf (und beim Update-Check, wenn ich mich recht erinnere).

Auf der Box gibt es dann keine andere Shell als "ash" und zwar auch unter dem Pfad "/bin/sh", wohin dann in aller Regel die "SHELL"-Variable bereits zeigt. Das Problem ist es eigentlich, daß bei der Auswertung des SheBang (das geht bis in den Kernel-Code) keine Variablen ausgewertet werden, soweit ich weiß.

An anderen Stellen setze ich das "SheBang" auch schon mal auf /bin/false ... bei direkten Aufruf der Shell mit dem Skript als Parameter ist es ja vollkommen egal, was im "SheBang" steht - vielleicht ist das sogar wieder die bessere Lösung. Zumindest verhindert sie, daß die falsche Shell verwendet wird - braucht dann eben mehr Tipperei beim Aufruf und die Suche über den Pfad funktioniert auch nicht mehr. Da ich eigentlich wenig Lust habe, bei mir immer eine angepaßte Version zu verwenden, wenn ich die dann schon für die Veröffentlichung jeweils "aufgehübscht" habe (meist sind das ja "Ableger" anderer (interner) Hilfsmittel), werde ich vermutlich nur die README.md noch etwas ausführlicher machen ... auf den direkten Aufruf möchte ich dann doch nicht verzichten. Und bei mir gibt es die "Shell-Library" mit den "yf"-Funktionen tatsächlich in einem eigenen Verzeichnis, auf das die Variable "YF_SCRIPT_DIR" zeigt. Damit habe ich die ganzen Probleme mit Pfaden, Rechten und Shell-Varianten nicht wirklich selbst ... aber ich verstehe schon, daß es unangenehm sein kann.

Nicht umsonst macht "modfs" inzwischen sogar jeweils noch ein "respawn" und nagelt den Pfad so fest, daß die ganzen verschiedenen AVM- und Freetz-Utilities da nichts mehr zu melden haben. Das macht aber für die "eva_tools" nicht wirklich Sinn in meinen Augen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.