Umlaute im Terminal

T

ThomasC

Mitglied
Thread Starter
Dabei seit
06.04.2006
Beiträge
32
Reaktionspunkte
1
Es gibt viele, viele Threads dazu, und auch eine Menge Seiten an Tipps, die ich mittlerweile durch habe. Und dennoch: Ein Problem im Terminal ist geblieben und ich sehe keinen Weg mehr, da weiter zu kommen.

In meiner .inputrc steht:
set meta-flag on
set convert-meta off
set output-meta on
set show-all-if-ambiguous on

Terminal->Fenstereinstellungen->Darstellung:
"Zeichensatz-Codierung (ISO Latin 9)"

Terminal->Emulation->
"Nicht ASCII-Zeichen in ESC-Sequenz wandeln"

Damit kann ich: Umlaute eingeben und auch mittels <Backspace> oder <Del> wieder löschen, soweit alles in Ordnung.
Gebe ich aber "ls /" ein, so kommt folgende Ausgabe (abgekürzt)

BenutzerhandbuÌcher und Informationen@ Volumes/ Desktop DB automount/

Es ist schwer hier darzustellen, wegen dem Umbruch, aber passieren tut folgendes: Das "ü" in Benutzerhandbücher wird als 2 Zeichen dargestellt (wirre Sonderzeichen) und die Spalten kommen durcheinander, so dass automount/ nicht unter Volumes/ steht sondern ein Zeichen verschoben.

Setze ich im Terminal aber:

Terminal->Fenstereinstellungen->Darstellung:
"Zeichensatz-Codierung (Unicode UTF-8)"
so habe ich einen anderen Effekt:

Nun liefert ls / richtig "Benutzerhandbücher", dafür ist nun Volumes um 2 Spalten nach vorne verschoben und das Löschen von Umlauten bei der Eingabe geht nicht mehr. Gebe ich also z.B. "öööööööööööööööö" ein, und drücke dann solange <Backspace> oder <Del> bis alle Umlaute weg sind, so kann ich in den Prompt hinein löschen, und zwar für jeden gelöschten Umlaut genau ein Zeichen. Drücke ich dann die Eingabetaste so sagt mir die Bash dann:
-bash: äää?: command not found
Offenbar bleiben Teile (das 2. Byte des Unicode-Codes?) beim Löschen übrig, die dann Bash interpretieren will.

Ah ja, der Vollständigkeit halber: ls ist ein Alias und macht
ls -GFw (das -w führt erst dazu, dass ls Umlaute ausgeben will)

Es hängt nicht mein Leben davon ab (momentan benutze ich Methode 1, da Verzeichnisnamen mit Umlauten eh selten sind und mich das Problem beim Löschen viel mehr stört), aber mich würde doch interessieren, ob jemand eine komplett 100% funktionsfähige Einstellung des Terminals kennt.
bash --version liefert 2.05b.0(1), interessanterweise genau dieselbe Version, die auf einem Linux Debian Server in der Arbeit BEIDE Probleme nicht hat. Nur gelingt es mir einfach absolut nicht, einen wesentlichen Unterschied in irgendwelchen Konfig-Dateien zu finden.

Noch eine Idee?

Viele Grüße
Thomas
 
Habe das selbe Problem mit UTF-8.

Komischerweise funktioniert <Backspace> korrekt, nachdem die Shell neu gestartet wurde (z.B. mit dem Kommando "exec bash").

Es muss irgendwie mit Readline (den inputrc-Einstellungen) und den Terminal-Fenstereinstellungen zutun haben.
 
Zuletzt bearbeitet:
hässlicher Hack:

exec bash

an /etc/profile anhängen.

Achtung: Ein Nebeneffekt ist, dass ~/.profile nicht mehr ausgeführt wird.
 
Zuletzt bearbeitet:
Fehlerbild:
(stark vereinfacht - geeignet für Bugreport?)

1.
Aktivierung der Bash-Unicode-Ein/Ausgabe im Standard-Tiger-Terminal durch folgende Zeilen in ~/.inputrc:
set input-meta on
set convert-meta off
set output-meta on
und folgende Zeile in ~/.bash_profile:
export LANG=en_US.UTF-8

2.
Nach dem Start des Terminals wird durch "env" sichtbar, dass LANG wie gewünscht gesetzt ist.

3.
Symptom: <Backspace> löscht Umlaute nicht korrekt.

4.
Wird während der Sitzung mit "export LANG=en_US.UTF-8" die Variable erneut "von Hand" auf den selben Wert gesetzt, oder mit "bash" eine neue Shell gestartet bzw. mit "exec bash" die Shell ersetzt, funktioniert <Backspace> korrekt.

any ideas?
 
Ich werde nie verstehen, weshalb Apple nicht UTF-8 als (funktionierendes) default für das Terminal verwendet. Im Rest des Systems ist alles perfekt internationalisiert...
 
moin

ThomasC schrieb:
Setze ich im Terminal aber:

