[linux-l] unterschiedliche "xterm" wie richtig verwenden?

[Steffen Dettmer]

Hi,

sorry für meine späte Antwort und danke für Deine Tips.

Hilft leider nicht weiter. Hat noch jemand eine Idee?

* Lutz Willek wrote on Wed, Sep 05, 2012 at 10:36 +0200:
> Ich muss auch öfter Putty nutzen. Meines Wissens ist der UTF-8 Support
> ein internes Putty-Problem:

Ich nutze das zwar nur wenig (nur paar deutsche Umlaute), aber
Putty-Probleme konnte ich wohl nicht feststellen - solange sich
eben beide Seiten über das Encoding einig sind :)

> Allgemein hilfreich zum Thema finde ich folgenden Link:
> http://www.michael-schummel.de/2007/10/22/putty-und-utf-8/

Hilfreich?
Wird da nicht mein "Problem" als "Lösung" angeboten:

        Fazit, wer mit UTF-8-Zeichen arbeitet, sollte sich darauf
        einrichten immer mal wieder zwischen einer UTF-8-Dartsellung und
        einer ISO8859-1-Darstellung umschalten zu müssen. Das ist, wie
        oben dargestellt, nicht sehr schwierig. Wer das oft braucht,
        könnte sich auf der Serverseite kleine Makros schreiben, muss
        aber daran denken auch im PUTTY die Translation umzustellen.

"Ans umschalten denken müssen" möchte ich ja gerade nicht...

> Inzwischen bin ich jedoch fast vollständig weg von Putty, hin zu
> mobaxterm. Dies ist im Endeffekt eine cygwin bash mit X-Server und

ok, cygwin mit X server und xterm (mit ssh) verwende ich auch
lieber, wenn's geht, ist aber "schwerer" und der cygwin X server
ist irgendwie komisch, z.B. was er mit Xresources macht ("xrdb
-query" returns NICHTS, wenn ich "xrdb -override" manuell
versuche, kommt Mist raus).

Das ändert aber nichts an meinem Problem. Hat das lokale xterm
UTF-8, muss die remote-Shell auch UTF-8 haben, sonst paßt es
nicht.

> Wo das nicht nicht einsetzbar ist nutze ich (aus verschiedensten
> Gründen) nicht putty, sondern kitty: http://kitty.9bis.com/

(mit'm eingebauten Chatserver?! :))

> > Wenn ich bei Putty "translation" auf UTF-8 stelle, muss ich auf
> > einem Server "export LC_CTYPE=de_DE.UTF-8" oder etwas in der Art
> > machen, damit vim richtig funktioniert, weil sonst steht locale
> > auf "de_DE at euro".
>
> Ich löse das für mich zufriedenstellend mit folgender Einstellung in
> Putty für alle Verbindungen:
> -->Windows-->Translation-->Remote character set: UTF-8
> -->Windows-->Translation--> "Adjust line drawing characters"
>     * [x] Use Unicode line drawing code points
> -->Connection-->Data-->"Terminal details": Terminal-type string: "linux"
> -->Connection-->Data-->"Environment variables":
>    * die drei Variablen LANG, LC_ALL *und* zusätzlich LC_CTYPE
>      auf "de_DE.utf8"

Das funktioniert aber spätestens dann nicht, wenn remote kein
UTF-8 kann/will (was aber auch nicht mein Problem ist, da ich
putty configs nicht synchronisiere)

> Achtung!
> Der ssh Server des Zielsystems (/etc/ssh/sshd_config) muss unter
> Umständen konfiguriert werden, damit die Variablen auch durch gereicht
> werden: "AcceptEnv", siehe http://linux.die.net/man/5/sshd_config

ahh OK, AcceptEnv heißt mein Problem also offensichtlich. Danke.

     "The default is not to accept any environment variables."

also per default funktioniert es sytembedingt überhaupt nicht?
Toll. Kennt man von Unix-Envs gar nicht, sowas...
Aber TERM wird akzeptiert, obwohl nicht konfiguriert, komisch...

Dann müßte ich ja voraussichtlich ALLE Server umkonfigurieren
bzw. umkonfigurieren lassen!

Außerdem ist das env von xterm hier genau gleich, egal ob es im
UTF-8 oder Latin-15 Modus arbeitet, also selbst das würde nicht
reichen :(

> > Ich hab schon viel gegoogelt, aber nicht herrausgefunden, wie das
> > Terminal-Encoding nun automatisch herausgefunden werden soll.
>
> Gar nicht! Terminalencoding ist Sache des Nutzers, Du _musst_ es für
> Dich passend einstellen.

Nee, ich finde, das sollte das Terminal machen. Farben und die
ganzen Steuerzeichen macht es ja auch automatisch (über $TERM),
nur genau ausgerechnet das Encoding nicht. Wobei ein xterm über
locale herausfinden könnte, ob es UTF-8 machen soll oder nicht
und sich entsprechend konsistent (also richtig) verhalten könnte.

Würde man die entsprechenden locale Eigenschaften "vererben"
(also wie TERM auch über "SSH-Grenzen" hinaus), sollte es
funktionieren. Ist auch viel logischer, wenn die lokale Zeit vom
Terminal (also Benuzter) abhängt, und nicht von irgendwelchen
Systemdefaults (ssh server.us und Zeitzone ist meist "falsch",
obwohl das per Environment prima geht, so man es denn manuell
korrigiert).

> Das eigentliche Problem dabei ist, dass:
> a.) die Gegenseite Deine Umgebung auch bereitstellen kann
> b.) die Variablen auch über ssh weiter gegeben werden können
>
> Im a.)-Fall kann ich mir mit hostspezifischen Einträgen in meiner
> privaten ssh-config helfen, die das eben passend umkonfigurieren.

