[gelöst] lynx Browser will nicht mehr starten

Mediaman2000

Neuer User
Mitglied seit
24 Feb 2007
Beiträge
79
Punkte für Reaktionen
0
Punkte
0
Moin

habe folgendes Problem: habe den lynx Browser in meinem dsmod installiert. Hat bis vor kurzem gut funktioniert, nur wenn ich nun lynx starten will bekomme ich nur das zu sehen:

PHP:
/var/mod/etc $ lynx
Error opening terminal: xterm.
/var/mod/etc $
Ich hatte den dsmod nachträglich nochmal kompiliert, da ich Samba hinzugefügt habe. Seitdem läuft lynx nicht mehr...
Hab ich vielleicht zufällig was nicht mit installiert beim 2. mal kompilieren, was für lynx von nöten ist? Bewusst habe ich nur Samba ausgewählt und sonst die Konfiguration unverändert gelassen.
 
Zuletzt bearbeitet:
Da fehlt offenbar das File mit den Terminaleinstellungen. Du kannst das überprüfen, indem Du
Code:
ls -lRa /usr/share/terminfo
aufrufst. Wenn da nix angezeigt wird, dann fehlen die Terminal-Infos. Du hast wirklich nur Samba hinzugewählt? Screen, MC, nano vorher drin gehabt und jetzt nicht mehr?
Edit:
Der schnelle Workaround wäre, das Paket mc mit auszuwählen und das Image neu zu bauen.
 
Zuletzt bearbeitet:
Wo soll das terminfo file denn herkommen? Im lynx package ist es zumindest nicht drin.

MfG Oliver
 
Richtig, im lynx-Makefile wird das nicht vom staging rüberkopiert. Ich überlege noch, was man anpassen sollte: das make vom ncurses und einfach die wichtigsten Terminfos per default rüberkopieren, oder ob man für jedes Paket wartet bis ein Bugreport kommt und dann selektiv jedes einzelne installiert, was vom jeweiligen Paket erwartet wird. Variante 1 scheint mir sinnvoller zu sein. Zusätzlich könnte man die exotischen Terminfos, die z.B. von Screen genutzt werden, im Screen-Makefile kopieren. (Screen hier nur als Platzhalter für alle anderes Pakete, die terminfos kopieren)
 
PHP:
/ $ ls -lRa /usr/share/terminfo
ls: /usr/share/terminfo: No such file or directory
/ $
Scheint also nicht da zu sein. Ok mc, da sagst du was, dass hab ich mit abgewählt vorm 2. kompilieren, da ich ne Meldung bekommen hatte, dass das Image zu groß werden würde. Da hab ich halt noch ein paar Sachen weggenommen, die ich ausprobiert habe aber nicht für brauchbar hielt - darunter war mc
 
Ah sorry, an die Variante, dass es vom Platz her zu knapp wird, hab ich gar nicht gedacht. Probier doch dann mal mit diesem Patch hier:
Code:
--- make/lynx/lynx.mk.orig      2007-07-29 03:12:55.000000000 +0200
+++ make/lynx/lynx.mk   2007-10-23 15:10:10.000000000 +0200
@@ -80,6 +80,9 @@
        touch $@

 $(LYNX_TARGET_BINARY): $(LYNX_BINARY)
[b]+       mkdir -p $(LYNX_TARGET_DIR)/root/usr/share/terminfo/{l,x}
+       cp $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/share/terminfo/x/xterm \
+               $(LYNX_TARGET_DIR)/root/usr/share/terminfo/x/[/b]
        $(INSTALL_BINARY_STRIP)

 $(LYNX_TARGET_CFG): $(LYNX_CFG)
Ich werd's dann auch im SVN für die kommenden Releases ändern.
 

Anhänge

  • lynx-terminfo.patch.bz2
    303 Bytes · Aufrufe: 2
Zuletzt bearbeitet:
Danke schonmal, werd ich heut abend testen - nur ne kurze Frage, da ich ein Neuling in Sachen DSmod bin, wo muss ich den Patch einfügen?
 
Wäre es nicht besser, ein extra Paket "terminfo" zu haben, also das in alle Pakete, die es brauchen könnten, mit aufzunehmen?
Und was ist mit denen, die nicht "xterm" als Terminal haben?
 