Terminal->Fenstereinstellungen->Darstellung:
"Zeichensatz-Codierung (Unicode UTF-8)"
so habe ich einen anderen Effekt:

Nun liefert ls / richtig "Benutzerhandbücher", dafür ist nun Volumes um 2 Spalten nach vorne verschoben und das Löschen von Umlauten bei der Eingabe geht nicht mehr. Gebe ich also z.B. "öööööööööööööööö" ein, und drücke dann solange <Backspace> oder <Del> bis alle Umlaute weg sind, so kann ich in den Prompt hinein löschen, und zwar für jeden gelöschten Umlaut genau ein Zeichen. Drücke ich dann die Eingabetaste so sagt mir die Bash dann:
-bash: äää?: command not found
Offenbar bleiben Teile (das 2. Byte des Unicode-Codes?) beim Löschen übrig, die dann Bash interpretieren will.

Ah ja, der Vollständigkeit halber: ls ist ein Alias und macht
ls -GFw (das -w führt erst dazu, dass ls Umlaute ausgeben will)

Es hängt nicht mein Leben davon ab (momentan benutze ich Methode 1, da Verzeichnisnamen mit Umlauten eh selten sind und mich das Problem beim Löschen viel mehr stört), aber mich würde doch interessieren, ob jemand eine komplett 100% funktionsfähige Einstellung des Terminals kennt.
bash --version liefert 2.05b.0(1), interessanterweise genau dieselbe Version, die auf einem Linux Debian Server in der Arbeit BEIDE Probleme nicht hat. Nur gelingt es mir einfach absolut nicht, einen wesentlichen Unterschied in irgendwelchen Konfig-Dateien zu finden.

Noch eine Idee?

Viele Grüße
Thomas
Zum Vergrößern anklicken....


soweit ich weiß ist die bash erst ab Version 3 und unter Verwendung von readline Version 5 unicodefähig.

Also - denke ich - heißt es warten bis apple diese Versionen verwendet oder diese Versionen über darwinports installieren.


Grüße,

ember

(endlich auf den Mac zurück gekehrt ;) )
 
ember schrieb:
moin

soweit ich weiß ist die bash erst ab Version 3 und unter Verwendung von readline Version 5 unicodefähig.

Also - denke ich - heißt es warten bis apple diese Versionen verwendet oder diese Versionen über darwinports installieren.


Grüße,

ember

(endlich auf den Mac zurück gekehrt ;) )
Zum Vergrößern anklicken....

Eine durchschnittliche Linux-Distri widerlegt Deine Aussage seit Jahren.

Es war schon vor 6 Jahren eine tolle Leistung von Apple
UTF-8 auf die Fahne zu schreiben und auf tcsh zu setzen.
(Mittlerweile soll allerdings sogar tcsh unicode verarbeiten können.)
 
tastendruecker schrieb:
Eine durchschnittliche Linux-Distri widerlegt Deine Aussage seit Jahren. Es war schon vor 6 Jahren eine tolle Leistung von Apple UTF-8 auf die Fahne zu schreiben und auf tcsh zu setzen. (Mittlerweile soll allerdings sogar tcsh unicode verarbeiten können.)
Zum Vergrößern anklicken....

seit 10.4 ist die standard-shell bash...
nur wenn man von 10.3 auf 10.4 updated behält man tcsh als standard-shell...
 
moin

tastendruecker schrieb:
Eine durchschnittliche Linux-Distri widerlegt Deine Aussage seit Jahren.
Zum Vergrößern anklicken....

hm. Siehe zB hier

http://de.gentoo-wiki.com/Utf8#Shells

oder hier:

http://www.tldp.org/HOWTO/Unicode-HOWTO-4.html#ss4.1

Anscheinend gibt es für die bash ab 2.04 einen Patch, der sie unicodefähig macht; das war mir entgangen. Von Haus aus (dabei bleibe ich aber :eek:) hat die bash erst seit Version 3 weitreichende Unicode-Unterstützung.

Merke: das sagt nix über die Unicode-Unterstützung zB in gtk oder qt aus - diese gibt es schon länger.

Ach so: meine Experimente zum Thema "Unicode + MacOS X" mit einem Bonus bezüglich gvim kann der Interessierte

hier (blog.stillflying.de/2006/07/14/vim-gvim-und-utf-8-unter-macosx-tiger)

nachlesen.

Grüsse,

Ember

(btw nutze ich seit div. Jahren hauptsächlich gentoo auf Workstation + Server und habe da schon einige Erfahrungen mit dem leidigen Thema "Unicode" machen dürfen. Ok, aber vielleicht ist gentoo ja keine "durchschnittlichen Linuxdistributionen".)
 
  • Gefällt mir
Reaktionen: moses_78
ember schrieb:
moin



hm. Siehe zB hier

http://de.gentoo-wiki.com/Utf8#Shells

oder hier:

http://www.tldp.org/HOWTO/Unicode-HOWTO-4.html#ss4.1

