[SOLVED] Re: terminal Emulation zu SCO Unix? / ISO646-DE Charset-Mischmasch

From: Malte von dem Hagen <vdh(at)mnetworking.de>
Date: Wed, 05 Apr 2006 22:13:29 +0200

Hallo,

es ist schon sehr lange her, aber nach einer Zeit der Ruhe hab ich das
Problem dann doch noch mal angefasst und auch gelöst. Den ursprünglichen
 Dialog und die Lösung poste ich hier i.w. zu Dokumentationszwecken.

Problem:
========
informix Datenbankanwendung auf SCO OpenServer Release 5
erstellt durch die Fa. SI-NET

Es ließ sich kein eindeutiger Terminal Typ feststellen, die Anwendung
selbst benutzte für die Menüführung einen anderen Zeichensatz (bis dato
unbekannt) als für die Nutzdaten (ISO646-DE).

Dadurch war die Anwendung nicht mittels simplen telnettings benutzbar,
obwohl das wohl mal so gedacht war.

Lösung:
=======
Eine Lösung muß zwangsläufig dreistufig sein:

- Zeichensatzprobleme lösen
  -------------------------
  Dafür habe ich einen beliebigen TrueType Font hergenommen (hier:
  Bitstream Vera Sans Mono) und habe in einem Font Editor (hier:
  High-Logic Font Creator unter Windows) sämtliche Umlaute und
  Blockgrafik-Zeichen an die Stellen kopiert, an die sie zu gehören
  schienen. Bsp.: Da, wo ne rechte obere Ecke sein sollte, wurde bei
  normalem telnet ein È dargestellt -> Zeichen für die Ecke dorthin
  kopiert. Der Font hat einen eindeutigen Namen bekommen und wurde in
  /usr/X11R6/lib/X11/fonts/bitstream-vera/ untergebracht.

- Funktionstastenproblem lösen
  ----------------------------
  Ich habe mich entschieden, den Zugriff via xterm zu realisieren,
  mittels der ~/.Xdefaults ließen sich die Funktionstasten wunderbar
  übersetzen:

  xterm*VT100.translations: #override \
          <Key>F5: string(0x1b) string("OT") \n\
          <Key>F6: string(0x1b) string("OU") \n\
          <Key>F7: string(0x1b) string("OV") \n\
          <Key>F8: string(0x1b) string("OW") \n\
          <Key>F9: string(0x1b) string("OX") \n\
          <Key>Break: string(0x7f)

- Mapping der Umlaute lösen
  -------------------------
  Um auch schreibenden Zugriff zu erlauben, mussten zusätzlich zu den
  Zeichen im Charset die zugehörigen Keycodes geändert werden. Dies
  natürlich beschränkt auf die Anwendung, daher habe ich das mit
  c-kermit gelöst. c-kermit wird aufgerufen mit einer rc-Datei als
  Argument, die folgendes enthält:

  set key \223 \~
  set key \228 \{
  set key \246 \|
  set key \252 \}
  set key \196 \[
  set key \214 \\
  set key \220 \]
  telnet 192.168.118.1

  Damit werden die Tastendrücke der Umlaute (äöüßÄÖÜ) in ISO646-DE
  übersetzt und es wird direkt der Login auf dem Server aufgerufen.

  Das ist nötig, da c-kermit unter Unixoiden leider kein SET
  TERMINAL-TYPE unterstützt und die Zeichensatzübersetzung auch nicht
  zielführend war.

- Alles zusammenführen:
  ---------------------

  Am Ende wird mittels

  xterm -T informix -bg black -fg goldenrod1 -fa 'Informix Sans Mono' \
  -fs 15 -en iso8859-15 -e kermit ~/-kermitrc

  direkt der Login in die Anwendung von einem X aus aufgerufen, die
  Übersetzungen funktionieren und alles gut :-)

Gruß,

Malte