Jein. Meines Wissens gehört die Terminfo-Datenbank zu ncurses dazu. Von dort werden die nötigen Files ja auch in das Staging-Directory installiert. Vom Staging-Directory kopiert zur Zeit noch jedes Paket, was bisher gemeckert hat, die jeweiligen Files in sein Paketverzeichnis, so dass diese schlussendlich im Image landen. Im Prinzip würde ich also sagen, dass die ncurses-Lib auch dafür zuständig ist, diese Files bereitzustellen. Als ich vorhin mal ein "du -s ..." über /usr/share/terminfo gejagt habe, war das mit ca. 6 MB bloß "ein bisschen" zu groß für die FBen. Daher würde ich die folgende Auswahl treffen: xterm, linux, putty, ansi, dumb und vielleicht noch ein paar Variationen davon. Welches Terminfo genutzt wird, wird doch über die Env-Variable "TERM" festgelegt, oder? Im dsmod wird die irgendwo auf "xterm" gesetzt, wobei ich nicht sicher bin, ob das so sein sollte: "linux" wäre meines Verständnisses nach die richtige Variante. Zugegeben, ich kenn mich da jetzt nicht soo im Detail aus. Aber im Prinzip gibts ja nur die serielle Konsole, Telnet und SSH-Verbindungen. Die letzten beiden können von welchem OS auch immer kommen, ich weiß nicht, inwieweit das dann noch zu berücksichtigen ist.
 
Es ist nicht richtig, TERM grundsätzlich auf linux zu setzen. TERM sagt ja nichts über den Rechner oder sein Betriebssystem aus, sondern über das Terminal, an dem der Benutzer sitzt. Korrekt ist es also, das zu übernehmen, was das Client-Programm des Benutzers (telnet, ssh) angibt.

Da die vollständige terminfo mit 6MB zu groß ist für die Box, ist es sinnvoll, sich auf die gängigen Terminals zu beschränken. Dazu kann man entweder eine gängige Auswahl treffen, oder Terminals über die Konfig anbieten. Komfortabel wäre es, wenn man in der Konfig die Namen von (zusätzlichen) Terminals angeben könnte, sofern dafür Bedarf da ist.

Auf jeden Fall gibt es keine Grund, bei verschiedenen Paketen eine unterschiedliche Auswahl von Terminals zur Verfügung zu stellen. Wenn mein Terminal vt4711 heißt, dann brauche ich vt4711, ob für lynx, mc, screen oder was auch immer.

Und bevor man bei einer größeren Anzahl von Paketen darauf achtet, immer die gleiche Auswahl an Terminals anzubieten, ist es besser, da an einer Stelle zentral zu machen.
 
RalfFriedl schrieb:
Es ist nicht richtig, TERM grundsätzlich auf linux zu setzen. TERM sagt ja nichts über den Rechner oder sein Betriebssystem aus, sondern über das Terminal, an dem der Benutzer sitzt. Korrekt ist es also, das zu übernehmen, was das Client-Programm des Benutzers (telnet, ssh) angibt.
Wo bzw. was (Script? Protokoll?) übernimmt denn die Einstellung vom Terminal des Benutzers? Ich weiß, dass es bei SSH so eine Art "Kontrollkanal" gibt, wo verschiedene Metainformationen ausgetauscht werden. Wird dieser da benutzt? Bei Telnet gibt es sowas nicht, da könnte das über verschiedene Escape-Sequenzen laufen?! Wie gelangt das dann in die Env-Variable?

Wenn man es nicht grundsätzlich auf "linux" setzt, dann sollte man es IMHO auch nicht grundsätzlich auf "xterm" setzen, so wie es momentan in der /etc/init.d/rc.mod gemacht wird. Oder?

Da die vollständige terminfo mit 6MB zu groß ist für die Box, ist es sinnvoll, sich auf die gängigen Terminals zu beschränken. Dazu kann man entweder eine gängige Auswahl treffen, oder Terminals über die Konfig anbieten.
Das ist schön ausformuliert das, was ich oben vorgeschlagen habe.
Komfortabel wäre es, wenn man in der Konfig die Namen von (zusätzlichen) Terminals angeben könnte, sofern dafür Bedarf da ist.
Die Idee ist gut, auch sollte das relativ einfach zu machen sein.

Auf jeden Fall gibt es keine Grund, bei verschiedenen Paketen eine unterschiedliche Auswahl von Terminals zur Verfügung zu stellen. Wenn mein Terminal vt4711 heißt, dann brauche ich vt4711, ob für lynx, mc, screen oder was auch immer.
ACK. Wobei screen da schon ein wenig rausfällt, da es selbst Terminal spielt. Aber da könnte man ja wirklcih -zusammen mit screen- noch die nötigen Files mit installieren.

Und bevor man bei einer größeren Anzahl von Paketen darauf achtet, immer die gleiche Auswahl an Terminals anzubieten, ist es besser, da an einer Stelle zentral zu machen.
ACK
 