Das ist ja nicht hostspezifisch!
Soweit ich weiß, können alle Hosts, die UTF-8 können, immer noch
Latin-1. Der Host muss dann nur das machen, was das lokale
Terminal hat, das kann ja beides sein.

> Im b.)-Fall hilft nur eine Anfrage an die Administration des Systems,
> als User kannst Du da nichts machen.

Unglaublich.
Kennt man von Unix gar nicht, sowas :(

Man könnte TERM irgendwie mißbrauchen (TERM=xterm-256color-utf8
oder sowas), aber das kann doch alles nicht der Gutfall sein?!

> imho: Eine freundliche Mail an den Admin des Servers hilft jedoch
> erstaunlich oft, in beiden Fällen ;)

Ja, aber das skaliert schlecht :)

> > Die ganzen UTF-8 HOWTOs, die ich fand, gehen scheinbar von der
> > irrigen Annahme aus, man würde immer, überall, auf allen Systemen
> > und unbedingt UTF8 machen, was ja wohl kaum der Normalfall sein
> > dürfte.
>
> Ha! Ich sag mal so: Der Idealzustand ist seit längerem: "immer und
> überall UTF-8". Und leider leben wir halt nicht in einer perfekten Welt.

Na ja, UTF-8 ist "teuer" und ich persönlich bräuchte es
eigentlich so gut wie nie, Latin1 reicht fast immer.
(Na ja, ich glaube, ich würde sogar die deutschen Umlaute
abschaffen, seh deren Nutzen nicht so recht...)

Ich hab bis vor kurzem in Terminals überhaupt kein UTF-8
verwendet, sondern Latin-9 (ISO-8859-15, die mit dem Euro), das
geht nur jetzt nicht mehr, weil ich UTF-8 Files bearbeiten muss,
was in Latin-X-Umgebungen ja nicht richtig funktioniert.

Die Systeme scheinen davon auszugehen, UTF-8 zu machen, wenn
lokal UTF-8 geht, ohne auf die Idee zu kommen, dass man
vielleicht eben kein lokales xterm hat und dabei zu vergessen,
dass das lokale xterm auch latin1 kann.

Hat denn das bei der UTF-8 wirklich niemand bemerkt? Gerade als
UTF-8 Support weniger verbreitet war, muss doch mein Problem
weitverbreitet gewesen sein?

> Hoffe die Mail hilft Dir etwas, lg

ja danke, nur blöd, dass es tatsächlich kaputt-by-design und
keinem-fiel-es-jemals-auf sein soll :(

oki,

Steffen

--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.