Oliver Fromme schrieb:
> Moin,
>
> Da sonst niemand geantwortet hat, stochere ich mal ein
> bißchen im Nebel herum ... :-)
>
> Malte von dem Hagen <vdh(at)mnetworking.de> wrote:
> > ich möchte gerne per telnet eine Anwendung (Informix) auf einem SCO Unix
> > benutzen, von einem FreeBSD 5-STABLE aus. Problematisch sind dabei
> > offenbar vor allem die Funktionstasten (F1-F12).
> >
> > Eine ausführliche Suche im Netz ergab bisher nur, daß scheinbar viele
> > Leute das Problem haben, aber keiner eine brauchbare Lösung.
>
> Wenn die Anwendung (Informix) ordentlich programmiert wäre,
> müßte sie sich an die entsprechenden termcap/terminfo-Daten
> halten und dementsprechende Codes von den Funktionstasten
> erwarten. (Vorausgesetzt natürlich, daß $ENV gemäß dem je-
> weiligen Terminal korrekt gesetzt ist.)
>
> Da es aber nicht funktioniert, ist die Anwendung offenbar
> nicht so sauber programmiert. Es stellt sich jetzt die
> Frage, welche Codes sie erwartet. Da ich Informix unter
> SCO UNIX nicht kenne, kann ich da nur raten. Naheliegend
> wären z.B. die Codes der SCO-Console. In der FreeBSD-term-
> cap findet man sie unter »scoansi«:
>
> :k1=\E[M:k2=\E[N:k3=\E[O:k4=\E[P:k5=\E[Q:k6=\E[R:\
> :k7=\E[S:k8=\E[T:k9=\E[U:k0=\E[V:
>
> Das sind dieselben wie bei FreeBSD's syscons. Es wäre also
> mal einen Versuch wert, zu testen, ob die Funktionstasten
> in Informix funktionieren, wenn Du die Anwendung von sys-
> cons aus startest. Das Problem dürfte nun sein, daß SCO-
> UNIX den Terminaltyp »syscons« nicht kennt. Da die beiden
> aber hinreichend nah verwandt sind, kann man es einfach
> manuell auf »scounix« setzen.
>
> Also folgende Vorgehensweise:
>
> - Mit Ctrl-Alt-F1 auf die erste syscons-Console gehen
> (falls Du noch unter X11 bist).
>
> - Einloggen.
>
> - »export TERM=scoansi« (sh, zsh, ksh, bash) bzw.
> »setenv TERM scoansi« ((t)csh).
>
> - Auf dem SCO-UNIX-Rechner einloggen.
>
> - Nochmals prüfen, daß $TERM wie erwartet gesetzt ist.
> (Manche Shell-Profiles überschreiben $TERM blödsinniger-
> weise.)
>
> - Nachgucken, ob das SCO-UNIX tatsächlich »scoansi« in
> der termcap oder terminfo hat. Wenn nicht, $TERM ent-
> sprechend korrigieren. (Vielleicht heißt der Eintrag
> unter SCO UNIX geringügig anders.)
>
> - Die Anwendung (Informix) starten und gucken, ob F1 usw.
> funktionieren.
>
> Falls das klappt, man aber nicht dauerhaft syscons verwen-
> den möchte (was ja verständlich ist), kann man z.B. xterm
> die entsprechenden scoansi-Codes beibiegen.
>
> > Ich habe leider keinen administrativen Zugriff auf den Server.
>
> Das ist auch nicht erforderlich. Der Bug existiert zwar
> in der Anwendung auf dem Server, aber da es kein Open-
> Source ist, kannst Du da sowieso nicht viel machen. Der
> Work-around ist halt, Client-seitig die passenden Code-
> Sequenzen für die Funktionstasten zu senden, die die
> Anwendung erwartet.
>
> > [...]
> > Die Anwendung wurde bisher mit TUNplus unter wine benutzt. Ich habe
> > Zugriff auf die alten Config-Files von TUNplus, und in denen findet sich
> > folgendes:
> > [...]
> > Terminal=at386.ter <--- Aha, ein terminal type
>
> Offenbar ein Dateiname.
>
> > at386.ter
> > =========
> > feno at386 at386 at386 97801
> > german asciie
> >
> > MF\sXGA\s(1024x768.CP437) <--- und eine Codepage.
>
> Das ist der gute alte Standard-DOS-Zeichensatz, der auch
> heute noch in jeder Graphikkarte enthalten und nach einem
> Reset als Default aktiviert ist.
>
> Das hat allerdings nichts mit den Funktionstasten zu tun.
>
> > at386.fun
> > =========
> > \033OP F1
> > \033OQ F2
> > \033OR F3
> > \033OS F4
> > \033OT F5
> > \033OU F6
> > \033OV F7
> > \033OW F8
> > \033OX F9
> > \033OY F10
> > \033OZ F11
> > \033OA F12
>
> Aha -- das sind offenbar die Code-Sequenzen, die für die
> Funktionstasten gesendet werden. Wenn diese funktionieren,
> dann sind sie offenbar in Informix gehardcodet (das ist der
> Pfusch, den ich bereits in meiner vorhergehenden Mail ver-
> mutet hatte). Die ersten zehn (bis F10) entsprechen dem
> »at386«-Eintrag in der FreeBSD-termcap, die anderen beiden
> (F11 und F12) scheinen keinerlei Eintrag zu entsprechen.
>
> Du kannst z.B. xterm überreden, obige Code-Sequenzen zu
> schicken (durch die VT100.ranslations-Resource via #over-
> ride; siehe die xterm-manpage).
>
> Unter syscons kannst Du die Funktionstasten mit kbdcontrol
> (siehe die manpage) einstellen. Für obige Codes wäre das:
>
> ESC=$(printf '\033')
> kbdcontrol -f 1 "${ESC}OP"
> kbdcontrol -f 2 "${ESC}OQ"
> kbdcontrol -f 3 "${ESC}OR"
> usw.
>
> (Bei den meisten Shells kann man <ESC> auch direkt einge-
> ben, wenn man davor Ctrl-V tippt.)
>
> Danach kannst Du Dich (unter syscons) mit dem SCO-UNIX ver-
> binden, und es sollte -- theoretisch -- funktionieren.
> (Evtl. vorher nochmal »export TERM=at386« eingeben.)
>
> > Diese drei Angaben sollten eigentlich reichen, dachte ich mir und starte
> > voller Zuversicht putty.
> >
> > Es folgen Probleme:
> >
> > 1. putty kennt kein "at386". Durch trial and error habe ich aber
> > entdeckt, daß vt100+ (unter Terminal -> Keyboard -> The Function keys
> > and keypad) scheinbar funktioniert - verifizieren kann ich das erst
> > morgen.
>
> Bei VT100 stimmen die ersten vier Funktionstasten mit denen
> von at386 überein (siehe termcap). Die restlichen sind un-
> terschiedlich.
>
> > 2. Unter "Window -> Translation -> Character set translation on received
> > data" kann ich CP437 auswählen. Klingt gut.
> >
> > 3. Font-Auswahl. Da ist leider keiner dabei, der CP437 (oder CP850, die
> > scheint ja sehr ähnlich zu sein) bietet, und bei Verwendung eines
> > iso8859-1 Fonts werden mir die Umlaute und das scharfe s teilweise
> > falsch dargestellt (ö=|, Ü=], ü=}, ß=~).
>
> Das ist weder ISO8859-1 noch CP437 oder CP850, sondern eine
> inzwischen völlig veraltete US-ASCII-Variante, die hierzu-
> lande als DIN66003 standardisiert wurde (später ISO646-DE).
> Sie enthält die Umlaute an Stelle der Zeichen {|}[\]~:
>
> http://czyborra.com/charsets/iso646-de.txt.gz
>
> > gnome-telnet kennt btw. ein paar mehr terminal types, aber at386 ist
> > nicht darunter - und character set translation geht damit gar nicht.
>
> Du könntest unter syscons eine entsprechende Screenmap für
> die Konvertierung der Ausgabe der Umlaute erstellen. Damit
> kann man beliebige Konvertierungen einrichten.
>
> Oder -- ein bißchen aufwendiger -- einen DIN66003-Zeichen-
> satz für syscons erstellen. Dazu muß man nur einen exi-
> stierenden nehmen (ISO8859 oder CP437) und die Umlaute an
> andere Stellen kopieren.
>
> Gruß
> Olli

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 05 Apr 2006 - 22:14:50 CEST

search this site