derheimi schrieb:
Wo bzw. was übernimmt denn die Einstellung vom Terminal des Benutzers?
Der Client (telnet bzw. ssh) ist dafür zuständig, diese Information an den Server (telnetd bzw. dropbear/sshd) zu übermitteln. Das "wie" hängt vom Protokol (telnet bzw. ssh) ab.
Ich weiß, dass es bei SSH so eine Art "Kontrollkanal" gibt, wo verschiedene Metainformationen ausgetauscht werden. Wird dieser da benutzt? Bei Telnet gibt es sowas nicht, da könnte das über verschiedene Escape-Sequenzen laufen?
Der richtige telnet Server macht anscheinend dem Client klar, daß er die TERM-Angabe haben will und bekommt sie auch. Der telnetd aus der Busybox tut das leider nicht. Die Details müßte man nachsehen. Die Escape-Sequenzen im telnet bilden sozusagen den Kontroll-Kanal, wobei Escape hier nicht den Zahlenwert 27 sondern 255 hat.
Code:
19:32:23.085455 IP 127.0.0.1.56931 > 127.0.0.1.23: P 28:72(44) ack 46 win 257
        0x0000:  4510 0060 18a5 4000 4006 23e1 7f00 0001  E..`..@.@.#.....
        0x0010:  7f00 0001 de63 0017 c377 4e81 c43d b03d  .....c...wN..=.=
        0x0020:  8018 0101 f622 0000 0101 080a 5bfc 56d9  ....."......[.V.
        0x0030:  5bfc 56d1 fffa 1f00 7e00 36ff f0ff fa20  [.V.....~.6.....
        0x0040:  0033 3834 3030 2c33 3834 3030 fff0 fffa  .38400,38400....
        0x0050:  2700 fff0 fffa 1800 5654 3437 3131 fff0  '.......VT4711..

linux login: test
Password:
tset: unknown terminal type vt4711
Terminal type?

Wenn man es nicht grundsätzlich auf "linux" setzt, dann sollte man es IMHO auch nicht grundsätzlich auf "xterm" setzen, so wie es momentan in der /etc/init.d/rc.mod gemacht wird.
Richtig.
Da aber der telnetd der Busybox TERM nicht annimmt (war mir bisher nicht aufgefallen), ist es besser, den Wert zu setzen, der häufig richtig ist, als gar keinen. Wobei ich nicht sicher bin, ob das Setzen von TERM an der Stelle eine Auswirkung hat oder nicht.

Das ist schön ausformuliert das, was ich oben vorgeschlagen habe.
Der Satz war als Einleitung gemeint für "Entweder man gibt die Auswahl vor oder man überläßt die Auswahl dem Anwender". Wobei sich meines Wissens bisher noch keiner über die fehlende Auswahl beklagt hat. Ich vermute, mit den von Dir genannten Terminal-Typen sind über 99% der Fälle abgedeckt. Theoretisch wäre es richtig, die Terminal-Typen zur Auswahl anzubieten. Praktisch gesehen weiß ich nicht, ob sich heutzutage die Mühe lohnt. Mein vt4711 ist sowieso gerade zur Reparatur ;).
Wobei screen da schon ein wenig rausfällt, da es selbst Terminal spielt.
Stimmt, das ist ein Sonderfall. Das Programm "screen" verwendet den Terminal-Typ "screen". dieser muß also für die Programme, die unter "screen" laufen, vorhanden sein. Das Programm nutzt für seine eigene Bildschirmausgabe den TERM-Wert, den es vorfindet.
Wenn jemand aber "screen" auf dem PC verwendet, um auf die Box zuzugreifen, sollte idealerweise der Termcap-Eintrag "screen" auf der Box sein, selbst wenn das Programm "screen" nicht auf der Box sein sollte.
 
Was müsste denn der Patchbefehl dann ausgeben? Irgendwie passiert da garnichts. Ich hab vorsichtshalber nochmal nen neues dsmod Verzeichnis erstellt. Erst mit menuconfig alles eingestellt, dann den patch in den root des dsmod Ordners, dann "patch -p0 < lynx-terminfo.patch" - nichts habs dann mit Strg+C abgebrochen, weiterer Test, weil im Ordner dsxx/make/lynx/patches noch andere .patch Dateien gespeichert waren dort den Patch reinkopiert und wieder versucht auszuführen - auch keine Reaktion. Ka ob ich was falsch mache vielleicht ein letzten Tip von den Profis...
 
A sagt mir doch das gleich ;)
So jetzt heißt es wieder warten auf das Image...
 
So die Sache hat geklappt, danke nochmals...
 
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.