Anscheinend gibt es für die bash ab 2.04 einen Patch, der sie unicodefähig macht; das war mir entgangen. Von Haus aus (dabei bleibe ich aber :eek:) hat die bash erst seit Version 3 weitreichende Unicode-Unterstützung.

(btw nutze ich seit div. Jahren hauptsächlich gentoo auf Workstation + Server und habe da schon einige Erfahrungen mit dem leidigen Thema "Unicode" machen dürfen. Ok, aber vielleicht ist gentoo ja keine "durchschnittlichen Linuxdistributionen".)
Zum Vergrößern anklicken....

Man sollte nicht alles glauben, was gentoo wiki schreibt.
Bash hat seit Version 2.05b Unicode-Support
(Readline 4.13)

Beide Pakete wurden am 18 Juli 2002 veröffentlich.
(Also vor 4 Jahren)

Du kannst also davon ausgehen, dass Gentoo es viel früher konnte.

MfG
 
hi

ok, man lernt ja nie aus; habe nochmal im Changelog gewühlt - Du hast recht. Das werde ich dann mal flugs auch im gentoo-wiki ändern.


Grüsse,

ember
 
Hat jemand mal die neuere Bash-Versionen getestet? Funktioniert das dann?

Gibts dafür einen Workaround?

Danke GALDO
 
Ist es praktikabel, die bash aus dem aktuellen Sourcecode zu compilieren und das Apple-Binary zu überschreiben? Oder kommt dann am Ende nur Mist raus? :)
(Ich ahne schon, was die Antwort ist...)
 
christian l schrieb:
Ist es praktikabel, die bash aus dem aktuellen Sourcecode zu compilieren und das Apple-Binary zu überschreiben? Oder kommt dann am Ende nur Mist raus? :) (Ich ahne schon, was die Antwort ist...)
Zum Vergrößern anklicken....

überschreiben ist das dämlichste was du machen kannst ;)
selbstkompilierte sachen gehören nach /usr/local/bin usw...
 
Also ich habe jetzt die Bash 3.1 von der GNU-Seite genommen und compiliert. Das Binary habe ich nach /usr/local/bin kopiert und den Pfad entsprechend gesetzt. Wenn ich die Bash 3.1 starte, dann tritt der Effekt mit dem nicht fehlerfreien Löschen von Umlauten mit der Entfernen-Taste nicht mehr auf.
Im pico kann ich die Umlaute aber leider trotzdem nicht verwenden :(

P.S.: Wenn ich das Binary überschrieben hätte, hätte ich wenigstens die bash nach bash_old kopiert. Trotzdem hat oneOeight recht: Auf ähnliche Weise habe ich mal ein Solaris 9 System geschrottet (hehe).
 
christian l schrieb:
Also ich habe jetzt die Bash 3.1 von der GNU-Seite genommen und compiliert. Das Binary habe ich nach /usr/local/bin kopiert und den Pfad entsprechend gesetzt. Wenn ich die Bash 3.1 starte, dann tritt der Effekt mit dem nicht fehlerfreien Löschen von Umlauten mit der Entfernen-Taste nicht mehr auf.
Im pico kann ich die Umlaute aber leider trotzdem nicht verwenden :(
Zum Vergrößern anklicken....

Am pico generell kann es nicht liegen.
Was sagt denn pico --version?

MfG
 
pico --version liefert: GNU nano version 1.2.4 (compiled 16:03:21, Mar 20 2005) Also doch der Nano :) Vielleicht habe ich noch nicht alle Einstellungen vorgenommen, die für eine kopmlette Unterstützung der Umlaute notwendig sind. Werde mich aber darum kümmern. Die Kritik eines Vorposters, daß jede aktuelle Linuxdistribution Umlaute im Terminal kann, ist durchaus berechtigt. Hoffentlich wird mit Leopard mal eine vollständig auf UTF-8 basierende (und funktionierende) Shellumgebung mitgeliefert. Das sollte man von Apple eigentlich erwarten können, vor allem wenn man die Unterstützung für asiatische Sprachen ansieht, die ja Systemweit vorhanden ist. (Bis auf das Terminal natürlich ;) )
 
Ich habe mir auch gerade mal eine aktuelle bash kompiliert und gestartet, allerdings hatte ich den Bug weiterhin.

hmm...
 
Kai90 schrieb:
Ich habe mir auch gerade mal eine aktuelle bash kompiliert und gestartet, allerdings hatte ich den Bug weiterhin. hmm...
Zum Vergrößern anklicken....
Vielleicht muss man eine neuere Readline-Bibliothek linken.
Ich werde das mal ausprobieren....
 
Stimmt, klingt logisch! Hab mir grad die aktuell libreadline gebaut und die bash damit kompiliert und jetzt klappt es einwandfrei.

Umlaute in pico/nano funktionieren bei mir auch nicht. Ist mir aber egal da ich eher vim-Nutzer bin. ;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten