@eisbaerin:
- Ohne Leerzeichen.
- copy_binaries ist am Anfang ja eher unabsichtlich dort hinein geraten ... ist ja auch "keine große Kunst", was es macht. Es fehlt(e) lediglich ein "Schlüsselwort" am Beginn der Datei, jetzt ist es drin.
- Generell stimmt bei Dir dann der Zeichensatz im Terminal nicht ... ich würde auf "ISO" bei Dir tippen, während die FRITZ!Box (seit einiger Zeit) mit "UTF-8" auf der Console arbeitet. Bei mir sieht es "richtig" aus:
Code:
Die Modifikation 'own files' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... nicht unterstützt
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... nicht unterstützt
Mit der "Umschreibung" von deutschen Umlauten habe ich mein halbes Leben lang gearbeitet (ich habe einen im Nachnamen und schreibe das in Benutzernamen immer noch als "ae"), aber irgendwann muß sich auch mal die Benutzung der "neuen Zeichensätze" (die gibt es ja erst seit 20 Jahren -
RFC 2044 - und länger) in der Praxis niederschlagen. Daher werde ich eher nicht auf die Benutzung von UTF-8 verzichten, selbst wenn es auch mich immer wieder bei der Bearbeitung solcher Dateien auf verschiedenen Plattformen zu erhöhter Aufmerksamkeit nötigt - es ist meist nur eine Einstellung beim Benutzer und es gibt noch viele andere Stellen, wo eine falsche Darstellung ebenfalls Auswirkungen hat, z.B. bei den ganzen "line drawing characters", auch wenn die heute nur noch selten zu sehen sind für die Benutzer von graphischen Oberflächen. Trotzdem führt für die Benutzung eines Terminalprogramms meist kein Weg daran vorbei und die richtige Darstellung der "modfs"-Nachrichten fällt dann automatisch mit ab.
@andiling:
Danke für den Zuspruch.
Das Problem des FTP-Clients bei Windows ist mir bewußt (habe ich schon selbst genug drüber geschrieben), ich sehe aber auf einer "Standard-Installation" von (neueren) Windows-Versionen keine denkbare Alternative, die nicht erst eine Nachinstallation erfordern würde.
Der Telnet-Client, der bei früheren Versionen noch automatisch installiert wurde, ist zwar nach wie vor verfügbar, aber m.W. spätestens seit Windows 8 nicht mehr dabei bei der Standardauswahl (ich würde sogar sagen, daß das schon seit Windows 7 so war, aber so wichtig, daß ich da nachsehe, ist es mir auch wieder nicht).
PuTTY (ich nehme immer den Fork "KiTTY" - falls den jemand nicht kennt, kann ich nur dem regelmäßigen Benutzer eines SSH-/Telnet-Programms unter Windows den einen oder anderen Blick empfehlen, da werden für Windows-Nutzer sinnvolle Erweiterungen eingebaut und dafür die Kompatibilität mit anderen Plattformen eingeschränkt) bietet keinen FTP-Modus und ist - zumindest wenn man ansonsten mit SIAB arbeitet bei der Ausführung von "modfs" - auch nicht zwingend bereits auf dem eigenen Windows-System installiert - damit könnte man auch wieder eine Telnet-Session zum Port 21 benutzen.
Solange es eben nur um die schnelle Umschaltung geht, funktioniert der Windows-Client ja problemlos und da würde ich Ausführungen zu den Defiziten des Windows-FTP-Clients jetzt auch unangebracht finden bzw. weitreichendere Optionen, welche Alternativen man installieren könnte/sollte, zögern den angestrebten Erfolg (die Umschaltung) dann nur weiter hinaus.
Genau deshalb habe ich die Alternativen mit "nc" und "socat" aufgeführt für die anderen Plattformen, weil so ein Kommandozeilen-FTP-Client wiederum nicht unbedingt zur Standardauswahl an Software auf anderen Plattformen zählt. Die FRITZ!Box selbst (falls man mehrere davon hat) enthält zwar die Applets "ftpget" und "ftpput", aber (ohne Modifikationen) keinen Client für den "Dialog" und ist damit an der Stelle mit "ftp" auch nicht benutzbar und auch meine STB (Linux-basiert) ist zwar mit einer Kommandozeile gesegnet, hat aber keinen FTP-Client an Bord (sie braucht ganz einfach keinen im normalen Betrieb). In Zukunft wird zwar auch die Waschmaschine (oder das Lego-Spielzeug) irgendein "embedded system" verwenden, was man für diese Zwecke nutzen könnte, aber da wird auch nicht immer (hoffentlich) ein FTP-Client dabei sein. Ich hatte sogar schon darüber nachgedacht, bei der Verwendung einer "bash" als Shell die Nutzung von /dev/tcp kurz anzureißen, denn dann braucht man praktisch gar nichts anderes mehr als diese Shell. Wenn das bei "ash" nur im Ansatz funktionieren würde, wäre das dem Leser auch nicht erspart geblieben, aber die meisten "embedded systems" setzen eben eher auf die Busybox und nicht auf eine "ausgewachsene" bash-Version.
Eine (meist ja ohnehin erst bei akutem Bedarf gelesene) Anleitung, die dem Leser mit einem nicht funktionsfähigen Router den Download und die Installation eines Programms aus dem Internet nahelegt, halte ich einfach für wenig hilfreich (die meisten sind dann im "MacGyver"-Modus und suchen irgendetwas, mit dem sie sich kurzfristigen Erfolg vorstellen könnten) und solange es eben anders geht, ist KISS an dieser Stelle nach meiner Meinung besser. Einer meiner Hauptkritikpunkte am jetzt obsoleten ruKernelTool (für den hier diskutierten Zweck) ist ja genau dessen "Verfallsdatum" (neben dem "closed source"-Ansatz) und die daraus entstehende Notwendigkeit, nach Murphy immer genau im falschen Moment erst darüber nachdenken zu müssen, wo man nun das passende Programm herbekommt. Die Frage, wie man dann die Datei BOOTSELECTION.ger liest, wenn die nur auf dem nun nicht mehr funktionierenden Router ausgepackt wurde, kann ich aber auch nicht beantworten ... vielleicht sollte der Hinweis, daß man sich diese vor jeder eigenen Aktion irgendwo abspeichern sollte, noch mit in die Anleitung hinein (auch wenn das als "Disclaimer" wenig hilfreich ist und die Erfahrung (zumindest meine) zeigt ja leider auch, daß "Vorbereitung" eher seltener anzutreffen ist - es wird schon irgendwie alles klappen, geht bei anderen ja auch :mrgreen
.
